How Do You Simulate Robot Motion in a Virtual Home?

• Bed with the gap underneath
• Doorway threshold
• Table with four legs
• Items on the floor
• Dock with a robot

What you will learn

• Compare simulators by what a small indoor robot needs.
• Build a virtual home, a robot and simulated sensors, then link them to ROS 2 and the real controller.
• Set acceptance criteria for repeated runs and understand what one passing run proves.

Before you start

Read the article on the layers of mop-robot simulation and the one on a path that covers a whole room. The article on testing drone commands in a simulator is about aircraft, so this one does not repeat it.

Which simulator suits a small mopping robot?

Pick one with physics, simulated sensors, a bridge to ROS 2 and room for many robots in one world. According to the ROS 2 documentation, several advanced simulators work with ROS 2, for example Gazebo and Webots, and they give fairly realistic results because they use physics-based models of robots, sensors, actuators and objects.

The table lists what each tool's documentation says. The last column is design reasoning, not a tested result.

For a differential-drive robot indoors, Gazebo has the pieces a fleet needs: a differential drive controller that attaches to a model with any number of left and right wheels, simulated sensors and a ROS 2 bridge. That is why it is used for illustration, not a conclusion for every project.

• Candidate simulators
• Three requirement filters
• The chosen simulator

How do you build the virtual home, robot and simulated sensors?

Build a world described in SDF and place the home, the robots and the sensors in it. A world described in SDF can hold multiple robot models, so the whole fleet shares one scene.

The virtual home should contain exactly what makes a mopping robot's job hard: a bed with a measured clearance gap, a doorway threshold, table and chair legs, and a few things lying on the floor such as a cable or shoes. Add a stair edge or a step too, because the robot must not fall.

The robot is a low model with two differentially driven wheels. Sensors follow the Gazebo sensors tutorial, which adds an IMU, a contact sensor and a lidar to a robot. In the illustrative design the forward distance sensor is a simulated lidar casting a few rays, and the cliff sensor is a ray pointing down at the floor. Wheels can slip against the floor while encoders still measure wheel rotation; the IMU carries noise. Model slip at the wheel–floor contact rather than treating the encoder itself as slipping.

Add the noise on purpose. A survey of the reality gap notes that simulated depth sensors typically assume ideal depth projections and often omit real-world artifacts such as quantization noise and depth shadows. Sensors that are too clean make a test easier than reality.

• Forward distance rays reaching an obstacle
• Cliff ray at the step edge
• IMU inside the body
• Wheel with encoder and slip marks

How do you connect the simulator to ROS 2 and the real controller?

Connect them through a bridge, so the real controller program runs without knowing it talks to a simulation. The ros_gz_bridge package exchanges messages between ROS 2 and Gazebo Transport, so simulated sensors flow into ROS 2 and wheel commands flow back.

For a fleet, each virtual robot has its own name and message channels. The controller and tests must share simulation time so pausing or speeding up does not corrupt deadlines. In this model, and the central controller sees them as it would see real robots. The Wi-Fi link between the computer and the robot is replaced by a channel inside the simulation, which lets a test insert a link cut at an exact second.

Wet cleaning is not part of this simulation. It does not model the physics of a damp pad; instead the simulation records which floor cells the robot has passed over as a map of cells swept by the modelled pad, including position uncertainty. This is geometric coverage, not confirmation of cleanliness. Wetness, dryness and pad grip can only be measured on a real prototype.

• Virtual world with three robots
• Bridge
• ROS 2 node network
• Real controller program
• Injected link cut

How big is the gap to reality, and how do you accept a run?

The gap always remains, so simulation is for removing faults early. The ROS 2 documentation expects what you observe in simulation to be very close to what you get when moving your controllers to a real robot. The survey above defines the reality gap as the difference between a simulated and a real environment in dynamics, perception and sensing, actuation and control, and system design. Both hold at different levels: close for the controller software, far for the real floor, wheels and sensors.

Accept the design through repeated runs with preset conditions, measuring the same indicators each time. This is a design proposal:

One passing run only shows that this scenario works. You need many runs with changing start positions and obstacles, and you need to read the failed ones too. A pass in simulation justifies building a prototype; it does not show that a real floor ends up dry.

• Passing runs
• Failed runs
• Runs with a link cut

Real-world example

This is a design scenario. A virtual robot starts at the dock, drives to the bed and enters the gap underneath to mop. The simulated distance sensor reports a bed leg, and the downward ray reports that floor is still there.

Midway, the test cuts the link between the controller and the robot. The robot stops receiving commands, stops the pump, enters its safe state, backs out from under the bed, crosses the doorway threshold and returns along a valid local route with working localization. Another run removes localization data and requires the robot to remain stopped rather than continuing home. The recorder keeps the cells cleaned before the cut, and once the link returns the controller assigns the remainder. The run records a successful dock, no fall and full coverage. In another run of the same scene, a cable blocks the way under the bed and the run ends with one blocked cell that the robot reports.

Common misunderstandings

A pass in simulation means the real robot passes. Simulation and reality differ in dynamics, sensors and actuation, so a pass only removes faults early.

Simulated sensors give readings like real ones. Simulations often leave out real noise; add noise and slip on purpose.

Motion simulation tells you whether the floor is dry. The physics of a damp pad is not built here, so dryness is measured on a real prototype.

Frequently asked questions

Should I use Gazebo or Webots to simulate a mopping robot?

The ROS 2 documentation names both as usable with ROS 2. This article uses Gazebo for illustration because it has a ROS 2 bridge, a differential drive controller and sensors. If you already know Webots, it remains a valid choice.

Can I simulate many robots at once?

Yes, because one Gazebo world can hold multiple robot models. How many run smoothly depends on your computer, so try it on your own machine.

How many runs count as a pass?

There is no general number. Set the number of runs and the pass rate according to the risk you accept, and vary the start positions and obstacles between runs.

Summary

• Choose a simulator with physics, sensors, a ROS 2 bridge and many robots; Gazebo has all of those pieces.
• Build a home with a bed gap, a threshold, a stair edge and clutter, add noise to the simulated sensors and connect the real controller through the bridge.
• Accept through many runs including link cuts; wet cleaning and dryness can only be measured on a real prototype.