ECITON-R is a proposed way for robots to share useful updates and divide work. It sits above the control system already inside each robot.

ECITON-R does not steer wheels, run motors, keep a drone in the air, or handle an emergency stop. The robot's own navigation and safety software stays in charge.

Nothing on this page has been tested in simulation or on hardware yet. This is the design the project will build and test.

A large group of small round Kilobot research robots gathered together.A large group of small round Kilobot research robots gathered together.

A real Kilobot swarm. These small robots were developed for swarm-robotics research. They are reference material, not ECITON-R hardware. Photo: asuscreative, CC BY-SA 4.0.

The whole idea in one picture

Start with the same blocked-route observation, then switch between the two paths. One follows a task intent back to the host robot. The other follows a message out to nearby nodes.

Responsibility map

Follow either path to see what ECITON-R handles and where its authority ends.

Host robotRobot retains authority
Permitted observation enters
Navigation and safety stay here
Robot may accept or reject task intent
ECITON-R nodeBounded decisions
Adapter translates observation
Two independent choices
Task preference
Check task intent
Communication action
Check message
NetworkTransport and reach
Choose an available radio
Nearby nodes receive and validate
  1. Host robotPermitted observation

    The route ahead is blocked.

  2. ECITON-R nodeAdapter translates it

    Only the approved observation enters the shared format.

  3. ECITON-R nodeTask preference

    A different useful task is suggested.

  4. ECITON-R nodeCheck task intent

    Unsupported, stale, or unsafe intent is blocked.

  5. Host robotAccept or reject

    Navigation and safety software keep final authority.

Trace task intent

Example: A robot reports that its route ahead is blocked.

What enters
A permitted observation says that the current route is blocked.
What ECITON-R decides
It forms a task preference and checks that the intent is supported, current, and within bounds.
What leaves
A high-level task intent returns to the host robot. It is not a movement command.
What can stop it
Deterministic checks can block the intent. The host robot may still reject or ignore it.

The left branch returns a high-level task intent to the robot. The robot can accept it, reject it, or let it expire. The right branch prepares a message for nearby ECITON-R nodes.

What each part does

  • Robot adapter: a translator between one robot's software and ECITON-R. It only passes information the robot is allowed to share.
  • Decision layer: chooses a task preference and a communication action from the node's local view.
  • Task-intent check: blocks a suggestion if it is stale, unsupported, unsafe, or too close to direct motor control.
  • Message checks: reject messages with a bad identity, wrong version, missing permission, expired time, duplicate ID, or broken forwarding rule. They also enforce resource limits.
  • Transport Manager: chooses an available radio after the message and its purpose are already clear.
  • Evidence Recorder: keeps the decisions, message frames, delivery results, and run settings needed to explain what happened later.

These jobs stay separate on purpose. A new decision method or radio should not require the rest of the system to be rewritten.

One message, step by step

Imagine three robots inspecting a site. One robot finds that a route is blocked.

  1. The robot reports a small observation through its documented adapter.
  2. ECITON-R decides whether nearby robots need that update.
  3. Protocol code checks the message's identity, version, permission, age, and size. It also checks for duplicates.
  4. The Transport Manager chooses an available supported radio.
  5. A nearby ECITON-R node receives the message and checks it again before using it.
  6. If the update changes that node's task preference, it may send a high-level task intent to its host robot.
  7. The host robot decides whether and how to move.

ECITON-R is not meant to broadcast every sensor reading. It is meant to move small, useful updates while staying inside communication and compute limits.

Where a learned model fits

The first version should use fixed, testable rules. A compact learned model may later recommend:

  • which task a robot should prefer;
  • whether to stay silent or send a message;
  • whether that message should go directly to a neighbor, spread through gossip, update shared virtual markers, carry an aggregate, or request a cluster change.

The model will not control message validity, coordinator terms, low-level motors, or robot safety. Deterministic code keeps those responsibilities.

What still needs to be built

The next shared pieces are:

  • SwarmObservation, the small set of robot information ECITON-R may read;
  • TaskIntent, the high-level suggestion a robot may accept or reject;
  • a versioned message envelope;
  • messages for task announcements, bids, claims, releases, completion, and rejection;
  • messages for heartbeats, temporary coordinator elections, votes, leases, and cluster merges;
  • evidence events and a run manifest that records the code version, settings, seed, and validity of each experiment.

These contracts must be defined before the simulator, firmware, and robot adapters are built independently. Otherwise, the three parts could end up speaking different versions of the protocol.