It's the middle of the night in a warehouse, and a few dozen robots are running inspection rounds. One of them rolls into aisle 3 and finds it blocked by a fallen pallet. It knows exactly what to do for itself: stop safely, find another route, carry on.
What it can't easily do is warn the robot already heading for aisle 3 from the other end of the building.
Most robots today are very good at being individuals. They can map a room, avoid a person and reach a shelf. Working as a team is harder. Usually it means a central server that every robot reports to, over a network that has to stay up. When the Wi-Fi drops or the server goes quiet, the team falls back into a group of individuals.
ECITON is about closing that gap: helping robots share the right information directly with each other, within real limits on bandwidth, battery and computing power. For most of this year, that work has lived in software, in our simulator, Swarm Lab. This post is about the next step: the hardware we've designed to take it off the screen and onto real robots.
Why not just stay in simulation?
Simulation is where we move fast. We can run large teams of simulated robots, replay every message and compare one idea against another in minutes. But a simulator is only as honest as its assumptions, and some questions only real hardware can answer.
Real radios are messy. In Swarm Lab, a message's size, delay and chance of being lost are numbers we choose. Real radio signals bounce off shelving, fade behind concrete and collide with other transmissions. The only way to know how often a message actually arrives is to send it.
Every message costs energy. Our robots decide what to share under an energy budget. On a real board we can measure what a transmission, a decision or an idle minute actually costs, then feed those numbers back into the simulator so it gets more realistic.
The decision-maker has to fit. Eventually we want a small trained model choosing what each robot shares. Training happens in simulation, but the model has to run on a low-power processor with very little memory. We won't know it fits until it's running on one.
Robots don't share a language. Robots from different makers often can't talk to each other at all. A common piece of hardware gives them one.
We treat simulator results and hardware results as different kinds of evidence. A simulator can tell us an idea is worth testing. Only hardware can tell us it works.
Why a separate board?
A fair question: why not just install our software on the robot's own computer? We chose a separate module, which we call the ANT. The name is a nod to the army ants our project is named after: each one is simple, but together they can do remarkable things. We went with a separate module for three reasons.
Robots are all different. They use different processors, operating systems and radios, and many have no spare radio at all. A separate module gives us one platform to support, plus a small adapter for each type of robot.
It draws a clear safety line. The ANT doesn't drive anything and has no connection to the motors. It exchanges a small, defined set of observations and suggestions with the robot through one port. Keeping it physically separate makes that boundary easy to see and check. If the ANT fails, the robot keeps working the way it did before the ANT was added.
It can be measured on its own. The ANT monitors its own power use, so the cost of coordination is never hidden inside the robot's overall battery drain.
| The ANT handles | The robot keeps |
|---|---|
| Deciding what to share, and with whom | Navigation and path planning |
| Choosing which radio to use | Motor control |
| Checking every incoming message | Safety and emergency stops |
| Suggesting tasks to the robot | The final say on every move |
| Recording what was sent, received and acted on | Its own sensors and maps |
What's on the board
A simplified view of the designed ANT. Orange marks the short-range path and blue the long-range path, the same colors used throughout this post. Not yet assembled or tested.
The ANT is built from a handful of blocks, each with one job:
- A low-power main processor. It runs the ECITON software and has a short-range radio built in for talking to nearby teammates.
- A separate long-range radio. It sits on its own module with its own power switch, so we can test it independently and switch it off when it isn't needed. We explained why we're interested in long-range radio in Long range, few words.
- Two external antennas, one for each radio, so they can be placed wherever works best on each robot.
- An energy monitor that measures how much power the ANT draws. Energy is part of every decision the ANT makes, so we need to measure it, not guess.
- Robot and sensor ports: a serial link to the robot's computer, plus standard connections for sensors.
- Protected power input. The ANT never plugs straight into a robot's battery. A small adapter made for each robot type supplies clean, protected power. USB-C provides power and setup on the bench.
- Status lights, reset buttons and debug access for both processors, because first boards rarely work on the first try.
All of this fits on a board about the size of a credit card. We chose ready-made radio modules instead of designing radio circuits from scratch. That keeps the first revision simpler and lets us test each radio on its own before we rely on it.
Two radios, two jobs
Short-range for frequent, nearby updates. Long-range for rare, small messages that must arrive. Illustrative, not to scale.
Robots that are close together need to talk often: I've taken this task. This area is done. The short-range link handles that. It's faster and can carry more in each message.
Robots that are far apart need to talk rarely, but reliably: a blocked route, a task being handed back, a heartbeat that says I'm still here. That's what the long-range link is for. It's slow and carries only a few words at a time, but it can reach across a site where the short-range link can't.
Our first outdoor goal is roughly 1 km between ANTs with a clear line of sight. That's a target we set for the first prototype, not something we've measured yet.
The software deciding what to say doesn't need to know which radio carries it. A separate part, the transport manager, picks the link. For now it follows fixed, predictable rules. Whether a learned model can choose better is a later experiment, and we'll compare it against those simple rules.
What the ANT actually does
One message, from discovery to a better decision. A simple version of this path already runs in Swarm Lab; on physical ANTs it is still to be built and tested.
Go back to the blocked aisle. Here's what the ANT is designed to do with that one discovery.
It decides whether to speak at all. The airwaves are shared, every message uses up battery, and too much chatter drowns out what matters. Often the best message is no message. The ANT weighs who needs the news and what it costs to send before anything goes out.
It chooses how to send it. A teammate in the next aisle gets it over the short-range link. One across the building gets it over the long-range link, or through a teammate that relays it.
It doesn't trust what it hears. Every incoming message is checked before it's used: Is it from a real teammate? Is it still fresh? Have we seen it already? Has it expired? A message that fails is dropped.
It suggests; the robot decides. The receiving ANT updates what its robot knows and may suggest a new task, such as a different route. The robot can accept or decline. The ANT never takes the wheel.
Two more jobs happen in the background. When a group of robots needs a coordinator, ANTs are designed to elect a temporary regional coordinator for a fixed term. It can be replaced at any time, and it's never the only robot that knows what's going on, so losing it doesn't break the team. The ANT also keeps a record of what it saw, sent, received and acted on, so when something goes wrong we can trace exactly why.
Where we are, honestly
Where the hardware stands as of October 31, 2026.
The ANT's design is complete and has been reviewed: the circuit, board layout, parts list and manufacturing files. No ANT has been ordered, assembled or tested yet. Everything about performance on this page is a goal, not a result.
Before our own boards exist, we'll test firmware and radio behavior on off-the-shelf development boards. The setup software for the first of those tests is ready; the tests themselves haven’t run yet.
The first build will be three ANTs: two field ANTs and one receiver. Their first job won't involve a robot at all. In a cooperative sensing demo, the field ANTs will take readings, share information that changes what a teammate measures next, and relay reports back to the receiver and a laptop. That tests the hardest part on its own: does information get where it needs to go, at a cost we can measure?
After that, an ANT goes on a real robot.
What we want to learn
These are the questions we built this board to answer:
- How often does a short, important message actually arrive across a real building or field?
- What does coordination cost in energy, and when is it worth paying?
- Can a small decision model run on the ANT and make better choices than fixed rules?
- How little can a robot say and still help its team?
We'll publish what we find, including the results that don't go our way.
If you run robot fleets, or have built radios for mobile robots, we'd like to hear what breaks for you in the real world. Get in touch, or try Swarm Lab to see the coordination ideas we'll soon be testing on real hardware.
All diagrams and illustrations by ECITON Robotics.