From Chapter 2 up to now, we've worked with Topics, Services, and Actions many times without ever asking how messages actually get from one Node to another. The answer to that question is one of the most important differences between ROS 2 and its predecessor (ROS 1): ROS 2 is built on top of an industry-standard Middleware called DDS.
If one out of a thousand LiDAR scans is lost, that's usually not a disaster. But if ARCHO's emergency stop command is lost, that can be dangerous. A map might be published late, but every new Subscriber should still be able to get its latest version — even if it comes online after the initial publication. That's why a single, fixed communication behavior for every message simply doesn't make sense.
QoS (Quality of Service) is exactly what tunes this: every Topic can have its own communication behavior.
| Mode | Behavior | Suitable for |
|---|---|---|
| Reliable | The message must be delivered; if a packet is lost, it is retried | Parameter Events, configuration, sensitive non-real-time commands |
| Best Effort | If the message arrives, great; if not, the next one comes along | Camera Stream, LiDAR, fast sensor data, weak WiFi networks |
| Mode | Behavior |
|---|---|
| Volatile | The Subscriber only receives messages published after it connects; it does not see earlier messages |
| Transient Local | The Publisher keeps the last piece of data so new Subscribers can also receive it — for example, for a Map |
| Mode | Behavior |
|---|---|
| Keep Last (depth=N) | Only the last N messages are kept |
| Keep All | All messages are kept up to the system's resource limits — this can consume a lot of memory |
| Policy | Meaning | Example |
|---|---|---|
| Deadline | How often, at minimum, a message must arrive | The LiDAR must publish every 100 milliseconds; otherwise a Deadline Missed is reported — very useful for Health Monitoring |
| Lifespan | How long a message stays valid | A velocity command from 5 seconds ago should no longer be executed |
| Liveliness | Whether the Publisher is still alive | If the motor command Publisher dies, the system can automatically zero the command |
Suppose ARCHO's LiDAR publishes with Best Effort, but a new Subscriber only accepts
Reliable. Result: the connection either never forms, or the expected behavior doesn't happen —
and the telltale sign is that /scan shows up in ros2 topic list,
but no data is ever received.
This command is exactly where you'll spot a mismatch between a Publisher and a Subscriber.
export ROS_DOMAIN_ID=20Systems with different Domain IDs usually don't see a shared ROS Graph. For example, one lab could use Domain 10 and another lab Domain 20 so their Discovery traffic doesn't mix.
Domain ID only separates Discovery — it does not encrypt or protect the communication. Relying on Domain ID or a WiFi password for real security isn't enough — this is something later chapters on security will explore further (if we continue down that path).
ROS Middleware — the layer that connects ROS 2 to an actual DDS implementation (such as Cyclone DDS or Fast DDS).
As we saw in the diagram above, this layer sits between rcl and the DDS itself
and lets ROS 2 switch between different DDS implementations without changing code.
QoS doesn't determine what data a message carries; it determines how reliably, persistently, freshly, and promptly that data is delivered.
Now that you understand DDS and QoS, it's a good time to review the four main ROS 2 communication types (which we worked with in Chapters 2 and 3) all together:
| Type | Suitable for | Example in ARCHO |
|---|---|---|
| Topic | Continuous data stream; the Publisher doesn't need to know who is listening | LiDAR Scan, IMU, Encoder, Battery Status, Camera Image |
| Service | Fast, short request/response; not suitable for long-running work | Reset Odometry, Clear Fault, Enable Motor, Get Firmware Version |
| Action | Work that takes time and needs Goal/Feedback/Result and Cancel | Navigate to Pose, Dock Robot, Follow Waypoints, Calibrate Wheels |
| Parameter | Configuring a Node's behavior; unsuitable for fast sensor data | max_velocity, wheel_radius, safety_distance, controller_frequency |
An industrial robot shouldn't just work; it must be able to answer the question: "Am I healthy or not?"
| State | Meaning |
|---|---|
| OK | Everything is normal |
| WARN | There's an issue, but it's not yet dangerous |
| ERROR | A serious error has occurred |
| STALE | The data we're receiving from this component is no longer up to date |
Example of a snapshot of ARCHO's status:
LiDAR: OK
IMU: OK
Battery: WARN
Motor Driver: ERROR
Camera: STALEBased on all these inputs, the Health Manager decides: should the mission continue? Should speed be reduced? Should ARCHO stop completely? Should the operator be notified?
A simple message that just says "I'm still alive." For example, the MCU sends a Heartbeat every 50 milliseconds. If the main computer doesn't see a Heartbeat for 300 milliseconds, it concludes the MCU has disconnected — exactly the same Watchdog principle we saw in Chapters 16 and 18.
now - last_scan_time > 0.5 second
↓
LiDAR Timeout
↓
Controller stop → Mission pause → Operator notification| Level | Example |
|---|---|
| Info | Map loaded |
| Warning | Battery below 30% |
| Recoverable Error | LiDAR temporarily unavailable |
| Critical Error | Motor overcurrent, Emergency stop active |
For example, if ARCHO's camera fails but Navigation can continue using only the LiDAR, the system moves to the DEGRADED state — not stopped, but with reduced capability. If the Encoder fails, this is a more serious error, and the system moves to FAULT.
We shouldn't assume that "because the ROS 2 Nodes are healthy, the robot is safe." Software can crash, the network can drop, a wrong Topic can get published, the CPU can hang, or an old command can mistakenly persist. That's exactly why real safety can't live in just one software layer.
| Type | Behavior |
|---|---|
| Normal Stop | The Controller smoothly brings speed down to zero |
| Protective Stop | A fast but controlled stop due to a detected human or hazardous obstacle |
| Emergency Stop | A fully hardware-level cutoff of actuator power — this must never be just a software Topic |
If Layer 1 (Nav2's intelligent collision avoidance) fails for any reason, the layers below it must still be able to contain the risk. This is exactly the lesson we learned in Chapter 18 about "one safety layer is not enough" — here we turn that principle into a complete six-layer architecture.
Safety Supervisor inputs: cmd_vel, LiDAR safety zones, Bumper, E-stop, motor faults, Localization quality, and battery status. Outputs: safe_cmd_vel, motor_enable, protective_stop.
| Zone | Allowed speed |
|---|---|
| Open warehouse area | 0.8 meters/second |
| Near humans | 0.3 meters/second |
| Docking area | 0.1 meters/second |
These limits can change dynamically based on the map, live LiDAR data, current position, mission type, and human presence.
When the Bumper is pressed, ARCHO must never immediately reverse without an automatic check first — an obstacle, or even a human, could be standing right behind it.
Real safety means that even when high-level software makes a mistake, the hardware and low-level control never allow a dangerous state to occur.
ARCHO now not only works, but also knows how to cope with unfavorable network conditions (QoS), how to report which part of its body is unhealthy (Diagnostics), and how to protect itself and the humans around it even when something goes wrong in software (multi-layer safety architecture). These are exactly the differences that separate a student project from a real industrial product.
ARCHO Project now has a Health Manager with four status levels, a Safety Supervisor with six independent safety layers, and properly tuned QoS Profiles for each type of data (fast sensor data versus critical commands).
In Chapter 20 — the final chapter of this path — we bring together everything we built across these 19 chapters and see ARCHO's complete final industrial architecture.