ROS 2's DDS middleware adds 2-5 ms of nondeterministic latency jitter per node hop, making it unusable for sub-millisecond servo control loops in force-sensitive robotic tasks

ROS 2's Data Distribution Service (DDS) middleware introduces serialization, deserialization, discovery overhead, and nondeterministic scheduling latency that accumulates across node boundaries in a typical multi-node robot control pipeline. Measured jitter ranges from 2.5 ms in idle conditions to 2.9 ms under CPU stress, with worst-case latencies far exceeding the 200-microsecond jitter budget required for 1 kHz force-torque servo loops used in contact-rich manipulation, grinding, polishing, and surgical robotics. Why it matters: ROS 2 is the de facto standard robot middleware with adoption across most academic labs and increasingly in industry, so robotics teams build their entire software stack on ROS 2 expecting it to handle all communication needs, so when they attempt to close high-frequency force-control loops through ROS 2 topics they encounter unpredictable latency spikes that cause force overshoot and oscillation, so teams must bypass ROS 2 entirely for real-time control paths by writing custom shared-memory or EtherCAT bridges, so the ROS 2 ecosystem fragments into 'ROS 2 for perception and planning' and 'custom code for control,' undermining the unified-middleware promise and doubling development and maintenance effort. The structural root cause is that DDS was designed for enterprise data distribution (military C4I, financial trading floors) where throughput matters more than deterministic latency, and its publish-subscribe discovery protocol, QoS negotiation, and serialization layers add irreducible overhead that cannot meet hard real-time deadlines on standard Linux, while the Preempt_RT kernel patches improve but do not eliminate jitter because the DDS libraries themselves contain non-preemptible code sections.