Cover photo: Colias robot swarm by Farshadarvin, CC BY-SA 4.0. Used unchanged; reference hardware, not an ECITON-R fleet.
The direction for ECITON-R is getting clearer. I want to build a system that helps existing robots work together, using small local AI models to make better communication decisions.
So far, a lot of the work has focused on communication limits: what happens when messages are delayed or lost, how robots share task information, and how coordination continues when a robot goes offline. That work is still useful. The bigger goal is to make communication smarter as the team grows.
I’m building this as an engineering project. I want a working system that I can demonstrate, explain, and eventually connect to real robots. There are already good ideas and tools in swarm robotics, networking, and machine learning. I want to build on those and see what works together.
What I Mean by Local AI
Each robot would run a compact model that uses its own observations, the information it has received, and its available resources to help decide what to communicate.
A robot might discover a task that another robot is better equipped to handle. It could send that information to a relevant neighbor. If its latest observation adds nothing useful, it could stay silent. As more communication modes become available, it could choose to pass along a summary or spread information through nearby robots.
The model would have a defined set of inputs and choices. It could be a small neural network making these decisions onboard. The intended decision loop would work locally, without asking a cloud service what to do every time something changes.
The protocol still needs clear rules. A model choosing to send something does not mean that message should automatically go through. Code needs to check whether the information is current, whether the action is allowed, and whether the robot has enough of its communication budget left. Keeping those checks predictable is part of making the system useful.
Planned local communication loop: observations feed a compact model, deterministic checks gate its proposal, and silence or delivery results update local information.
This is the loop I want to build next. The learned model still needs to be integrated.
Scaling the Team
The scale goal I’m working toward is 1,000 simulated robots. That is a target, and there is still work to do before I can show useful coordination at that size.
If every robot constantly sends every update to every other robot, the traffic grows quickly. I want most decisions and information to stay local, with updates reaching the robots that actually need them. Temporary coordinators could help combine information when that is useful, while robots keep their own local knowledge and can continue without a permanent leader.
Fewer messages only help if the team can still do its work. I want to look at communication cost alongside completed tasks, stale information, and recovery when links or robots fail.
The aim is to avoid all-to-all updates. Local neighborhoods can keep each robot’s communication bounded, but delivering information across the whole team still has a cost. I need measurements before claiming any particular scaling behavior.
The Hardware Vision
The hardware direction is the ECITON-R Node: an add-on module that connects a supported robot to the coordination system.
The long-term vision is to make it easier to turn existing robots into a coordinated team. The first step is to support a specific platform and prove the connection works. Different robots have different interfaces, power requirements, and capabilities, so each adapter needs to be tested.
The host robot keeps responsibility for navigation, motor control, and safety. The Node would handle coordination, communication, and the local decision model, then pass high-level task requests through the robot’s supported interface.
Planned Node boundary: coordination and communication sit on the Node; a tested adapter connects it to a host robot that retains navigation, motors, and safety.
The Node and adapter in this diagram are the intended system. Compatibility has to be established one robot platform at a time.
An ESP32-S3 development board, shown as a hardware reference. This is not a photo of our Node or a tested ECITON-R board.
I’ve started the embedded software path with an ESP32-S3 build target. The first bench firmware supports identity and ping over serial and has passed software checks and a target build. Physical board testing, radio communication, and model execution are still ahead.
What Is Working Today
Swarm Lab already gives me a place to build and inspect this behavior. It has simulated message delivery and failures, task coordination, resource limits, saved runs, and replay. There is also a single-rover experiment that builds a local obstacle map and navigates from it, with position supplied by the simulator.
An earlier Swarm Lab rover run showing its obstacle map and planned path. Position is supplied by the simulator.
The current bounded reference policy is deterministic. I still need to integrate a trained local model. The direct-message work has started with code that binds an exact communication choice to its recipient and information; connecting that choice to live execution is the next part.
What I’m Building Next
The next stage is to connect these pieces into a demonstration where I can follow a robot’s local information through its decision and see what gets sent, refused, or received.
From there, I want to introduce a small model, starting with a focused communication choice, and compare its behavior with a simple rule-based policy. The simulator should make those choices visible so I can understand where the model helps and where it makes things worse.
Alongside that, the hardware work needs to establish the local runtime and move onto a real development board. That will help determine which model, memory requirements, and interfaces are practical before building a custom Node.
I can see applications in inspection, logistics, disaster response, and defense support, where teams need to coordinate through unreliable connectivity. The physical AI direction that interests me is making individual robots better at working together. The next demonstration should make that idea visible: robots using their own information to choose useful work and share what the rest of the team needs.
Image credit: ESP32-S3 on paper, VectorVoyager, CC BY-SA 4.0; unchanged.
