About ECITON-R
I’m Anish, a Mechatronic Systems Engineering and Artificial Intelligence Systems Engineering student at Western. I started ECITON-R to study how robot teams share information and divide work.
One early spark was Big Hero 6. The microbots made groups of robots feel exciting and helped get me interested in engineering. Ant colonies gave me a different question: how can local interactions add up to useful teamwork?
The question behind the project
A robot only sees part of its surroundings. Another robot may know about a job it hasn’t found, or a route it hasn’t explored. Bringing those pieces together can help a team, but each robot has limited communication capacity, battery and computing time.
I’m interested in how robots decide what to share and how that changes the work they choose. The questions I want to test are:
- Which discoveries are worth sending when messages are limited?
- How should robots divide tasks when they have different information?
- How can a team recover when messages are lost or a temporary coordinator goes offline?
A place to try the ideas
I wanted to watch a robot change direction and find out what it had learned. That became Swarm Lab: a simulator where you can change the scene, follow a robot, and inspect the messages behind its decisions.
Today, it simulates temporary task claims, information passed between neighbors, and replaceable coordinators. You can draw walls, add jobs, introduce missed messages, and inspect each robot’s local knowledge.
The latest mapping experiment follows one rover as it discovers obstacles, remembers free space and plans a route using its own map. It assumes an accurate position; shared obstacle maps and position estimation through SLAM are still future work.
From simulation to a robot
The longer-term plan is an ECITON-R Node that connects the coordination logic to a supported robot. It would handle task suggestions and communication, while the robot’s own systems keep control of navigation, motors, obstacle avoidance and safety.
A learned policy is a decision rule trained in simulation. Those policies and the physical Node are still planned. Before using them on a robot, we need to test the adapter and measure how quickly the code runs, how much memory and energy it needs, and how it behaves when something fails.
How we’ll judge progress
The aim is to compare different decision and sharing rules on the same scene, incoming jobs and failures. We’ll examine the work completed and the communication and computing used, keeping failed and inconclusive runs in the record.
This site follows that process through development updates, research notes and the simulator itself. Simulation findings apply to the recorded conditions; claims about physical robots will need hardware measurements.