🎓 Lesson 13
D5
MQTT vs. DDS vs. ROS2 Topics: Choosing Your Communication Backbone
MQTT, DDS, and ROS2 are different ways for machines—like tractors, sensors, and drones—to send messages to each other reliably in smart farming systems.
🎯 Learning Objectives
- ✓ Explain the architectural trade-offs between MQTT, DDS, and ROS2 in terms of latency, reliability, and scalability
- ✓ Analyze a smart farming use case (e.g., real-time soil moisture coordination across 50 edge nodes) and select the optimal communication backbone based on QoS requirements
- ✓ Design a minimal communication architecture by mapping sensor/actuator roles to appropriate middleware patterns (e.g., telemetry → MQTT; closed-loop steering control → DDS)
- ✓ Apply DDS QoS policies (e.g., ‘Reliability: RELIABLE’, ‘Deadline: 100 ms’) to meet functional safety constraints in autonomous implement guidance
📖 Why This Matters
In autonomous farming, a malfunctioning communication layer can cause a $500K grain harvester to ignore a sudden obstacle—or delay frost-warning alerts to irrigation controllers by seconds that cost acres of crop. Choosing between MQTT, DDS, and ROS2 isn’t academic: it determines whether your system scales to 1,000 IoT soil probes, reacts in <50 ms to lidar-detected deer, or survives spotty 4G/LTE dropouts in rural fields. This lesson equips you to make engineering-driven, not tool-driven, choices.
📘 Core Principles
All three technologies solve message passing—but with divergent priorities. MQTT uses a central broker: devices publish to topics (e.g., 'farm/field7/soil_temp'), and subscribers receive copies—ideal for infrequent, best-effort telemetry. DDS eliminates brokers; nodes discover each other dynamically and negotiate QoS (reliability, durability, deadline) per data stream—critical for time-sensitive tasks like auto-steer correction loops. ROS2 inherits DDS’s underlying transport but adds standardized interfaces (e.g., ‘sensor_msgs::msg::Imu’), lifecycle management, and tooling (rviz2, ros2 bag)—making it powerful for full-stack farm robot development, yet heavier than raw DDS or MQTT. Understanding their layered responsibilities—network abstraction (MQTT), real-time data plane (DDS), and robotic system orchestration (ROS2)—is foundational.
📐 End-to-End Latency Budget Allocation
For closed-loop autonomous functions (e.g., implement depth control), total allowable latency must be partitioned across network, serialization, processing, and actuation. This formula ensures DDS/ROS2 configurations meet hard real-time constraints.
Latency Budget Partitioning
T_network ≤ T_total − (T_sensor + T_compute + T_actuate)Allocates maximum allowable network + serialization latency to meet end-to-end control loop deadlines
Variables:
| Symbol | Name | Unit | Description |
|---|---|---|---|
| T_network | Network and Serialization Latency | ms | Time from message serialization to deserialization at receiver, including transport and QoS overhead |
| T_total | Total Control Loop Deadline | ms | Maximum allowable time from sensor input to actuator output for stable closed-loop performance |
| T_sensor | Sensor Acquisition Delay | ms | Time from physical event to digital sample availability |
| T_compute | Controller Processing Time | ms | CPU time required for perception, planning, and decision logic |
| T_actuate | Actuator Response Time | ms | Mechanical/electrical delay from command signal to physical action |
Typical Ranges:
Autonomous tractor steering: 30 – 50 ms
Soil moisture telemetry upload: 1000 – 10000 ms
💡 Worked Example
Problem: An autonomous sprayer requires end-to-end control loop closure ≤ 80 ms to maintain spray swath accuracy within ±2 cm at 20 km/h. Known delays: sensor acquisition = 5 ms, controller compute = 12 ms, hydraulic actuator response = 18 ms. What maximum network + serialization latency can DDS/ROS2 contribute?
1.
Step 1: Sum non-network delays: 5 ms + 12 ms + 18 ms = 35 ms
2.
Step 2: Subtract from total budget: 80 ms − 35 ms = 45 ms
3.
Step 3: Allocate conservatively: reserve 30 ms for DDS network transport (including serialization, discovery, and QoS overhead), leaving 15 ms margin for jitter.
Answer:
The DDS transport layer must deliver messages within ≤30 ms (p99), which aligns with DDS implementations using shared memory (intra-process) or RT-capable UDP on Linux with PREEMPT_RT patches.
🏗️ Real-World Application
John Deere’s Operations Center uses MQTT for fleet-wide telemetry (fuel level, GPS position, engine hours) from >1M connected machines—prioritizing scalability and battery life over latency. Meanwhile, their See & Spray™ vision-guided system relies on ROS2 (with Cyclone DDS) for sub-50-ms coordination between camera inference nodes, path planners, and solenoid valve actuators—where packet loss or delay would misapply herbicide. When integrating third-party soil scanners, they bridge MQTT (for slow-changing calibration data) into ROS2 via the ‘ros2_mqtt_bridge’ package—demonstrating pragmatic coexistence, not dogma.