Published field note · Research note
· 5 min read
A late robot command can be correct and still be wrong
Reliable delivery preserves bytes, not relevance; physical commands need source time, sequence, epoch, validity, and local admission before execution.
Relay, a fictional mobile manipulator in a workshop tool crib, sees the blue torque wrench at the front of shelf B. From observation S880, its planner generates command C42: move the wrist into the admitted pre-grasp region. The command is delayed in a reliable queue. During the delay, an operator moves the wrench and Relay’s application computer restarts. C42 finally arrives intact. Its target is plausible, its sender is authenticated, and its bytes are exactly what the producer sent. Executing it would still be wrong.
The missing property is not semantic correctness but temporal validity: permission for this command to influence this robot state during a bounded interval. That permission depends on facts the target coordinates cannot carry by themselves. Relay needs the source observation’s production time and sequence, the system epoch in which the command was created, an expiry or validity horizon, the goal and cancellation identity, and the physical envelope the lowest local controller will enforce.
An epoch is an identifier that changes when restart, reconfiguration, or an authority reset invalidates work from an earlier system instance. After Relay restarts from epoch 4 into epoch 5, C42 cannot regain authority merely because its delivery was retried. A local admission gate is the component beside execution that compares the command with current time, epoch, goal state, protective state, source age, and motion limits. For C42, the first mismatch is enough: epoch 4 is not epoch 5, so the gate records a rejection and produces no actuator effect. New command C43, generated from current state S932 in epoch 5, can proceed through the same checks.
Reliability is a transport property
ROS 2 exposes the distinction in its Quality of Service settings. History and depth govern queued samples; reliability governs whether delivery is best effort or retried; durability governs availability to late joiners; deadline, lifespan, and liveliness express different timing and availability expectations. Choosing reliable delivery does not by itself bound end-to-end latency or prove that the delivered command still describes the state in front of the robot.
Lifespan can help discard old messages in transport, but semantic validity may be narrower. A command can arrive within a generic transport lifespan after the wrench moved, after its goal was cancelled, or after the controller’s authority epoch changed. Conversely, an old inventory observation might remain valid for an asynchronous report even though it is unusable for collision response. The consumer that knows the physical use must make the final admission decision.
The ros2_control Controller Manager documentation describes a periodic read-update-write loop, update-rate configuration, scheduling and memory settings, overrun handling, and diagnostics. Those mechanisms provide a concrete place to observe timing and apply controller logic. They do not guarantee that arbitrary hardware, kernels, drivers, or application code meet a deadline, and they do not define Relay’s complete stale-command protocol.
Asynchronous learned policies make the issue easier to trigger, not unique to AI. The SmolVLA preprint decouples chunk generation from execution so a robot can keep executing while the next chunk is produced. That supports concurrency between model work and motion. It does not establish a production protocol for rejecting chunks derived from old observations; Relay’s source sequence, epoch, validity, and admission rules are book synthesis layered around the mechanism.
A credible countercase is a single-process controller over a private memory channel where commands are computed and consumed synchronously inside one measured period. Explicit epochs and network-style sequence fields may add no value if restart atomically clears all pending work and the controller can prove that no stale producer survives. Even then, the invariant still exists: a command is admitted only for the state and cycle that produced it. The implementation has encoded validity structurally rather than in a message.
What this does not prove
This note does not prove that ROS 2 reliable QoS is unsuitable for control, that timestamps alone make motion safe, or that rejecting stale commands defines a safe fallback. Clock synchronization, wraparound, queue bounds, cancellation races, restart persistence, and the physical protective response each need their own design and test. The bounded claim is simpler: successful delivery preserves a proposal; only local admission can grant current physical authority.
What field would let your lowest local controller reject a command that is semantically plausible but no longer valid for the state in front of it?
Open question
What I'm testing
What field would let your lowest local controller reject a command that is semantically plausible but no longer valid for the state in front of it?
Evidence boundary
Sources and boundaries
A linked source supports only its named role below. This note connects and tests ideas; the note itself is not evidence.
- official specROS 2 Quality of Service settings
Documents history, depth, reliability, durability, deadline, lifespan, and liveliness policies; reliable delivery alone does not guarantee bounded latency or current semantic validity.
- official specros2_control Controller Manager
Documents the read-update-write control loop and real-time settings for a named ROS 2 stack; configuration is not a complete deadline or safety guarantee.
- frontier preprintSmolVLA preprint
Provides an asynchronous chunk generation/execution example; the preprint does not specify or validate a production stale-command admission protocol.