Robot works in simulation but not in reality

1. Symptoms

• A controller or planner works in simulation and oscillates, stalls or collides on the robot.
• Localisation is good in simulation and drifts on hardware.
• Timing-sensitive code fails only on the robot.

2. Possible causes

• No sensor noise, bias or dropouts in simulation.
• Zero latency in simulation.
• Unlimited acceleration or torque in simulation.
• Friction and slip differences.
• Calibration and frame differences (extrinsics, wheel radius).
• Real-time factor or time source differences (use_sim_time).

3. Measurements to collect

• The same step or trajectory test in both worlds.
• Stationary sensor recordings for noise.
• Latency of each sensor and of the command path.

4. Diagnostic commands

Commands are not executed by the site’s automated tests (they need a ROS 2 Jazzy installation or the robot).

ros2 param get /my_node use_sim_time
ros2 topic delay /scan
ros2 bag record /cmd_vel /odom /imu/data

5. Step-by-step investigation

1. Run the same test in both worlds and compare the shape, mean and spread.
2. Add measured noise and latency to the simulation.
3. Set acceleration limits and friction from tests.
4. Compare calibration (wheel radius, extrinsics).
5. Check time settings on every node.

6. Corrective actions

• Make the simulation conservative: add noise, latency and limits from measurements.
• Fix calibration differences.
• Retune on the more realistic model, then on hardware.

7. Validation after the fix

• The same test gives statistically similar results in both worlds.

References

• See the simulation-to-hardware differences guide.