E · System design challenge 1

Challenge 1: Design an Autonomous Mobile Robot

Design a robot that can deliver items in a building, then prove it on paper first and in the field second.

Uses modules 01, 02, 03, 05, 09, 13, 14
ROS 2 Jazzy

1. Problem statement

A facility needs a differential-drive robot to carry a 10 kg payload between rooms on one floor, with doorways down to 0.9 m wide and carpeted corridors, running for a full 8-hour shift with a 20-minute charge at lunch. People walk in the corridors. The robot must localise itself against a prebuilt map, plan paths, avoid people and carts, and stop safely.

Your deliverable is a design document (requirements, architecture, budgets, configuration choices, test plan) followed by a validated field report.

2. Constraints

Payload 10 kg; total robot mass limit 35 kg.
Top speed 1.0 m/s; acceleration 0.5 m/s²; steepest slope 5° (door thresholds and one ramp).
Doorways 0.9 m wide; corridors 1.5 m; the robot must pass people at 0.5 m clearance.
Indoor only: no GNSS. Lighting varies from bright to dim.
ROS 2 Jazzy on an onboard computer; no cloud dependency for driving.
Budget for sensors and compute is limited: you must justify every sensor.
Software safeguards are not safety-rated functions: any personnel-safety requirement needs a safety-rated stop (see Module 18).

3. Architecture

A reasonable starting architecture to critique and improve (this is not a prescribed answer):

2D LiDAR ─┐                                  ┌─▶ costmaps ─▶ Nav2 planner/controller ─▶ /cmd_vel
IMU ──────┼─▶ LiDAR (or LIO) localisation ───┤                                           │
wheel enc ┘        (map frame)               └─▶ TF map→odom                             ▼
                                                                     motor drivers ◀─ ros2_control
battery ─▶ BMS ─▶ fuse ─▶ DC-DC rails ─▶ computer, sensors, drivers        emergency-stop circuit (hardware)

Challenge subsystems
Subsystem	Decision to make	Where to look
Sensors	Which obstacle sensors cover your failure cases (glass, low obstacles, people)?	Sensor Selection Calculator, Sensor Comparison Tool
Motors	Torque, speed and gear ratio for the slope and payload	Motor Sizing Calculator and its guide
Power	Battery size for 8 h, charger strategy, converter ratings	Power Budget Calculator and its guide
Compute	Data rates, memory, stage times against core count	CPU/GPU Resource Estimator
Localisation	Which SLAM/localisation approach for your sensors	SLAM Selection Guide, Fusion Architecture Builder
Navigation	Footprint, inflation, controller, recovery	Costmap tuning guide

4. Implementation stages

Requirements. Turn the problem statement into numbered, testable engineering requirements (speed, clearance, runtime, localisation error, stopping distance, mission success rate). Mark each as functional or non-functional.
Sensor selection. Choose sensors with the calculator and the comparison tool, write the rationale and list the datasheet items you will verify. Identify how glass doors and low obstacles are handled.
Motor and gearbox. Size the motors for payload, slope and acceleration with a 1.5× margin; check a candidate motor’s rated, stall and no-load numbers against your result.
Power. Build the power budget, choose the battery and converters, check peak C-rate and the cable drop of the motor harness, and compute the 8-hour energy need including the lunch charge.
Compute. Estimate the data rates, memory and stage utilisation; choose the computer and explain which stage limits it. State what you measured versus what you assumed.
ROS 2 and frames. Define the frame tree, publish static transforms from the URDF and verify directions with test points (see the frame-conventions guide).
Localisation and SLAM. Choose and configure the localisation approach, integrate LiDAR and IMU (extrinsics and time), build the map, then verify localisation error against surveyed points.
Navigation. Configure Nav2 costmaps from the official parameters, set footprint and inflation for the 0.9 m door, and configure recovery behaviours.
Control tuning. Verify the robot tracks the commanded velocity, calibrate wheel radius and separation, tune the controller and check for oscillation.
Validation. Run the test plan: door passages, people in the corridor, a full-shift energy test, emergency-stop checks, and regression bags.

5. Validation criteria

Every requirement has a test and a recorded result.
Motor continuous torque with margin is below the rated torque; measured current agrees within 20 % of prediction.
Estimated runtime ≥ 8 h with the stated margin; confirmed by a discharge test within 15 %.
All streams fit the links at ≤ 70 % of nominal; no dropped messages in a 30-minute full-load run.
Localisation error against surveyed points within the requirement, on at least three separate days.
At least 95 % of 100 door passages and 95 % of 100 corridor deliveries succeed, with minimum clearance recorded (choose the thresholds from your requirements; these are examples).
Emergency stop stops the robot within the specified distance on every one of 20 trials from full speed, using the safety-rated stop path.

6. Engineering trade-offs

2D LiDAR vs 3D LiDAR or depth cameras: a single scan plane is cheap and light on compute but misses tables and low obstacles; 3D sensing covers them at higher cost and processing.
Larger battery vs payload and energy: more runtime adds mass, which raises motor load: iterate.
Margin vs cost: a 1.5× torque margin protects against the unknown but adds weight; measure rolling resistance on the real carpet to justify the margin.
Single computer vs distributed: simpler wiring and no network copies, but a single failure point.
Tight inflation vs door passage: wide inflation keeps distance from walls but may close the 0.9 m door in the planner’s eyes.

References

Use the guides and tools linked above; every number they produce is labelled with its assumptions. Product specifications must come from the datasheets of the parts you choose.