E · System design challenge 2

Challenge 2: Outdoor-to-Indoor Autonomous Navigation

A robot drives from a car park through a building entrance. The pose must stay continuous, and the robot must know what to do when the indoor localiser fails.

Uses modules 06, 07, 11, 12
ROS 2 Jazzy

1. Problem statement

A delivery robot starts on an outdoor path using GNSS, an IMU, a 3D LiDAR and wheel odometry. It approaches a building, GNSS degrades near the façade, and it enters a lobby where it must localise against an indoor map. Planners, controllers and the fleet system consume a single pose and must not see it jump.

Your deliverable is an architecture and a validation plan, supported by experiments in the Localization Handover Visualizer and recorded data.

2. Constraints

Outdoor GNSS accuracy and degradation near the building are measured on site, not assumed.
The indoor map is built separately; its registration to the outdoor frame has an unknown error.
Update rates differ: GNSS a few Hz; LiDAR-inertial odometry at the LiDAR scan rate; IMU much faster.
A single continuous pose must be available to Nav2 at all times; a discontinuity above a stated limit is a test failure.
The robot must recover if the indoor localiser loses track.
All timestamps and extrinsics must be verified; assume nothing synchronised until measured.

3. Architecture

IMU ───────────┐
3D LiDAR ──────┼─▶ LiDAR-inertial odometry (continuous, local frame) ─────────┐
wheel odometry ┘                                                              │
GNSS ───▶ GnssMonitor (reported accuracy + innovation) ─▶ gated absolute fix ─┤
prior indoor map ─▶ map localiser ─▶ absolute pose with covariance ───────────┤
                                                                              ▼
                                      offset estimator (covariance-weighted) ─▶ map → odom
                                      alignment estimated in the overlap          odom → base_link stays smooth
                                      slew-limited correction ─▶ Nav2

Frames
Frame	Meaning
`map`	Global/indoor frame in which planners work; may receive corrections
`odom`	Continuous local frame from odometry; never jumps
`base_link`	The robot
`gnss_enu` (conceptual)	Local ENU frame for GNSS fixes, tied to `map` by an alignment you estimate

4. Implementation stages

Sensor architecture. Choose and justify each sensor (Module 2); decide which provide absolute information and which relative, and how each fails at the entrance.
Coordinate frames. Define every frame, its parent and its publisher; verify directions with test points (frame-conventions guide).
Time synchronisation. Measure stamp-versus-receive latency per sensor and the LiDAR–IMU offset from recorded bags; decide the synchronisation scheme and the tolerance (use the Sensor Time Synchronization Simulator).
Calibration. Calibrate LiDAR–IMU extrinsics and validate; calibrate the GNSS lever arm; measure the indoor-map-to-GNSS registration at surveyed points.
State estimation. Choose the estimator structure (see the Fusion Architecture Builder): LiDAR-inertial odometry feeding an offset estimator, with covariance-weighted absolute inputs.
GNSS monitoring and gating. Implement and tune the degradation monitor on recorded approach data (see the GNSS-degradation guide).
Localisation handover. Reproduce the transition in the Localization Handover Visualizer with your measured parameters; choose alignment estimation, gating and slew limits; implement them.
Failure recovery. Specify what happens when the indoor localiser loses track (stop, creep on odometry, relocalise from the entrance, ask for help) and when GNSS returns on exit.
Validation. Drive the transition repeatedly in both directions with logging; analyse jumps, errors and recovery.

5. Validation criteria

Largest pose step (correction not explained by odometry) across at least 20 entries and 20 exits is below your limit.
Position error against surveyed doorway points stays within the requirement through the transition.
The measured map-to-GNSS alignment estimate is repeatable across runs.
Deliberately degraded GNSS (driving along the façade) does not corrupt the pose: the monitor switches before the error exceeds the limit.
Forced indoor-localiser failure (covering the LiDAR, moving a cart into view) leads to the specified safe behaviour and recovery.
The test data and configuration are saved so any run can be replayed from bags.

6. Engineering trade-offs

One estimator with changing weights vs switching estimators: one estimator avoids discontinuities but needs honest covariances; switching is simpler to reason about but puts the whole inconsistency into one step.
Align to the GNSS frame vs to the indoor map frame: the pose has to end up in one; aligning indoors to the map is usually what navigation needs, at the cost of a correction outside.
Slew-limiting the correction: hides jumps from controllers but delays the correct pose; planners must tolerate an evolving map-to-odom.
Tight vs loose coupling of the LiDAR-inertial block: tight is usually more accurate and more sensitive to extrinsics and time; loose is modular.

References

Tools: Localization Handover Visualizer, Sensor Fusion Architecture Builder, Sensor Time Synchronization Simulator. The visualiser is a one-dimensional teaching model; use it to understand mechanisms, not to predict your robot.