Teleoperation

Configuration

Admitting a resource profile

The profile states five storage capacities — for serializing, receiving, history, duplicate suppression, and safety events — along with the timing, how many independent network paths there are, and the largest sample allowed. Every one of them has to be positive, and there have to be at least two paths, or the profile is not a valid one.

Rather than checking those values wherever they are used, they are checked once when the profile is built, and a profile that fails cannot be constructed at all. Everything downstream then takes a profile that is already valid and does not re-check it.

A type whose size cannot be known

Creating an endpoint asks the sample type for its largest possible encoded size, and rejects three things in order: a type with no bound at all, one whose bound is larger than the configured sample capacity, and one whose bound is large enough to need splitting across messages.

The third rejection is the one specific to this profile. Splitting a sample is well-defined and Part 3 covers it, but it means a command arrives only when all its pieces do, and one lost piece costs the whole command. A control path declines that trade and requires commands that fit in one message.

Where the serialization buffers come from

Serializing a command needs somewhere to put the bytes. Allocating that per command is what the profile exists to avoid, so the factory allocates exactly as many blocks as the profile's serialization capacity, once, and hands one to each writer as it is created.

The count of blocks in the pool plus the count held by live writers is always the number the profile asked for. A block is never in both places, because taking it moves ownership rather than copying a reference, and dropping a writer moves it back. Line 6 covers the case where the pool gave out a block and endpoint creation then failed for its own reasons.

Receiving

Servicing UDP and shared memory

UDP datagrams arrive in bursts. Handling one per turn leaves the rest waiting; draining without a limit lets a busy network occupy the worker indefinitely. A turn therefore handles at most the configured number of UDP datagrams, then gives shared memory one nonblocking opportunity. Even a continuous network stream cannot prevent a notified local command from being considered.

Declaring a receive-buffer count is only a resource control if the service actually owns that many buffers and uses no others. Here it does: a turn fills slots from the first, stops at the first poll that finds nothing or when every slot is full, then hands each filled slot to the handler in order. After that finite batch, it checks shared memory once before beginning another turn.

Line 11 clears a slot after the handler returns rather than before it is called. The handler borrows the bytes for the duration of its call, so the slot cannot be refilled while it is running — which is what stops one datagram overwriting another that is still being examined.

Line 13 matters for shutdown. If a handler asks to stop, the slots after it still hold datagrams that will never be serviced, and leaving them marked as pending would make the accounting wrong for anything that inspects the batch afterwards.

Why both transports share one command state

A local shared-memory copy and a UDP copy can represent the same logical command. They therefore pass through the same reader history, authority state, sequence frontier, and duplicate window. If each transport kept its own state, accepting a command from one would not stop the other from accepting the same command again.

Shared memory still has its own authentication and decoding boundary. Only after that succeeds does it enter the common command policy. An idle check, duplicate, policy rejection, or security rejection leaves the worker running; a command-processing fault stops it through the same owned shutdown path as a UDP fault.

Admission

Suppressing a duplicate command

Sending each command over two independent paths is what makes one path failing survivable. When both paths work — which is most of the time — the receiver gets everything twice, and acting twice on "rotate 10 degrees" is not the same as acting once.

Each command carries an identity: which robot, which session, which authority epoch, which stream, and its sequence number. The receiver remembers the identities it has recently accepted and rejects a second arrival.

Remembering all of them would grow without bound, so it remembers a fixed number of the most recent, in a ring. When the ring is full the oldest entry is overwritten.

Why a full window is not an error

Most bounded structures in this series reject work when they fill up. This one does not, and the difference is what filling up means. A full assembly table means more samples are in flight than the deployment planned for. A full duplicate window just means enough commands have been accepted to fill it, which happens almost immediately and stays true forever. Reporting that as a resource fault would report a fault continuously during normal operation.

Why rejected commands are not remembered

The identity is recorded only for a command that was actually accepted — after it has passed the authority, ordering, freshness, and clock checks. A command rejected for arriving too early relative to its clock may become admissible when it arrives again on the other path, and recording the rejected copy would suppress the copy that would have worked.

Authority

Holding control authority

Only one operator may be driving at a time, and handing control over has to survive the messages involved being delayed or repeated. Authority is held as a session, an epoch that increases on every grant, and a flag saying whether it is currently active.

Revoking clears the flag but keeps the session and epoch. That is the part worth stating plainly, because discarding them looks tidier and is wrong: a later grant must carry a strictly newer epoch than anything seen before, and forgetting the epoch is what would let a replayed old grant be accepted after a revoke.

The race this closes

An operator is granted control at epoch 7. Control is revoked. The grant message for epoch 7 is delayed in the network and arrives again. If revoking had cleared the epoch, that grant is indistinguishable from a first grant and is accepted, and an operator who was removed is driving again. Because the epoch survives, the replayed grant fails the test on line 1.

What a progress argument does and does not add

Everything above is about what must not happen. A separate obligation covers the other kind of failure: a command copy that is selected for delivery and then simply never looked at. Each copy is either received and put through admission, or classified as lost, and either way it leaves the set of outstanding copies. Since that set only shrinks and the worker keeps servicing it, it eventually empties.

The claim is deliberately weak. It permits every copy to be lost. What it rules out is the receive machinery holding a copy forever without deciding about it, which no amount of checking that bad commands are rejected would catch.

Freshness without comparing host clocks

Robot-owned command deadlines

The robot decides how long a command may remain useful. It issues a permit tied to its current observation and control session, and keeps the expiry locally. The controller echoes that permit with its command. The robot checks the deadline using the same local elapsed-time clock that created it. No controller timestamp participates in this mode.

This is an optional application protocol above DDS, not a change to the DDS wire standard. It is separate from the timestamp-based admission mode described earlier. The owner is robot_control_session in C++ and RobotControlSession in Rust; both keep the operator lease and command windows together.

Issuing a permit

Let L be the configured command-window lifetime, A the maximum age of the robot observation, o its acquisition time, and t the robot's current time. The deadline is min(t + L, o + A). A new permit cannot make an old observation fresh. The owner rejects expired or future observations, invalid configuration, and arithmetic overflow.

Each permit contains the robot, session, authority epoch, observation, serial, and an unpredictable challenge. The robot stores the complete permit in one of W configured slots. Refreshes are separated by R, with W ≥ ceil(L / R); a still-live slot is never overwritten. The controller cannot choose or extend the stored deadline.

Acceptance requires both a live operator lease and an unexpired permit. Renewing the lease does not extend an existing permit. A successful handover, revocation, or lease expiry discards its grants; a rejected request preserves still-valid grants. Authorization loss retires the owner through its Security collaborator. UDP and SHM use that same owner.

What the deadline guarantees

A rejected command does not advance the accepted sequence. Admission at the exact deadline is rejected. These checks decide whether the robot may consider a command; they do not guarantee timely network delivery or that an actuator has executed it. DDS acknowledgement, robot admission, and actuator completion are three different events.

The product must qualify its robot clock, including suspend and drift, and the source of sensor timestamps and unpredictable challenges. Losing trust in that clock retires the owner. Defaults in a configuration file are tuning values, not validated clinical safety limits.