Up to this point we've assumed ARCHO has a single computer running everything — from Nav2 to motor control. In the real world, that assumption rarely holds. A real robotic platform typically consists of three different hardware layers, each optimized for its own job.
Motor control needs a very fast, predictable real-time loop — for example, a thousand times per second. A regular Linux computer that's simultaneously running Nav2, SLAM, and image processing cannot guarantee that timing. That's why industrial architectures separate motor control from heavy processing.
NVIDIA Jetson is designed for heavy processing tasks:
It's better for the Jetson to send high-level commands (like target velocity) to a separate microcontroller over CAN, Ethernet, or Serial, rather than controlling the motor driver directly itself.
Jetson
│
▼
CAN / Ethernet / Serial
│
▼
Microcontroller
│
▼
Motor Drivers| Important Jetson consideration | Why it matters |
|---|---|
| Power and cooling | Heavy processing generates significant heat and needs proper cooling |
| Storage space | AI models and logs can take up a lot of space |
| JetPack version | Driver and library compatibility depends on the JetPack version |
| CUDA compatibility | Every AI model is tested against a specific CUDA version |
| Automatic node startup | After a power outage, the system must come back up without human intervention |
| Log rotation | Without it, the disk gradually fills up |
| Watchdog and thermal limits | Prevents overheating and system freezes |
The Raspberry Pi is well suited to lighter workloads:
| Good for | Limited for |
|---|---|
| LiDAR driver | Heavy AI models |
| Sensor gateway | Multiple simultaneous depth cameras |
| ROS bridge | Heavy visual SLAM |
| Mid-level control, telemetry | |
| Lightweight educational robots |
Raspberry Pi
│
├── ROS 2
├── LiDAR Driver
├── IMU Driver
├── robot_localization
└── Basic Nav2An ESP32 usually doesn't run a full ROS 2 stack like a computer does. There are two common paths for connecting it to the ROS 2 world:
micro-ROS brings the familiar ROS 2 concepts — Publisher, Subscriber, Service, Timer — to microcontrollers. But because an MCU's resources (RAM, flash, CPU, networking) are far more limited than a computer's, the full ROS 2 architecture shouldn't be copied onto it as-is.
| Tasks suited to the ESP32 | Tasks not suited to the ESP32 |
|---|---|
| Reading encoders | SLAM |
| Motor speed PID | Nav2 |
| Reading simple sensors | Point cloud processing |
| Watchdog | Large AI models |
| Brake command and light control | |
| Sending telemetry |
If the ESP32 receives no new command from the upper layer for a set period (say, 300 ms), it must decide on its own to zero the motor command and apply the brake — without waiting for an instruction from the Jetson or Raspberry Pi. If the upper layer is disconnected for any reason (even a software crash), ARCHO must not keep moving on the last command it received.
No command for 300 ms
↓
Motor command = 0
↓
BrakeThis is one of the most important safety principles in any real industrial robot — and because it is so critical, it must be implemented independently of the entire upstream software architecture, directly on the microcontroller.
In an industrial version of ARCHO with a picking arm: the Jetson is responsible for Nav2, AI-based object detection, camera, and visual SLAM. These high-level decisions are sent over a communication link (CAN or Serial) to a microcontroller (ESP32 or STM32), which itself directly reads the encoder, closes the motor PID loop, runs the watchdog, and responds to the Emergency Stop button — completely independent of whether the Jetson is healthy or not.
| Layer | Primary responsibility |
|---|---|
| Jetson | Heavy processing: AI, perception, visual SLAM, Nav2 |
| Raspberry Pi | Gateway or lightweight processing: LiDAR driver, telemetry |
| MCU (ESP32/STM32) | Real-time control: encoder, PID, watchdog, emergency stop |
Now you know why a real ARCHO rarely runs on a single computer. Heavy processing (Jetson), a lightweight gateway (Raspberry Pi), and direct real-time motor control (ESP32 with an independent watchdog) each play a different role, and this separation improves both performance and system safety.
ARCHO Project now has a three-layer hardware architecture: a Jetson for Nav2 and AI, and an ESP32 with an independent watchdog for direct motor and encoder control.
In Chapter 17 we move to the industrial networks that actually connect these layers together: CAN bus and EtherCAT.