Engineering Guides · Module 01

Writing a system integration plan

Integrate in the order the dependencies allow, test each step, and never add two unknowns at once.

Intermediate
Module 01: Robotics System Architecture & Requirements
Written for ROS 2 Jazzy where ROS 2 is used
Sources checked 2026-11-05

Assumptions: A practical template based on the NASA Systems Engineering Handbook; not a standard. All numbers in the example are illustrative and the code is executed by the site’s tests.

1. Engineering problem

Bringing every subsystem together at once makes a failure impossible to localise. A plan integrates in dependency order, with a test after each step, so a failure points to the last thing added.

2. When is this needed?

After interfaces are defined and before hardware arrives.
When a new subsystem is added to a working robot.
Before a field trial.

3. Selection and design decisions

Overview
Plan element	Content
Order	Dependency order: drivers, frames, safety, state estimation, mapping, navigation
Entry criteria	What must be true before the step starts (inputs available, previous step passed)
Exit criteria	A measurable check (rate, latency, error, recorded bag) that the step passed
Test environment	Bench, simulation, test area, field
Risks and fallbacks	What could go wrong and the fallback (stub, recorded data, simulation)
Owner and date	One person per step

4. Advantages and disadvantages

Big-bang integration is fast on paper and slow in practice; incremental costs planning and finds problems earlier.
Simulation first is cheap and does not reveal timing or electrical issues.
Stubs and recorded data let parallel teams proceed before all hardware exists.

5. Requirements and constraints

A step starts only when its dependencies have passed their exit criteria.
Each exit criterion is a number or a pass/fail test, not “looks fine”.
Cycles in the dependency graph are design errors to resolve (an interface to split).

6. Architecture

drivers ─▶ tf ─▶ imu_fusion ─▶ slam ─▶ nav
   └─▶ safety (parallel with tf)

7. Implementation

List the subsystems and what each depends on.
Compute the order (below); steps in the same level can run in parallel.
Write entry and exit criteria for each step from the requirements.
Name the stubs or recorded data used where a dependency is missing.
Record results after each step and update the plan.

deps = {"drivers": [], "tf": ["drivers"], "imu_fusion": ["drivers", "tf"], "slam": ["imu_fusion"], "nav": ["slam", "tf"], "safety": ["drivers"]}
done, order = set(), []
while len(done) < len(deps):
    ready = sorted(n for n, d in deps.items() if n not in done and all(x in done for x in d))
    if not ready:
        raise SystemExit("cycle in the dependency graph")
    order.append(ready)
    done.update(ready)
for i, level in enumerate(order, 1):
    print(i, level)

Printed (checked by the site’s tests):

1 ['drivers']
2 ['safety', 'tf']
3 ['imu_fusion']
4 ['slam']
5 ['nav']

Reading it: drivers come first; the safety function and the transform tree are independent of each other and can be integrated in parallel; state estimation needs both drivers and frames; SLAM needs state estimation; navigation comes last. A cycle raises an error instead of an order. The graph is an illustrative example.

8. Real examples

Example AMR: bring up drivers and check rates; publish the frame tree and verify with the transform tools; add the IMU filter and compare against odometry; run SLAM on a recorded bag; then close the loop with navigation, first in simulation, then at low speed in the test area.

9. Failure scenarios

Navigation integrated before the frames were verified, so tuning chased a transform error.
Every subsystem integrated in the same week.
Exit criteria written as “works”.
Missing stubs blocked a team for a month.

10. Troubleshooting

If a step fails, return to the previous passed step and diff what changed.
If a dependency is late, substitute a stub and mark the step’s result provisional.
If the order contains a cycle, break it with an interface or a stub.

11. Validation

The ordering example prints the levels above (checked by the site tests).
Each step has measurable entry and exit criteria.
Every exit result is recorded with date, version and data.

13. Further references

NASA Systems Engineering Handbook, Rev 2 (2017): ntrs.nasa.gov/citations/20170001761, integration and verification processes, read 2026-11-05.

Related on FixTheRobot

Odometry and Motion Models SLAM · Lesson