M9-T1 — End-to-End SLAM System Architecture

Learning objectives

After this lesson, you should be able to:

• Turn an application into numerical requirements for accuracy, robustness, rate, compute and cost.
• Derive an error budget and decide which absolute aids a design needs.
• Select sensors, front end, back end and map representation by matching them to the requirements and environment.
• Specify monitoring, logging and failure handling as part of the architecture, and describe a test plan from simulation to field.

The problem and the intuition

A system designer is asked: “Make the robot know where it is.” That sentence is not a specification. How accurately, how often, where, for how long, with what happening around it, on what computer, at what price, and what should the robot do when it does not know? Each answer changes the design. A vacuum cleaner needs rough position, robustly, for pennies. A warehouse shuttle needs centimetres at 20 m/s. A survey drone needs a consistent map and accepts a sensor that costs more than the vehicle.

The architecture follows from the numbers. Start from the requirements, compute what drift the application can tolerate (an error budget), and the result tells you whether relative sensing is enough or whether you need an absolute reference such as a prior map, a loop closure or a beacon. Then check the compute budget. Only then choose algorithms. Doing it in the opposite order, choosing a favourite algorithm and discovering the problems in the field, is the usual source of expensive surprises.

Requirements → budgets → sensors and algorithms → monitoring and logging → tests. The algorithm is chosen by the budgets, not the other way round.

The design method

Problem. Design a localisation and mapping system that meets stated requirements in a stated environment, with documented failure behaviour and a verification plan.

Assumptions. The application and environment can be described well enough to write requirements; the available sensors, computer and budget are known; the system is part of a larger robot with a planner and a safety layer that consume its outputs.

1. Write requirements as numbers. Accuracy (for example 5 cm RMS in the map frame for docking, 20 cm elsewhere), update rate (10 Hz pose, latency under 50 ms), coverage (area, distance without a loop), duration (hours), environment (static, people, lighting, GNSS), failure budget (missions per failure), compute (cores, memory, power) and cost.
2. Derive the error budget. Dead-reckoning drift grows with distance: σ(d) ≈ ε d. If the allowed error is e_max and the longest stretch without an absolute correction is D, then relative sensing alone suffices only if ε D < e_max. Otherwise an absolute aid (loop closure, map matching, beacons, GNSS) must bound the error, with enough coverage that D is never exceeded.
3. Choose sensing. Match the sensor to the failure modes of the environment (M5, M6, M8-T4): a 2D lidar for indoor structured floors; 3D lidar and IMU for outdoor or multi-level; stereo or RGB-D plus IMU where lidar is too costly; add wheel odometry and an IMU almost always, since they are cheap and cover each other’s weaknesses.
4. Choose the estimator. Filter-based odometry for low latency and low compute; pose-graph back end for loop closure and consistency; a prior-map localiser for repeated operation (M7-T5). Prefer established components (M8-T9) and isolate research components.
5. Choose the map. The map should serve the consumers: an occupancy grid for 2D planning, a feature map for relocalisation, a mesh or semantic map if the task needs it. Decide what is stored (graph and scans, M7-T6) and how it is versioned.
6. Design the interfaces. Frames and transforms (M7-T2), time stamps (M7-T3), message types and QoS, parameters; define who publishes what and with which guarantees.
7. Design monitoring and failure handling. Degeneracy eigenvalues, inlier counts, covariance, consistency, loop-closure verification outcomes, timing and CPU; thresholds that trigger degraded modes (slow down, stop, relocalise, ask for help).
8. Design logging and evaluation. Record raw sensor data, parameters, versions and outputs for every run so that any failure can be reproduced and every metric recomputed (M8-T8).
9. Plan the tests. Unit tests of components; simulation with injected faults (M8-L4); replay of recorded data; staged field tests with safety limits; long-duration tests for the failure rate.

ε

drift rate of dead reckoning, as a fraction of distance travelled.

D_max

longest distance (or time) between absolute corrections.

e_max

allowed position error for the application.

degraded mode

a planned reduced-function behaviour when health signals are poor.

Interfaces between the boxes

A worked design: a warehouse shuttle

