Design & Selection · Module 15

Matching simulated sensors and actuators to hardware

Simulation is a model. List the parameters that matter, set them from measurements, and state how close is close enough.

Intermediate
Module 15: Simulation-to-Real Integration
Written for ROS 2 Jazzy where ROS 2 is used
Sources checked 2026-11-06

Assumptions: Numbers in the examples are illustrative and the code is executed by the site’s tests. Facts taken from a cited source are marked; other statements are general engineering knowledge and must be confirmed on the datasheet of the part you use.

1. Engineering problem

A simulation with perfect sensors, zero latency and unlimited acceleration passes every test the real robot fails. Closing the gap means finding the parameters that drive the behaviour you care about and setting them from measurements.

2. When is this needed?

Before trusting simulation results for hardware decisions.
When a controller works in simulation and not on the robot.
When building a digital twin.

3. Selection and design decisions

Group the differences: sensor (noise, bias, rate, latency, field of view, range, dropouts), actuator (acceleration and velocity limits, delay, backlash, torque limits), environment (friction, surface, lighting) and timing (loop rates, real-time factor). For each, take the real value from a datasheet or a measurement (see the calibration, timing and motion-control guides in this track) and set a tolerance for the match.

Overview
Group	Parameters	Where to measure
Sensor	Noise sigma, bias, rate, latency, FOV, range	Datasheet; stationary recordings; bag latency analysis
Actuator	Max acceleration, max speed, delay, backlash	Step tests on the robot
Environment	Friction, ground, lighting	Slip and drive tests on the real floor
Compute	Loop rates, jitter	Profiling on the target computer

4. Advantages and disadvantages

More fidelity costs modelling and simulation time; match only the parameters your results depend on.
Domain randomisation (varying parameters over ranges) tests robustness when the exact value is unknown.
Simulation tuned to one robot may not transfer to a sibling.

5. Requirements and constraints

Each matched parameter has a source and a tolerance.
Parameters not matched are listed as known differences.
Results are only claimed for the matched regime.

6. Architecture

hardware measurements ─▶ parameter table (value, tolerance, source) ─▶ simulator configuration ─▶ comparison runs

7. Implementation

List the parameters that influence the behaviour under test.
Measure or look up each on the hardware.
Set the simulator and compute the mismatch (below).
Rerun the comparison and review the unmatched ones.
Record known differences next to every simulation result.

rows = [("lidar range noise sigma (m)", 0.0, 0.02, 0.005), ("lidar rate (Hz)", 10.0, 10.0, 0.05), ("imu gyro noise density", 0.0, 0.0002, 0.25),
        ("camera latency (s)", 0.0, 0.045, 0.1), ("wheel acceleration limit (m/s^2)", 5.0, 1.2, 0.1), ("friction coefficient", 1.0, 0.6, 0.2)]
print(f"{'parameter':36s}{'sim':>8s}{'real':>9s}  verdict")
for name, sim, real, tol in rows:
    err = abs(sim - real) / abs(real) if real else float("inf")
    print(f"{name:36s}{sim:8.4f}{real:9.4f}  {'matches' if err <= tol else 'differs by %.0f %%' % (err * 100)}")

Printed (checked by the site’s tests):

parameter                                sim     real  verdict
lidar range noise sigma (m)           0.0000   0.0200  differs by 100 %
lidar rate (Hz)                      10.0000  10.0000  matches
imu gyro noise density                0.0000   0.0002  differs by 100 %
camera latency (s)                    0.0000   0.0450  differs by 100 %
wheel acceleration limit (m/s^2)      5.0000   1.2000  differs by 317 %
friction coefficient                  1.0000   0.6000  differs by 67 %

Reading it: the lidar rate matches; noise (zero in simulation against 0.02 m), gyro noise, camera latency (zero against 45 ms), acceleration limit (5 against 1.2 m/s²) and friction (1.0 against 0.6) do not. The first four are the typical sources of a controller that works in simulation and not on hardware. The values are illustrative.

8. Real examples

Wheel controller: acceleration limit and latency set from step tests before the simulated controller is tuned.

9. Failure scenarios

Tuning a controller on zero-latency simulation.
Assuming default friction.
Not recording which parameters were matched.

10. Troubleshooting

Run the same test in simulation and on hardware and compare the response shape.
If the shape differs, find the unmatched parameter.
Add noise and latency first: they explain most gaps.

11. Validation

The comparison prints the table shown (executed by the site tests).
Simulated and real responses agree within the stated tolerances on the matched tests.

13. Further references

Gazebo Harmonic sensor tutorial: gazebosim.org/docs/harmonic/sensors, read 2026-11-06 (SDF sensor elements such as gpu_lidar and imu, with topic, update rate and ray scan settings).