Validating the transition

1. Engineering problem

Handover logic can look fine on one run and fail on another. The frames have rules: the local frame must be smooth for controllers, the global frame may correct itself but by a bounded amount. Measuring discontinuities over many crossings shows whether the design meets them.

2. When is this needed?

• Before releasing a robot that crosses building boundaries.
• After any change to fusion, gating or maps.
• When comparing two handover designs.

3. Selection and design decisions

REP 105 (read 2026-11-05) states that odom is continuous (no discrete jumps) but drifts, and that map does not drift but can have discrete jumps. A transition test therefore records the pose of the robot in odom and the map → odom transform over each crossing and checks (1) that no step in odom exceeds what the speed allows, (2) the size of every jump of map → odom, and (3) that the planner and controllers tolerated it without stops or oscillation.

4. Advantages and disadvantages

• More crossings give confidence and cost time; vary speed, direction, weather and time of day.
• Instrumented reference (a surveyed path) gives error; discontinuity needs none.
• A tight jump limit forces smoother fusion.

5. Requirements and constraints

• The requirement values are written before testing.
• Crossings cover both directions and the ODD’s conditions.
• All frames and their publishers are recorded in a bag.

6. Architecture

bag of crossings ─▶ odom step check ─▶ map→odom jump check ─▶ recoveries and stops ─▶ pass/fail per crossing

7. Implementation

1. Define requirements for jump size and recoveries.
2. Record bags of crossings with /tf and the localisation outputs.
3. Compute steps and jumps (below).
4. Review failures and fix the cause.
5. Repeat the full set after each change.

import math
def discontinuities(poses, dt, vmax):
    out = []
    for i in range(1, len(poses)):
        step = math.dist(poses[i - 1], poses[i])
        if step > vmax * dt * 2:
            out.append((i, round(step, 2)))
    return out
odom_jumpy = [(0.1 * i, 0.0) for i in range(10)]
odom_jumpy[6:] = [(x + 1.5, y) for x, y in odom_jumpy[6:]]            # a 1.5 m jump in a frame that must stay continuous
map_ok = [(0.1 * i, 0.0) for i in range(10)]
map_ok[6:] = [(x + 0.4, y) for x, y in map_ok[6:]]                    # a 0.4 m correction in the map frame
print("odom frame jumps:", discontinuities(odom_jumpy, 0.1, 1.0), "(REP 105: odom must be continuous)")
print("map frame jumps:", discontinuities(map_ok, 0.1, 1.0), "(allowed, but bounded and logged)")

Printed (checked by the site’s tests):

odom frame jumps: [(6, 1.6)] (REP 105: odom must be continuous)
map frame jumps: [(6, 0.5)] (allowed, but bounded and logged)

Reading it: a 1.5 m step in the odom frame is flagged (REP 105 requires that frame to be continuous), while a 0.4 m step in the map frame is allowed but reported (0.5 m including the normal 0.1 m motion). The pose lists are synthetic and illustrative.

8. Real examples

• 50 crossings of a loading dock door: largest map jump 0.18 m, odom never jumped, no recoveries.

9. Failure scenarios

• Only testing one direction.
• A fused filter that publishes odom with jumps because GNSS is fused directly into it.
• Not recording tf, so the cause cannot be found afterwards.

10. Troubleshooting

1. Find the time of the largest jump and look at which source changed.
2. Check whether the jump coincides with a mode change.
3. Check gating and covariances at that time.

11. Validation

• The checker prints the lines shown (executed by the site tests).
• All crossings meet the written requirements in every condition tested.

12. Engineering checklist

• Requirements written first
• Both directions and conditions
• tf recorded
• Steps and jumps computed
• Failures analysed
• Repeated after changes

13. Further references

• REP 105, Coordinate Frames for Mobile Platforms: rep-0105.rst, read 2026-11-05.

Related on FixTheRobot