· By Sajeevan (Saj) Veeriah
Robotics · 4 min read
Before tuning a robot, check what it thinks is moving
A practical way to separate coordinate-frame, timing and localisation faults before changing a navigation controller.
A robot turns in place, but the wall in its laser scan seems to slide across the room. It is tempting to open the controller settings and start changing gains. First, check whether the robot's picture of the world is consistent.
My rover portfolio record combines a physical platform with simulation-validated autonomy. The distinction matters: simulation is useful for repeatable diagnosis, while physical testing introduces mounting errors, wheel slip and timing behaviour that a clean simulation may not reproduce. The diagnostic sequence below is a proposed method, not a report of additional tests on that rover.
Give each coordinate frame one job
ROS REP 105 defines a useful division of responsibility. The base_link frame is fixed to the robot. The robot's pose in odom should change continuously, although it can drift. Its pose in map can receive discrete corrections from localisation. These are different behaviours serving different purposes.
The usual relationship is map to odom to base_link, with sensor frames attached beneath the robot. A localisation component provides the map-to-odom correction; an odometry source provides odom-to-base_link. Check who publishes each transform. Competing publishers can make a plausible diagram behave inconsistently.
Sources: [1]
Predict the observation before running the test
Choose a simple scene with a flat wall and a clearly marked starting position. Keep the robot stationary first. Record the scan, transforms and their timestamps. If a stationary wall moves in the display, investigate the sensor data and transform path before interpreting that movement as a control problem.
Next, rotate slowly in a controlled test area. In the robot's frame, the wall should change position as the robot turns. In a stable world frame, the same wall should remain approximately fixed. This makes the selected display frame part of the test, rather than a cosmetic setting.
Use the following observations as hypotheses to investigate. None identifies a cause on its own.
| Observation | Next comparison |
|---|---|
| Wall shifts when the robot rotates | Compare the measured sensor mounting offset with the configured transform. |
| Pose jumps at localisation updates | Compare map-frame and odom-frame motion at the same timestamps. |
| Problem grows with speed | Compare sensor age, transform timing and wheel behaviour. |
| Repeated data produces different behaviour | Check configuration, clock source and other inputs that were not recorded. |
Turn timing into a physical distance
Consider an illustrative robot moving at 0.5 m/s. If an observation is interpreted as current when it is actually 0.2 s old, the robot travels 0.1 m during that interval. This is a simple displacement estimate, not a complete model of scan distortion or localisation error.
The calculation is distance = speed × time: 0.5 m/s × 0.2 s = 0.1 m. Before spending an afternoon tuning around a ten-centimetre discrepancy, establish whether measurements are transformed using their acquisition time and whether the relevant clocks agree.
Record acquisition time and reception time separately when the interface supports them. A delayed measurement can still be useful if the system handles its timestamp correctly. A recently received message is not necessarily a recent observation.
Change one layer and keep a comparison
Once frames and timing are credible, move through odometry, localisation, planning and control in that order. Save the inputs, configuration and expected observation for a short repeatable scenario. Change one relevant setting, rerun the scenario, and compare the result with the previous run.
Include a stationary test, a slow turn, straight travel and a deliberate localisation correction. Define acceptable movement or error before looking at the new result. Otherwise, a smoother animation can be mistaken for an improvement while another behaviour gets worse.
Carry the successful scenario to hardware with an appropriate test area, speed limit and stopping provision. A simulation pass establishes behaviour under that simulation's assumptions. Record the additional physical checks separately so another engineer can see exactly where the evidence ends.
Sources: [2]
Sources and further reading
Sources checked on 11 September 2026. The numeric example and diagnostic sequence are illustrative; they are not measured rover results.