1. Requirements. An indoor shuttle in a 120 m × 60 m warehouse with 100 m aisles. Docking accuracy 5 cm at 24 stations; elsewhere 15 cm. Pose at 10 Hz with latency under 100 ms. Forklifts and people move. 16 hours a day. Failure budget: at most one localisation-lost event per 1 000 missions. Computer: 4 ARM cores, 8 GB. Cost: under €1 500 for the sensing.
2. Error budget. A 2D lidar odometry with wheel and IMU drifts about ε = 0.5% of distance: over a 100 m aisle that is 0.5 m. The requirement is 0.15 m, so relative sensing alone fails already after about 30 m (0.15 / 0.005 = 30 m). Therefore an absolute reference is needed: localise in a prior map built once (M7-T5), so that the error is bounded by map matching, not accumulated.
3. Sensing and estimator. A 2D lidar (25 m range) at 10 Hz, wheel encoders, an IMU, and 24 reflective markers at the docking stations as fiducials for the 5 cm requirement. Mapping offline with SLAM Toolbox and loop closure (M7-T4); operation with SLAM Toolbox localization or AMCL on the saved map (M7-T5, M7-T6); the markers give absolute fixes at the docks.
4. Weak spots from the environment. The 100 m aisles with parallel racks are degenerate along the aisle (M8-T4): scan matching alone will not see forward motion. Wheel odometry (information-form fusion, M8-L3) and fiducials at the aisle ends cover it. Moving people and forklifts: log-odds clearing and a static map (M8-T1). Racks rearranged every month: a re-mapping procedure with verification.
5. Compute budget. Localisation with 2 000 particles costs about 1.4 million likelihood lookups per second (M7-T5), under 0.3 core. Mapping runs offline. Nav2 and perception take one core each. Estimated utilisation at p99 of 0.6 (M7-T8): within the 0.7 limit.
6. Monitoring and failure handling. Scan-match eigenvalues, localisation covariance, particle spread, TF timing, CPU. If the covariance exceeds 0.3 m or the match score falls: slow to 0.3 m/s; if it stays high for 5 s: stop and call global relocalisation; at the next fiducial, snap. Every event is logged.
7. Verification. Simulation with injected faults (false matches, clock offsets, dropout) to check the monitors; replay of three recorded days; 2 weeks of supervised operation. The failure budget of 1 in 1 000 missions needs about 3 000 failure-free missions to support at 95% confidence (M9-T2).

Engineering implications and limitations

Engineering implications

• Write the requirements and the budgets first, and review them with the customer. Most late-stage problems are requirements that were never stated.
• Keep an absolute reference in the design whenever the error budget shows that drift will exceed the requirement.
• Make health observable. Every stage should expose a quantity that says how well it is doing, and the supervisor should act on it.
• Define degraded modes and test them. A system that fails safely is more valuable than one that is accurate until it is not.
• Log everything needed to reproduce a run: raw data, parameters, software versions, calibration, ground truth if available.
• Change one thing at a time and re-run the evaluation suite; keep the baseline.

Limits

The method is a framework, not a recipe. Requirements are uncertain until the robot is in the real environment; budgets rest on estimates (a drift rate of 0.5% is an assumption to be measured). Interactions between components, for example a timing error that looks like a degenerate scene, are found by testing, not by design. And no architecture removes the need to validate the system in the actual place and conditions in which it will work.

Common misconceptions

Engineering takeaways

1. Start from requirements as numbers: accuracy, rate, latency, coverage, duration, environment, failure budget, compute and cost.
2. The error budget ε D ≤ e_max shows whether relative sensing suffices or an absolute aid is needed.
3. Choose sensors for the failure modes of the environment and estimators by the budgets, preferring established components.
4. Design monitoring, logging, degraded modes and a test plan as part of the architecture.
5. The warehouse example needs a prior map plus fiducials because 0.5% drift exceeds 15 cm after 30 m.

References and further reading

Primary papers and authoritative documentation.

• Durrant-Whyte, H. and Bailey, T. (2006). Simultaneous localization and mapping: Part I. IEEE Robotics & Automation Magazine 13(2).
• Bailey, T. and Durrant-Whyte, H. (2006). Simultaneous localization and mapping (SLAM): Part II. IEEE Robotics & Automation Magazine 13(3).
• Cadena, C. et al. (2016). Past, present, and future of simultaneous localization and mapping: Toward the robust-perception age. IEEE Transactions on Robotics 32(6).
• Thrun, S., Burgard, W. and Fox, D. (2005). Probabilistic Robotics. MIT Press.
• Macenski, S., Foote, T., Gerkey, B., Lalancette, C. and Woodall, W. (2022). Robot Operating System 2: Design, architecture, and uses in the wild. Science Robotics 7(66).
• Groves, P. D. (2013). Principles of GNSS, Inertial, and Multisensor Integrated Navigation Systems, 2nd ed. Artech House (error budgets).

Knowledge check

Three conceptual questions. Write an answer, then reveal the explanation. Your answers stay in your browser.

What’s next

A design is a set of tradeoffs, and a report must justify them with evidence. The last lesson covers how to make and defend those tradeoffs, and how much testing a claim of reliability needs.

Related content

Nothing below is required to finish this lesson.

• Before
  M8-T9: Current Research Directions

  Distinguish established practice from open problems and read the current literature critically.

• Lab
  M9-L1: Build and Debug an End-to-End SLAM Pipeline

  Assemble odometry, scan matching, pose graph, mapping and evaluation, diagnose injected failures and write an engineering report.