This chapter ties together everything from the previous chapters: the good news is that when you move from Gazebo to real ARCHO hardware, most of the architecture you built stays untouched.
| Layer | Does it change? |
|---|---|
| Nav2, SLAM, Controllers | No |
| TF naming, URDF | No |
| High-level topics | No |
| Hardware Interface (the lowest layer of ros2_control) | Yes — this is the only part that actually changes |
This is exactly why we emphasized separating the Hardware Interface from the rest of the architecture so strongly in Chapter 8. If that separation was done correctly, moving from simulation to reality is just a swap of the bottom layer, not a rewrite of the entire system.
robot_state_publisherrobot_localizationExactly the same reason you learned about Lifecycle Nodes in Chapter 12: if Nav2 activates before Localization is ready, it can make dangerous decisions. This Bringup order applies the same principle to the entire physical system.
Before ARCHO's very first movement on real ground:
cmd_vel is zero (before the test starts).Command positive
↓
Wheel rotates forward?If the answer is no, check these four things in order: motor direction, encoder direction, command sign, and driver mapping.
Never start at high speed. The safe sequence:
0.05 m/s
0.10 m/s
0.20 m/s
0.30 m/sAt each step, before increasing the speed, make sure ARCHO moves exactly as you expect.
You command ARCHO to drive 5 meters straight, but the actual distance traveled is 4.8 meters:
correction factor = 5 / 4.8 = 1.0417
new_radius = old_radius × 1.0417You command ARCHO to make one full rotation, but instead of 360 degrees it actually rotates only 330 degrees:
These are exactly the same parameters we set in controllers.yaml for
diff_drive_controller in Chapter 8 (wheel_radius, wheel_separation).
If these values don't precisely match ARCHO's real geometry, Odometry (Chapter 9) develops a systematic
error from the very start — and that error propagates directly into SLAM and Nav2 as well.
You must test that ARCHO actually stops under all of these conditions:
Remember how we emphasized an independent Watchdog on the ESP32 in Chapter 16? Here's exactly why: if you rely only on the ROS-level Watchdog and the very computer that ROS runs on crashes, no layer remains to stop ARCHO. Real safety comes from redundancy of layers, not from a single point of failure.
So that ARCHO comes back up on its own after any power outage or restart, without human intervention:
# /etc/systemd/system/archo-bringup.service
[Unit]
Description=ARCHO ROS 2 Bringup
After=network-online.target
[Service]
Type=simple
User=robot
ExecStart=/usr/local/bin/start_archo.sh
Restart=on-failure
RestartSec=3
[Install]
WantedBy=multi-user.target#!/bin/bash
# /usr/local/bin/start_archo.sh
source /opt/ros/jazzy/setup.bash
source /home/robot/archo_ws/install/setup.bash
exec ros2 launch archo_bringup real_robot.launch.pyWhen ARCHO is operating in a real warehouse without direct supervision, you need to be able to answer these questions:
| Tool | Use |
|---|---|
| rosbag2 | Full data recording for later replay and analysis |
| diagnostic_msgs | Standardized health reporting for each subsystem |
| /diagnostics | Central topic for aggregating health status |
| Prometheus or similar | Monitoring metrics over time |
| Log Rotation | Preventing the disk from filling up |
| Health Heartbeat | Quickly detecting when a subsystem has failed |
ros2 bag record \
/scan \
/imu/data \
/odometry/filtered \
/tf \
/tf_static \
/diagnosticsEven with the best Gazebo simulation (Chapter 7), the real world always has surprises in store:
| Simulation | Reality |
|---|---|
| Perfectly flat ground | Slip and unevenness |
| Ideal wheels | Wear, slight differences between wheels |
| Controlled noise | Real, unpredictable noise |
| Low, constant latency | Variable network and hardware latency |
| Clean sensors | Dust, direct light, surface reflections |
ARCHO has now gone from a Gazebo simulation to a real physical robot — with a controlled Bringup order, a complete Preflight Checklist, calibrated wheels, several independent safety layers, automatic startup with systemd, and a logging system that always tells you why something happened.
ARCHO Project now has a fully calibrated physical version that starts up automatically via systemd, records rosbag2 data for troubleshooting, and benefits from a multi-layered safety chain.
In Chapter 19 we move on to industrial-grade production standards: QoS, DDS, Diagnostics, and safety architecture — the things that take a project from "it works" to "reliable in production."