The keyboard says where. The robot decides when. A person steers one robot through a maze with four arrow keys. The other robots receive the same game definition, determine their own roles from their own identities, and will act as pursuers once that behaviour is built. What matters here is not that a robot can be driven from a keyboard — it is that live human input was added to an autonomous system without changing the architecture it already had.
What you are seeing
A still of what is on screen while this runs. The filled dot is the robot being steered; the two outlined ones are others in the same game. Beside the floor is that robot’s own state.
- Role
- Runner
- Heading
- East
- Requested direction
- WestPending
- Corridor runs
- 7
The robot is moving east, but the operator has requested west. That request remains pending until the robot reaches a valid turning point.
The rule and the cell size are the source’s; the floor plan is drawn for this page. What a still cannot show is the body moving, which is what the recording is for.
The challenge
A character in a video game turns on the frame you press the key. A robot cannot. It is half a metre wide in a corridor a metre and a half across, it is already moving, and turning costs it room and time — some openings are narrow enough that it has to pivot to get through at all.
So the question is not how to make it obey faster. It is what a keystroke should BE, given that it cannot be obeyed at the instant it is pressed.
What happens when you press a key
Take the robot running down a corridor and the operator pressing left:
- The press is recorded rather than sent to the wheels.
- The robot keeps going — there is no left here to take.
- It reaches a cell where a turn is physically possible.
- There, the recorded direction is what decides, and the turn happens.
Press another direction before any of that happens and the new one replaces the old — nothing queues. Which is the distinction the whole page rests on: what a person intends and what a body can execute are two different things, and they meet at a place that is known in advance.
From key to movement
The same path as a technical flow: five stages, and the requested direction carried across them until it is applied.
How the robot finds its turning points
The places where a turn is possible are not every cell. A cell is one of them when three or more ways leave it, or when the way straight ahead is shut — a corner, or a dead end. Between two of them there is nothing to decide, so the robot runs the corridor.
How the robots coordinate
The game definition is sent to one robot, which passes it to the others over the robot-to-robot communication the earlier demos already used — nothing was added to carry it. Each robot receives the same definition and determines its own role from its own identity. Nobody hands out roles.
- Its role in the game is a domain matter: what this robot is supposed to do.
- What its body can execute — wheels, bumper — is a separate list the host keeps.
- The two are deliberately not the same thing, and neither one is derived from the other.
What happens when you stop pressing
Take your hands off the keyboard and the robot neither stops nor waits. A fallback rule in the domain keeps choosing the way on, in a fixed order, and it always answers something.
Human input and autonomous behaviour coexist here rather than taking turns: the keyboard influences the decision, it does not replace the deciding.
What this demonstrates
These robots already supported formations. They now also support game-based behaviour, and adding it required no changes to what was already there. The new module is created with the robot and asks it for every route, so the body is driven exactly as it was before.
- The body: unchanged.
- The journal: unchanged — the operator’s presses land in it like any other act.
- The robot-to-robot communication: unchanged — the game definition travels on what was already there.
That is the result. Live human input, autonomous decisions, a body with physical limits, robots coordinating, and a complete history of what happened — inside the architecture that was already in place.
What is next
Movement is what has been built, and it is the part that takes the most work. What follows it is listed here rather than implied.
| capability | built | not yet |
|---|---|---|
| Live keyboard input, recorded as the robot’s own act | yes | |
| Movement that respects the body’s physical limits | yes | |
| One game definition shared between robots | yes | |
| Each robot determining its own role | yes | |
| Moving on with no human input at all | yes | |
| The others pursuing | next | |
| Something to collect, and a score | later | |
| A maze found rather than given | later |
And one standing condition rather than a step: these robots run inside one simulator on one computer. A distributed physical fleet is not what this demonstrates.