Repository navigation
Central Controller
The central controller provides intentions to individual arms. Its main responsibility is to decide which arm receives an assignment, rather than to decide the position of every segment.
For example, “Arm 3, reach this position” provides a destination. Arm 3 keeps that objective while its local controller exchanges requests between segments, limits their movement and responds to obstacles. The central controller does not replace those local adjustments with a planned whole-arm pose.
| Concern | Central responsibility | Local arm responsibility |
|---|---|---|
| Assignment | Direct a reach or idle instruction to a chosen arm | Retain and execute the instruction |
| Reaching | Supply an objective | Exchange neighbour requests and turn segments |
| Obstacles | Make the environment available to the arms | Steer around nearby boundaries and reject unsafe movement |
| Sensing | Schedule updates and allow observation | Determine which segments contact which objects |
| Grasping | Receive successful capture reports and preserve exclusive ownership | Recognise sustained adjacent contacts and establish the grip |
| Carrying | Route the requested destination to the chosen arm | Move the attached object while respecting movement constraints |
flowchart TB
User["Experimenter chooses an assignment"] --> Central["Central controller"]
Central -->|"Objective"| A1["Arm 1"]
Central -->|"Objective"| A2["Arm 2"]
Central -->|"Objectives"| Others["Arms 3 to 8"]
A1 --> Local1["Own segments, sensing and grasp"]
A2 --> Local2["Own segments, sensing and grasp"]
Others --> LocalOther["Separate local state for each arm"]
Local1 -->|"Capture report"| Central
Local2 -->|"Capture report"| Central
LocalOther -->|"Capture reports"| Central
In the current experiment, assignments originate with the experimenter or the initial scene. The central controller is not an autonomous planner deciding which goal is most valuable.
Each arm has its own target, local messages, joint configuration and activity state. Retargeting one arm does not replace another arm's assignment. Similarly, an idle arm does not prevent other arms from moving.
Consider three simultaneous activities:
| Arm | Assignment or activity | Expected behaviour |
|---|---|---|
| Arm 1 | Hold captured food | Preserve its pose and attachment |
| Arm 3 | Reach beyond an obstacle | Keep trying local adjustments towards its objective |
| Arm 6 | Idle | Hold its pose while continuing to sense nearby objects |
Independence does not mean the arms occupy separate worlds. They see the same environmental objects, and a food object moved by one arm changes what another can sense. An ownership rule also prevents two arms attaching themselves to the same object.
The current model does not simulate arm-to-arm collisions, cooperative lifting or the body being pulled by incompatible actions. Those would require additional interaction rules.
Reach: move the tip towards a position. The arm can locally establish a grasp if it encounters enough sustained food contact; capture does not require a second instruction from the central controller.
Carry: when the arm already holds food, a new destination refers to the food's centre rather than the tip. The local controller adjusts its movement accordingly.
Idle: stop moving without necessarily releasing a grip. Sensing continues, but an idle arm does not begin a new grasp.
Retract: when food is held, carry it towards a point near the arm's attachment to the body. Retraction changes the objective; it does not shorten the segments.
Release: detach the object in place and idle the arm. This prevents immediately grasping the same object again without a new instruction.
Resetting an arm's geometry is a separate experimental operation. It releases held food because a grip cannot safely retain a reference to a segment whose geometry has been rebuilt.
A successful capture produces a report containing the arm's identity, the object's identity and the simulation time. A completed capture is reported once, not on every later update spent holding it. The most recent 32 reports are retained, along with the total capture count for the current simulation.
Routine segment contacts remain local observations. The display may show them, but seeing a contact does not mean the central controller has issued a new task.
The arm's displayed state describes its current activity or restriction:
| State | Meaning |
|---|---|
| Idle | No active movement assignment and no higher-priority displayed condition |
| Reaching | Working towards a tip objective |
| Reached | Tip lies within the arrival tolerance |
| Contact | Local sensors touch an object; contact alone is not a completed grasp |
| Grasping | Adjacent food contacts are being held for the required time |
| Holding | A grip exists and the arm is not moving the object |
| Carrying | Moving held food towards its requested destination |
| Retracting | Carrying held food towards the body-side destination |
| Avoiding | Nearby obstacles are redirecting local movement requests |
| Blocked | A movement was rejected, or the objective is inside an obstacle's clearance region |
These are summaries, not mutually exclusive physical facts. A carrying arm can still have contact readings while displaying Blocked. A held object remains attached when an obstacle stops a carry. An idle arm touching something can display Contact without becoming active.
All arms advance using the same simulation timestep. The central controller visits them in a stable order. This ordering makes the experiment repeatable; it does not imply that the arms are separate physical processors running at different speeds.
When food is captured, its identity becomes unavailable to later claims. If multiple claims would complete in the same update, the first completed claim in arm order wins. When an arm encounters more than one eligible food object, object identity gives a deterministic order for considering candidates.
In the Phase 3 model, arbitration occurs before movement, using compact arm intentions and reported hazards. Withdrawal has priority 100, local avoidance 80, grip 60, reaching 50, incidental discovery 20 and idle 0. Shared food or coordinate targets favour existing ownership, then an eligible incumbent on the same resource, then the lowest arm number. Losers enter Yielding without losing their assignments. The final ownership check remains a safeguard against duplicate attachments.
A reported P100 hazard at or above the configured critical severity (0.95 by default) requests retreat from every arm. The fixed body does not move: each arm computes its own retreat locally. Withdrawal releases food in place; interrupted carries are abandoned, while ordinary reach assignments resume after clearance. Named-food tasks retain their identity and ignore incidental discoveries. The interfaces display priorities, reasons, recent conflict outcomes and safety-release counts. Reward-based food ranking and coordinated route planning remain outside the model.
There is no central search for a collision-free route. Obstacle steering is local to a segment's requested movement. A whole-arm movement check can veto an unsafe turn, but it does not construct an alternative route. This distinction matters: local steering proposes movement; the geometric check enforces constraints.
Capture decisions originate from adjacent contact within an arm. The central layer records the result and prevents duplicate ownership. It does not prescribe which joint must curl to make the capture happen.
See Reach Controller and Arm Movement for local rules and their limits, Hazards, Recoil and Conflict Resolution for the arbitration rules, and Architecture for the implementation.