Robotics. Reinforcement Learning.
Training intelligence for robot swarms.
Iresine builds multi-agent reinforcement learning software that trains robot swarms to coordinate, adapt and act as one.
The problem
One robot is a control problem. A hundred is a coordination problem.
Steering one robot to a goal is well understood. Put dozens in the same space and the hard part changes: who covers which area, who hands off to whom, and what happens when a teammate fails.
Iresine trains the team instead of scripting it. Each robot’s policy (the learned part that decides what it does next) practices with its teammates in simulation, then runs on that robot’s own sensors and local messages.
Control
1 robot, 1 goal
Coordination
Many robots, shared goal
Why swarms are hard
- 01
Partial observability
Nobody sees everything
Each robot only knows what its own sensors pick up. Decisions are made with missing information about the world and the team.
- 02
A moving target
Non-stationarity
While one robot learns, its teammates learn too, so the world each one is adapting to keeps changing underneath it.
- 03
Credit assignment
Who actually helped?
The team wins or loses together. Learning stalls unless training can tell which robot’s action made the difference.
- 04
Limited communication
Slow, short-range links
Radio links are narrow and lossy. Robots must decide what is worth saying, and still act when messages never arrive.
- 05
Scale and failures
Teams change mid-mission
Robots get added, run low on battery or drop out. Behavior tuned for one exact team size breaks when the team changes.
What we build
Software for the whole path, from simulation to the field.
Four parts, each built for teams of robots rather than one robot at a time: practice safely in simulation, learn to cooperate, stay coordinated under real-world limits, then run on the robots themselves.
- 01
Simulate
Swarm-scale simulation where whole teams practice before any hardware moves.
- Many environments in parallel
- Physics and sensor models
- Randomized conditions on every run
- 02
Train
Robots learn together with a shared view of the team, then each acts on its own.
- A shared critic that scores the whole team during training
- Robots of the same type share what they learn
- Curricula from easy to hard
- 03
Coordinate
Team behavior that holds up under the limits real robots face in the field.
- Learned communication under bandwidth limits
- Acting on partial observations
- Works across team sizes and dropouts
- 04
Deploy
Sim-to-real transfer onto each robot’s own computer, inside a safety layer.
- Domain randomization and distillation
- Constraints, geofences and fallbacks
- Runs onboard, no central server
Underneath all four: every policy is measured against simple baselines before anyone trusts it. How we evaluate
How a pilot works
From your mission to a trained, tested swarm.
A pilot runs in four steps, as a loop rather than a hand-off, so each round of training starts closer to the real world.
- 1
Define the mission
We agree on the robots, the environment, the goals and the hard constraints, and on how success will be measured.
Output Mission spec and success measures
- 2
Build the simulation
We model your robots, sensors and surroundings, then randomize them so policies cannot overfit one version of the world.
Output A swarm simulation of your mission
- 3
Train and stress-test
We train team policies with multi-agent reinforcement learning, then test them against simple baselines, robot dropouts, noisy sensors and scenarios they have never seen.
Output Trained policies and an evaluation report
- 4
Deploy and iterate
Policies run on each robot behind a safety layer. What the robots see in the field flows back into simulation.
Output Onboard policies and a feedback loop
After step 4, field data flows back into step 2, the simulation, and the loop repeats.
Applications
Built for jobs one robot cannot do alone.
Wherever a team has to cover ground, divide the work and keep going when members fail, coordination decides the outcome. These are the areas we design for.
- Active research
Wildfire response
Our first research environment: teams of agents learn to locate, track and contain spreading fire in simulation.
- Locate
- Track
- Contain
-
Search and rescue
Air and ground teams split a search area, share what they find and re-plan when a teammate runs low on battery.
- Area coverage
- Shared findings
- Re-planning
-
Precision agriculture
Fleets divide fields for scouting, spraying or sampling, and adjust the plan as weather and crop conditions change.
- Field coverage
- Task allocation
-
Warehouse and logistics fleets
Many mobile robots share aisles and docks without gridlock, routing around each other and around people.
- Traffic flow
- Task allocation
-
Infrastructure inspection
Teams inspect bridges, pipelines, power lines and plant sites together, dividing the structure and covering blind spots.
- Coverage
- Hand-offs
-
Environmental and ocean monitoring
Aerial, surface and underwater robots spread out to sample large areas where links are weak and conditions shift.
- Sampling
- Low bandwidth
Why learn coordination
Three ways to run a robot team.
Scripted rules and central controllers work well for small, predictable jobs. As fleets grow and conditions change, their limits show. The ratings are our qualitative view, not measured results, and they include where learned coordination needs extra care.
| Capability | Scripted rules Hand-written if-then behavior on each robot | One central controller A single planner that commands every robot | Iresine’s approach Learned decentralized coordination Policies trained together, run on each robot |
|---|---|---|---|
| Grows with more robots | Rule interactions get hard to predict | Compute and traffic grow with every robot | Same policy on each robot, trained across team sizes |
| Adapts to new conditions | Handles only the cases someone wrote down | Re-plans well if its world model is right | Trained on randomized conditions; within that range |
| Keeps working if a robot or link fails | Robots continue, but rarely cover for each other | Losing the controller or its link can stall the team | Each robot acts on its own sensors; trained with dropouts |
| Works without constant communication | Mostly local by design | Every robot needs a live link to the planner | Uses short local messages when they arrive |
| Engineering effort as tasks get harder | Every new case means new rules | Models and planners must be extended | Upfront work in simulation; harder tasks mean retraining |
| Easy to inspect and predict | Behavior is written out line by line | Plans can be read before they run | Needs testing and a safety layer, which we build in |
Evidence over assurances
Every policy has to beat the baselines.
A trained swarm can look impressive in a demo and still be no better than a simple rule. So before anyone relies on a policy, we test it the way a skeptic would.
-
Baselines set the bar
Scripted rules, random actions and idle robots. A policy that cannot clearly beat them is not trusted.
-
Scenarios it has never seen
Evaluation runs on newly generated scenarios (fresh random seeds) that the policy never trained on, so a good result is not luck or memorization.
-
Controls
We change one thing at a time and keep control runs, so every improvement traces back to its cause.
-
Stress tests
Robots drop out, sensors get noisy, links fail. We measure how gracefully team performance degrades.
What a fair comparison looks like
IllustrativeBuilding a robot fleet that needs to think as one?
Tell us about your robots, your environment and the behavior you need. We will tell you honestly whether multi-agent learning can help, and how.