Door Control¶
In operation. Built and operated by Eric Cordero (accessibility/door-control).
Two robots in a corridor with a door need to know three things about each other: where the other one is, what it wants, and since when it has wanted it. That is the whole content of neighbour awareness.
Neighbour awareness¶
Every device broadcasts a short status frame. The field names are one or two letters because every byte counts against the 250-byte limit of the radio bridge.
| Field | Meaning |
|---|---|
s |
serial number of the sender — the identity |
x, y |
pose in metres |
h |
heading in radians |
m |
map name, not uid; falls back to the uid only if the chassis reports no name |
t |
sender timestamp |
st |
state, one letter out of c d p w e m i |
tp |
target point |
p |
priority; absent means 0, and 0 is not sent |
cl |
claim, today only "lift" |
ca |
moment of claiming — not of arrival |
r |
one bit: there is a lane to retreat to |
Two of these are the same lessons the fleet learned separately.
Map identity is the name, not the uid. The comment in the source says it plainly: comparing uids is what made every robot invisible to every other. The same mistake, found twice, in two systems, by two teams.
ca is the moment of claiming, not of arrival. It feeds the order of
precedence directly, and it is what stops the furthest-away robot from starving.
Identity is the serial number, not the MAC¶
The peer table is indexed by the serial number from the frame. The sender MAC is carried along — logged on first hearing, stored in the record, displayed on the awareness endpoint — but it decides nothing.
This has a practical consequence for anybody wanting to join over IP instead of the radio bridge: a neighbour arriving without a MAC breaks no rule. Bound to the radio transport are exactly two things: the 250-byte payload limit, and the fact that the sender MAC is a required field in the frame type. The HMAC-SHA256 signature (truncated to 128 bits), the group, and the clock window are transport-independent and reusable as they are.
Distances¶
| Value | Setting | What it is for |
|---|---|---|
| Blocking distance | 0.6682 m | two footprints — "is standing on my target" |
| Exit clearance | 1.5 m | leave a standing robot a way out |
| Substitute clearance | 1.0 m | how far in front of a target still counts as arrived |
| Settle range | 2 × conflict distance | from when an occupied target becomes my problem |
| Parked grace | 15 s | how long parked before the target is given up |
| Peer stale after | 3 s | freshness, on the local clock |
| Clock window | ±5 min | replay protection, not a freshness test |
What is deliberately not in this table
None of these asks whether there is enough room to dock or to turn at the target. That rule does not exist here yet and is being adopted from the fleet side, where it came out of a rotate timeout in the field: a robot that could not complete its turn where it stood. See Fleet.
Door areas come from the map¶
A door area is a polygon of regionType 5, and it does not coincide
with a circle around the door point. It is chosen per point, and a type-5
polygon wins as soon as it contains the point — so a broad slow-driving zone
cannot silently override a deliberately drawn door area.
Vendor numbers are never stored as such. They are translated into an own zone
kind, with the vendor number kept literally beside it; an unknown number becomes
"unknown" — never a guess and never a silent loss. The reason is on the record:
the published enumeration was wrong about one value, so the only admissible
evidence is an overlay carrying the zone, not a document naming it.