FixTheRobot Explore Robotics / Systems Engineering / Engineering Guides / Module 05

Engineering Guides · Module 05

Example onboard computer architecture

One reasonable way to split a mobile robot’s software across a real-time microcontroller, a CPU and a GPU, with the reasoning for each boundary.

  • Intermediate
  • Module 05: Onboard Computer, CPU/GPU Selection & Compute Sizing
  • Written for ROS 2 Jazzy where ROS 2 is used
  • Sources checked 2026-11-05

Assumptions: An illustrative design for an indoor/outdoor mobile robot with one camera, one LiDAR and an IMU. No product is named; sizes follow the estimator and sizing guides with your own measured numbers.

1. Engineering problem

Where each piece of software runs decides latency, power and failure behaviour. This example shows a three-tier split and explains each boundary so you can adapt it.

2. When is this needed?

  • Designing the compute for a new mobile robot.
  • Reviewing an architecture for single points of failure.
  • Explaining the split to a team.

3. Selection and design decisions

TierRunsWhy here
Real-time microcontrollerMotor control loops, encoder reading, watchdog, hardware e-stop interlock, IMU readDeterministic timing; keeps the robot safe if Linux hangs
CPU (Linux, ROS 2)Drivers, LiDAR odometry/SLAM, localisation, Nav2, state estimation, loggingSequential, branching workloads and the ROS 2 ecosystem
GPUCamera preprocessing and neural-network detectionData-parallel work that repays the transfer

4. Advantages and disadvantages

  • One computer vs two: splitting perception onto a second computer isolates load but puts camera data on a network.
  • Microcontroller vs ros2_control on the main CPU: a microcontroller gives deterministic timing; ros2_control on the CPU is simpler but exposed to scheduling jitter.
  • Single point of failure: the main computer; the microcontroller keeps the safe-stop path independent.

5. Requirements and constraints

  • Sensor interfaces counted per tier (USB, Ethernet, CAN, UART).
  • Power and thermal budgets (see the selection guide).
  • Time synchronisation (PTP/PPS) reaching all tiers.
  • Safety-rated functions are separate from this architecture (see Module 18).

6. Architecture

                         ┌─────────────────────── main computer (CPU + GPU) ───────────────────────┐
camera ──USB3─────────▶  │ camera driver ─▶ [GPU] preprocess + detector ─▶ tracker ─┐                               │
3D LiDAR ──Ethernet───▶  │ lidar driver ─▶ deskew/filter ─▶ LiDAR-inertial odometry ─┼▶ localisation ─▶ Nav2 ─▶ /cmd_vel
IMU ──UART/USB────────▶  │ imu driver ──────────────────────────────────────────────┘                    │       │
                         └────────────────────────────────────────────────────────────────────────────────┼───────┘
                                                                                                          ▼
                              microcontroller: velocity control loops, encoders, watchdog ◀── /cmd_vel (heartbeat)
                                      │  motor drivers ─▶ motors                  e-stop hardware path ─▶ motor power

7. Implementation

  1. Interfaces: camera on USB 3.x, LiDAR on its own Ethernet port, IMU on a serial link that also carries a hardware timestamp or PPS, microcontroller on USB or CAN.
  2. Processes: group nodes that exchange big messages (camera → detector, LiDAR driver → odometry) into the same process to avoid copies; keep the planner and logging in separate processes.
  3. Placement: detector on the GPU; odometry, localisation and navigation on the CPU; control loops on the microcontroller; check with the CPU/GPU Resource Estimator and the allocation guide.
  4. Timing: one clock source (PTP or PPS) for LiDAR, IMU and camera; measure remaining offsets (bag-latency guide).
  5. Watchdog: the microcontroller stops the robot if the /cmd_vel heartbeat stops (an operational safeguard, not a safety-rated function).
  6. Logging: record sensors and estimates to a separate disk or at a measured rate that the storage can sustain.

8. Real examples

  • Simplest variant: no GPU, a CPU-only computer and a 2D LiDAR; the architecture stays the same without the GPU box.
  • Heavier variant: a second computer for perception connected by a dedicated Ethernet link; check the link budget.
  • Weight-limited variant: an embedded GPU module as the single main computer.

9. Failure scenarios

  • A hung main computer leaves the motors running (no watchdog on the microcontroller).
  • Camera frames copied between three processes and saturating a core.
  • Timestamps from different clock domains.
  • The GPU starved by a slow CPU pre-processing stage.

10. Troubleshooting

  1. Verify each tier alone (microcontroller loop, drivers, odometry), then together.
  2. Check rates and stamps at each boundary.
  3. Profile the main computer at full load (profiling guide).
  4. Pull the main computer’s power: the robot must stop.

11. Validation

  • A full-load hour with stable rates and no throttling.
  • Heartbeat loss stops the robot within the specified time on every one of 20 trials.
  • End-to-end latency from sensor to command measured and within budget.
  • Each tier’s power and temperature documented.

12. Engineering checklist

13. Further references

  • Site guides on throughput, workload allocation and profiling; the Module 18 overview for safety-rated functions.

Related on FixTheRobot