Which Layers of a Mop Robot Should Simulation Cover?

• Circuit layer
• Firmware layer
• Motion layer
• Fleet layer

What you will learn

• Tell apart what simulation can prove from what only a real prototype can answer.
• Write a testable pass criterion for each layer and tie it to a requirement.
• Follow one requirement, returning home on link loss, through all four layers and know when to stop simulating and build.

Before you start

It helps to have read the article on the parts of a mini mopping-robot system. Other terms are explained where they first appear.

What can simulation prove, and what can it not?

Simulation gives evidence that a design meets a requirement inside a model, not inside a real home. The NASA Systems Engineering Handbook separates two questions: verification asks whether the end product was realized right, validation asks whether the right end product was realized. The same document places simulation among the methods of analysis: a model is a mathematical representation of reality, and a simulation is the manipulation of a model.

The reason to simulate is cost. Testing the real product is the most resource-intensive verification technique, and validation by testing is the same. Fixing the design in a model before building a prototype is a cheaper way to catch errors early.

The limit lies in the model. According to a survey of the gap between simulation and reality, there are no perfect simulators, so there is always a difference from the real world, called the reality gap. The survey describes the gap as many sub-gaps, each from the simulation failing to replicate a physical mechanism accurately, in dynamics, perception and sensing, actuation and control, and system design. So every passing result is valid only for the part that was modelled.

• Virtual model
• Real home
• Dynamics
• Perception and sensing
• Actuation and control
• System design

What does each of the four simulation layers check?

Each layer checks a different group of faults, so all four are needed. The table below is one way to split them, with a typical tool for each; the next three articles go deep on circuits, firmware and motion.

The ngspice site describes an open source spice simulator for electric and electronic circuits. According to the Wokwi documentation, it simulates Arduino, ESP32, STM32 and many other boards, parts and sensors, and offers Wi-Fi simulation so a project can use MQTT, HTTP or NTP. With Gazebo, users interact with a running simulation by publishing and subscribing to topics over Gazebo Transport or ROS, which is how a controller on a computer can connect.

Once a real board exists, hardware in the loop adds another check. One hardware-in-the-loop framework shows the effect of delays, noise and saturation on a control system.

• Circuit layer
• Firmware layer
• Motion layer
• Fleet layer
• Part not yet checked

How do you write a pass criterion for each layer?

A pass criterion is one sentence with a condition, an expected result and a way to measure it, so anyone running it reaches the same verdict. NASA's requirement checklist asks whether requirements are specified in a measurable, verifiable manner and whether all requirements are bidirectionally traceable to higher-level requirements. The table applies that idea to the illustrative design; the content of each criterion is a design proposal.

The "Result" column is filled only after a run. Bidirectional traceability means each row points up to its source requirement, and each requirement points down to the test that checks it.

• Source requirement
• Simulation test
• Pass result
• Fail result
• Two-way traceability

How does one requirement cross all four layers?

One requirement usually needs evidence in several layers. Take "on link loss, stop mopping and return to the dock" as a hypothetical example:

1. Circuit: with the pump off, the supply still gives the motors and the microcontroller enough power while the robot drives home.
2. Firmware: the heartbeat timer expires, the state machine cuts the pump and stops the wheels within its time budget, then permits a return only with valid navigation data. A separate lost-localization test confirms it remains stationary.
3. Motion: the virtual robot starts in a far zone, drives around a bed and a table, and docks successfully across many runs.
4. Fleet: two robots lose the link and head to the dock together; robots enter only with permission from a modelled dock-side or local arbiter. If the lost central controller is the only arbiter, the correct outcome is separate holding positions outside the entrance, not a queue assumed to keep running.

Simulation exposes faults that reading code can miss. Suppose that in the firmware layer, repeated reconnection attempts keep resetting the heartbeat timer, so the pump never stops. The fault shows up when the link is cut many times in simulation, and the code is fixed before any board exists.

• Link lost
• Circuit lane
• Firmware lane
• Motion lane
• Fleet lane

When should you stop simulating and build?

Stop when the criteria of all four layers pass and the remaining risk can only be measured on a real prototype. Four typical items belong there: how the damp pad wets the floor, battery chemistry, real Wi-Fi radio in a home and floor friction. They sit among the sub-gaps described above, which a model struggles to reproduce accurately.

A prototype is the costliest technique, so build the smallest one that measures exactly those things. Feed the measurements back into the model so later simulations sit closer to reality.

• Frame of what only a prototype measures
• Four layers passed
• Damp pad wetting
• Battery
• Wi-Fi radio
• Floor friction

Real-world example

Someone is about to buy parts. Before ordering the pump, they build the supply circuit in a circuit simulator and see the voltage dip when the pump runs with a motor. They add a smoothing capacitor in the model and rerun it. Only when the model passes do they order parts, and the first prototype is used to check whether the model was right.

Common misunderstandings

A passing simulation means the robot will run well in a home. The result holds only for what was modelled; the reality gap is always there.

Motion simulation is enough. Circuits and firmware have faults of their own that a motion simulator cannot see, such as a voltage dip or a heartbeat timer that keeps resetting.

Once simulated, no prototype is needed. The damp pad, the battery, Wi-Fi and friction still have to be measured on a real prototype.

Frequently asked questions

Can simulation replace a prototype?

Not completely. Simulation catches faults early and cheaply, while a prototype measures what a model struggles to reproduce.

Which layer should I simulate first?

Start with the layer where a fault costs most in the real build, usually the power supply and the firmware's safety logic. This is a design suggestion and depends on the project.

Do I need a real board to simulate firmware?

No. A simulator such as Wokwi runs code for ESP32 with Wi-Fi, so you can write and test code before the board arrives. Real timing and radio still need measuring on a real board.

Summary

• Simulation gives evidence inside a model; the reality gap means each result holds only for what was modelled.
• Four layers, circuit, firmware, motion and fleet, each have a testable pass criterion traced to a source requirement.
• Stop simulating when all four layers pass, then build the smallest prototype to measure the damp pad, battery, real Wi-Fi and friction.