Swarm Robotics in Reality

DotBot Academy

Geovane Fedrecheski

AIO team, Inria Paris

The speaker

Step 1 · Who we are 1/3

Figure 1: Geovane Fedrecheski.

Geovane Fedrecheski

Lead Research Engineer, AIO team, Inria Paris

• Leads the 1,000-robot DotBot testbed; designed Mari, the testbed’s radio link layer
• IoT security at the IETF: co-author of ELA (zero-touch enrollment), implemented EDHOC in Rust as Lakers
• Background: PhD in Electrical Engineering (USP), BSc in Computer Science (UNICENTRO), visitor scholar at UC Berkeley, earlier at LG Electronics
• Research interests: swarm robotics, the Internet of Things, IoT security, education

fedrecheski.com · GitHub · LinkedIn

Who we are, in three slides, starting with me (Figure 1). I lead the DotBot testbed at Inria Paris, in the AIO team, and I designed Mari, the radio link layer you will meet in the platform chapter. On the security side I co-author ELA, an IETF draft for zero-touch enrollment of IoT devices, and implemented EDHOC in Rust as the Lakers library. Before Inria: a PhD in electrical engineering at the University of São Paulo, a visit to UC Berkeley, and industry work at LG Electronics. My website has the papers and the projects.

Inria, and Inria Paris

Step 1 · Who we are 2/3

The French national research institute for digital science and technology.

4,350 collaborators: 2,500 Inria staff and 1,850 from partner institutions

Inria Paris, our centre

35 project teams

700 people

55 nationalities

With PSL, Sorbonne Université and Université Paris Cité. Figures from inria.fr and Inria’s institutional infographic.

Figure 2: Inria’s nine research centres, and its local offices.

I work at Inria. Inria is the French national research institute for digital science and technology, a public operator of the French State, rooted in computer science and applied mathematics. It has about 4,350 collaborators: 2,500 Inria staff and 1,850 from partner institutions. Figure 2 shows its nine research centres across France, plus local offices. We are at the Inria Paris centre: 35 project teams and about 700 people from 55 nationalities, working with the three Paris research universities, PSL, Sorbonne Université and Université Paris Cité.

The AIO team

Step 1 · Who we are 3/3

Formerly low-power wireless for the Internet of (Important) Things. Now robotic swarms, IoT security, chip-scale sensing.

Figure 3: The AIO team, February 2024. Photo: aio.inria.fr.

Smart Dust Low-Power Wireless Networking Security in Constrained Systems Swarm Robotics Vehicle Area Networking

Within Inria Paris, the team behind this testbed is AIO, formerly called EVA, at Inria Paris (Figure 3). Its roots are in low-power wireless communications: in its own words, designing tomorrow’s Internet of Important Things, for critical applications such as robotics and industrial control loops, under tight reliability, scale, security and energy constraints. Today the work is robotic swarms, IoT security and chip-scale sensing. The research is organized in five pillars: smart dust, low-power wireless networking, security in constrained systems, swarm robotics and vehicle area networking. The team co-chairs two IETF working groups, 6TiSCH and LAKE, co-leads the OpenWSN project with Berkeley, and runs over 1,000 sensors on three continents. The DotBots are the swarm robotics pillar, and they lean on the others: Mari is low-power wireless networking, SwarmIT and Qrkey are security in constrained systems.

What DotBot Academy is

Step 1 · DotBot Academy 1/9

Figure 4: Hundreds of DotBots on the floor of the 725-robot deployment, Limerick, January 2026.

Program a swarm of small robots with Python: first in a simulator, then on real robots.

8 steps, from the simulator to real robots 2 + 2 two people, two robots per duo 20 robots in the room

Welcome. DotBot Academy is a hands-on introduction to programming a swarm of small robots like these (Figure 4) with Python, like the hundreds in this photo from our largest deployment. You work in pairs, two people and two robots per duo, with 20 robots in the room. You start in a simulator on your own laptop, where nothing can break, and you finish with your own script driving your two real robots on the floor.

Why swarm robotics?

Step 1 · DotBot Academy 2/9

Figure 5: The promise: many simple robots working together, as illustrated in the LeSwarm pitch.

• Many simple robots, one collective behaviour that emerges from them
• Resilient: lose a few robots and the swarm carries on
• In parallel: more robots cover more ground at once

logistics and warehouses environmental monitoring agriculture search and rescue inspection in hard-to-reach places collective transport space exploration

Why swarms at all? Large robot swarms are seen as the next frontier in distributed autonomous systems (Figure 5). Instead of one complex robot, many simple ones, and the interesting behaviour emerges from how they interact. A swarm is resilient: lose a few robots and it carries on. And it works in parallel, so more robots cover more ground at once. The applications people have in mind: logistics and warehouses, environmental monitoring over large areas, agriculture, search and rescue after a disaster, inspection in hard-to-reach places, collective transport, space exploration.

The reality

Step 1 · DotBot Academy 3/9

Figure 6: Kilobots, Harvard, 2012: up to 1,024 cheap robots, but slow; an experiment takes hours. Rubenstein et al., ICRA 2012.

Figure 7: The Robotarium, Georgia Tech, 2017: 20 robots of about 300 USD, experiments of 15 minutes at most. Pickem et al., ICRA 2017.

Figure 8: Drone shows, Paris, 2025: a pre-programmed choreography, not a swarm.

Lab swarms stop at a handful of connected robots or at slow ones, and real deployments are still missing.

The reality is different. Research swarms exist, but with limits. The Kilobots from Harvard (Figure 6) reached 1,024 robots that are cheap, but slow: an experiment takes hours. The Robotarium at Georgia Tech (Figure 7) has 20 robots of about 300 dollars each, and an experiment lasts at most 15 minutes. And the swarms people see on television, drone shows (Figure 8), are a pre-programmed choreography: every drone flies a fixed path, with no collective behaviour. Most lab swarms stop at fewer than 10 connected robots, real-world swarm deployments are still missing, and swarm research is often validated only in simulation.

Good robots, not swarm robots

Step 1 · DotBot Academy 4/9

platform	good for	why it does not scale to a real swarm
e-puck2	research	€1,200 per robot · not designed for swarms · under 10 connected at once
Thymio	teaching, in schools	1 to 8 hours to charge · under 10 connected at once
micro:Maqueen	teaching, with a micro:bit	$32 plus a micro:bit · AAA batteries · no localization · programmed one robot at a time
Crazyflie	research and teaching	not designed for swarms · localization rare or costly · under 10 connected at once
DotBot	research and teaching	€150 per robot · built for swarms · charges in under a minute · localization from a €250 base station · 1,000 connected

Figure 9: Platforms for teaching and research robotics, against what a real swarm needs. Source, figures and pictures: the LeSwarm pitch, May 2026; micro:Maqueen Lite: the DFRobot product page, 2026. Photo: DFRobot.

The usual setup: 2 hours to charge, under 10 connected robots, a €50,000 localization system, and tools that drive one robot at a time.

Why not use the robots labs and schools already have? They are good robots, but not swarm robots (Figure 9). The e-puck2 is a research robot, at around 1,200 euros each, and it was not designed for swarms. The Thymio is a school robot, and robots like it take 1 to 8 hours to charge. The micro:Maqueen Lite from DFRobot is a popular BBC micro:bit robot car for schools: about 32 dollars plus the micro:bit, three AAA batteries (not included), line sensors and an ultrasonic socket but no way to know where it is, and programmed with MakeCode blocks one micro:bit at a time, over a USB cable or Bluetooth. The Crazyflie is a drone for research and teaching, but it needs a localization system that is rare or costly. And all of them connect fewer than 10 robots at once. The usual setup adds up to 2 hours of charging, fewer than 10 connected robots, a localization system around 50,000 euros, and software that drives one robot at a time. The DotBot was designed the other way round: about 150 euros, built for swarms from the start, charged in under a minute, located by a 250-euro base station, and made to connect 1,000 robots.

Sources for the micro:Maqueen row: the DFRobot product page, https://www.dfrobot.com/product-1783.html (price, AAA batteries, MakeCode and Mind+, sensors, photo), and the micro:bit user guide, https://microbit.org/get-started/user-guide/transfer-code-to-the-microbit/ (programs go to one micro:bit at a time, by USB or Bluetooth).

Why it is hard

Step 1 · DotBot Academy 5/9

With hundreds of robots, every chore is multiplied. Each one is a pillar of today’s platform.

💶 Afford hundreds of robots → The robot

🔋 Charge them all, again and again → The robot

📍 Locate every robot, live → Lighthouse 2

📡 Connect hundreds at once, with low latency → Mari

🔄 Reprogram the whole fleet, safely → SwarmIT

🧪 Sim to real the same code in the simulator and on the floor → PyDotBot

The result: a slow rate of scientific progress. After M. Dorigo, G. Theraulaz, V. Trianni, Swarm robotics: past, present, and future, Proceedings of the IEEE, 2021

Why is it so hard? Because with hundreds of robots, every chore is multiplied. You have to afford hundreds of robots, charge them again and again, know where each one is, talk to all of them at once with low latency, and reprogram the whole fleet without losing robots to a bad flash. And code written in a simulator often behaves differently on real robots. Dorigo and colleagues, in their 2021 review in the Proceedings of the IEEE, point to the slow rate of progress in the field. Each of these problems is one of the pillars I show you in a moment.

Our proposal

Step 1 · DotBot Academy 6/9

Problem Hundreds of real robots are out of reach for most labs, classrooms and companies

Solution An open platform for swarm robotics at scale: the DotBot testbed

Research Past the simulation-reality gap: experiments with hundreds of real robots

Education A real swarm in class, programmed in Python, instead of a few line followers

Innovation Physical validation of swarm ideas, without buying a hundred industrial robots

1,000 robots: the goal of our testbed, built in the EU project OpenSwarm

725 robots in one deployment, January 2026

open hardware, firmware and software

Our proposal: an open platform for swarm robotics at scale, the DotBot testbed, built at Inria in the EU project OpenSwarm. It serves three audiences. Researchers, who are stuck at the simulation-reality gap and want experiments with hundreds of real robots. Teachers, who want a real swarm in class rather than a few line followers. And companies, who want to validate swarm ideas physically without buying a hundred industrial robots. Today you use it as students: 20 robots, programmed in Python.

We built all of it, from scratch

Step 1 · DotBot Academy 7/9

🤖 Hardware the DotBot robot, board and charging

⚙️ Firmware drivers and apps, in C, on the robot

📍 Lighthouse 2 localization, one photodiode per robot

📡 Mari the radio network for hundreds of robots

🛡️ SwarmIT safe reprogramming over the air

🐍 PyDotBot the software on your laptop

Our mission Enable a new level of swarm robotics experimentation: hundreds of real robots, open to everyone.

One thing to know before the tour: the team built every piece of this platform from scratch. The hardware, the robot and its board. The firmware that runs on it. The Lighthouse 2 localization. Mari, the radio network. SwarmIT, which lets us reprogram the whole fleet safely. And PyDotBot, the software you use today. Nothing here is a kit bought off the shelf, apart from the Lighthouse base stations. The mission behind all of it: enable a new level of swarm robotics experimentation, with hundreds of real robots.

Your textbook

Step 1 · DotBot Academy 8/9

Figure 10: The workshop website: one page per step, with what to do and what you should see.

Figure 11: The PyDotBot docs, where the step pages send you when you need the details.

Follow the workshop pages; they take you into the docs when you need them.

Start the workshop →

Your textbook today is two things. The workshop website (Figure 10) has one page per step: the problem, what to do, what you should see. Each page links into the real PyDotBot documentation (Figure 11), the same one researchers use, at the section you need. Every step has a core exercise that everyone finishes. Open it now: after the plan comes step 2, the platform, and the hands-on part starts with step 3.

Today’s plan

Step 1 · DotBot Academy 9/9

Step 1 Introduction

Step 2 The platform: how it works

Step 3 Your swarm in the simulator

Step 4 My script moves a simulated robot

Step 5 Connecting to the real robots

Step 6 My script moves a real robot

Break Robots on the charger

Step 7 Moving to a certain position

Step 8 My two robots at once

Finale To be decided

Wrap-up Questions, and what comes next

Eight steps, each one a visible win. Step 1 is this introduction, which ends here. Step 2, right after this slide, is the platform: what makes the real swarm hard, and how the platform works, with time for your questions. Not installed yet? Start now, during the platform talk: you need it in step 3, when we all start the simulator on our laptops together. In step 4 you write your own script against the simulated robots: it lights a robot and drives it. Step 5: you connect to the room’s controller and find your two real robots. Step 6: the same script on one of them, and you see what changes on a real floor. Then a break, with the robots on the charger. Step 7: you send a robot to a position, and it gets there by itself. Step 8: both robots at once. Then a finale, which we will announce on the day, and a short wrap-up. Duos who are ahead can try the extra module, Flash it, where you flash your own robots over the air.

From simulator to reality

Step 2 · The platform

Figure 12: A swarm in the simulator, as you will run it on your laptop in step 3.

→ ?

Figure 13: A real swarm: hundreds of DotBots on the floor, Limerick, January 2026.

A swarm in a simulator is a few commands away. The real robots are right there.

How hard can it be?

In a few minutes you will have a swarm running on your laptop (Figure 12), and real robots are right there on the floor (Figure 13). Same code, same API. So how hard can it be to go from the simulator to reality? In the simulator, a robot always knows where it is, never runs out of charge, never drops a radio packet, and never gets bricked by a bad program. On the floor, every one of those is a real problem, multiplied by the number of robots. The next few slides are what it took to solve them.

The platform

Step 2 · What we have today

Figure 14: Today’s setup.

Everything you’ll use today runs on five building blocks. Each one is published research.

This is today’s setup (Figure 14): 20 DotBots, driven through one radio gateway, each one located by one lighthouse on its stand. Before you get your own robots, a tour, so the next steps make sense: first what you all touch, the robot and the controller with its simulator, then the complexity underneath: how a robot knows where it is, how it talks, how your code gets onto it safely, and how the software ties it together. Each part was built at Inria and published, so for each one I show you the first page of the paper. They are all on the References page of the website.

Five pillars, five problems

The platform · Overview

problem	solution	how
swarms that are expensive and slow to charge	🤖 The robota cheap robot, built by the hundreds	two 120 F supercaps, full in about 30 s
costly tracking that does not scale	📍 Lighthouse 2off-the-shelf base stations	each robot computes its own position, from one photodiode
radios that stall past about 50 robots	📡 Mariabout 100 robots per gateway, low latency	a TSCH schedule: one slot per robot, no collisions
buggy code that takes a robot out	🛡️ SwarmITevery robot recoverable over the air	your app runs in a TrustZone sandbox
many parts to fit together	🐍 PyDotBotone tool for the whole platform	one CLI, a controller with a REST API, a console, a simulator

Five building blocks, and each one exists because of a problem. The robot: swarms of more than a hundred robots are too expensive for many labs, and keeping them charged is labour; the DotBot is cheap and charges in about 30 seconds. Lighthouse 2: camera tracking is expensive; base stations from virtual reality are cheap, and each robot computes its own position, so more robots do not make it harder. Mari: Wi-Fi and BLE struggle past about 50 robots; Mari serves about 100 per gateway with low latency. SwarmIT: a bug in your code must not lose the robot; your app runs in a sandbox and the testbed can always take the robot back. PyDotBot: one tool that puts it all together.

The robot: DotBot v3

The platform · The robot 1/2

Problem Swarms of 100+ robots are expensive to build and to keep charged

Solution A cheap robot, built by the hundreds, on supercaps that charge in about 30 s

Loading the 3D model...

Figure 15: DotBot v3 in 3D. Drag to turn, hover a part.

• About 95 mm square, two wheels and a ball caster
• Up to about 0.8 m/s
• Built for swarms: small, cheap, open source

Best Demo Award

Figure 16: Demo: DotBot, a cm-Scale, Easy-to-Use Micro-Robot for Swarm Research. ICRA 2024 workshop Breaking Swarm Stereotypes. hal-04673787

Figure 17: CapBot: Enabling Battery-Free Swarm Robotics. ICRA 2025, with KU Leuven: battery-free, on supercapacitors. hal-05289043

This is the robot you will hold (Figure 15), turning slowly in 3D, from the board design files: one board, about 95 mm square, two wheels with gearmotors and a ball caster at the front, top speed about 0.8 m/s.

The idea behind it is in Figure 16, the demo paper from the ICRA 2024 workshop Breaking Swarm Stereotypes, where it won the Best Demo Award. Swarm research is often validated only in simulation, because building a swarm of more than a hundred robots is too expensive for many labs. The DotBot is meant to lower that barrier: small, easy to use, open source, and in that paper about 40 euros of components per robot at a volume of 1,000. That paper describes an earlier revision that ran on AA batteries; today’s v3 runs on supercapacitors, next slide.

Next to it, Figure 17, CapBot at ICRA 2025: a sibling battery-free swarm robot from KU Leuven, with Inria and the University of Sheffield. It runs on supercapacitors only, fully recharges in 16 s, runs 51 minutes at top speed, and can pass up to half of its charge to a peer in under 20 s. It is the closest published work to the supercapacitor power of DotBot v3.

Inside, and what powers it

The platform · The robot 2/2

Figure 18: Top: the nRF5340 module, the RGB LED, the Lighthouse photodiode and the ON/OFF switch.

Figure 19: Underneath: two 120 F supercapacitors, and the two gearmotors with their encoders.

no battery 2 x 120 F supercapacitors

30 s to a full charge

~1 h of typical use

OFF also empties the supercaps, for safety

On top (Figure 18): the nRF5340 module, a chip with two cores; the network core runs the radio, the application core drives the board and runs your code. Next to it, the RGB LED and the Lighthouse photodiode. Turn the robot over (Figure 19): the two gearmotors sit between the wheels, each with an encoder that counts wheel turns. The USB-C port goes to an on-board programmer, and headers expose UART, I2C and SPI for add-ons.

There is no battery. Energy comes from the two 120 F supercapacitors underneath. About 30 seconds on the barrel jack or a contact-pad charging station fills them. From the team’s bench experience, not a controlled measurement: about 20 minutes driving non-stop at full speed, about an hour of typical use, about 3 hours idle in the bootloader. So if your robot slows down or vanishes from the map, the first question is: is it charged?

One more part on top, at the left edge (Figure 18): the ON/OFF switch, SW3. Switching it OFF does more than cut the power: it also discharges the supercapacitors through a 4.7 ohm resistor on the board, so a robot that is off holds no stored energy. A charged supercapacitor bank can deliver large currents, so this is a safety feature: to put a robot away, switch it OFF.

Controller, console, simulator

The platform · PyDotBot 1/2 runs on your PC

Figure 20: The console of a simulator with 10 robots: the live map in the middle, testbed controls on the left, map layers on the right.

• The controller turns the swarm into a REST API on your laptop, at localhost:8000
• The console is a web page on that API: live map, joystick, flashing
• The simulator serves the same API with no robots, so the same script runs on both

You run one of these yourself in step 3: the simulator. Figure 20 is its console, here with 10 robots. The controller is the piece that matters: dotbot run controller turns the swarm into a REST API on your laptop, on port 8000, and the console at /console is a web page on that API, with the live map, a joystick and the flashing controls.

dotbot run simulator gives you the same API with simulated robots. That is the trick of the whole workshop: in step 4 your script talks to the simulator, and in step 6 the very same script talks to the real robots, unchanged. In the room, I run the real controller for the 20 robots on the floor; you run the simulator’s on your laptop, and from step 5 on your script points at the room’s controller instead.

That is everything you touch today: the robot, the controller and its console. Next, the complexity underneath, which you never have to see.

Where am I? Lighthouse 2

The platform · Localization 1/2 robot computes its position base station in the room

Problem Camera tracking is expensive and gets harder with more robots

Solution Off-the-shelf base stations, and every robot computes its own position on board

A base station sweeps infrared planes across the floor; each robot times them, and a one-time calibration turns that into (x, y) in mm.

Figure 21: The base station sees the floor at an angle (left); four known corners map it onto the square field of the map, in millimetres (right).

Now the complexity underneath, starting with how a robot knows where it is. Look at the base station on its stand: it is a Lighthouse 2, built for virtual reality headsets. It spins planes of infrared light across the room. The robot has no camera and no GPS: one photodiode times when each plane passes, and those times are angles seen from the base station (left of Figure 21).

Angles are not millimetres yet. Calibration fixes that: place one robot on the four corners of the field, once per setup, and the result is pushed to every robot (right of Figure 21). From then on, each robot computes its own position.

One photodiode per robot

The platform · Localization 2/2 runs on the robot

Figure 22: The one Lighthouse sensor on a DotBot v3: a photodiode on top of the board.

• One diode and one chip per robot, decoded on a low-power microcontroller: no FPGA, no camera
• Cheap: about $200 per base station, $2.30 + $1.20 for the diode and chip
• Decentralized: after a one-time scene solve, every robot computes its own position

Figure 23: Lighthouse Localization of Miniature Wireless Robots. IEEE RA-L, 2024. DOI 10.1109/LRA.2024.3405345

The whole sensor is the one photodiode in Figure 22, on the robot’s centreline. Figure 23 is the paper behind it, in IEEE Robotics and Automation Letters, 2024. Its contribution: decoding the Lighthouse 2 signal in real time on a small low-power microcontroller, with a single photodiode per robot, where earlier work needed several receivers and an FPGA.

The cost is the point: a base station is about 200 dollars, the diode and its front-end chip about 2.30 and 1.20 dollars in small quantities, against tens of thousands for camera motion capture. And it scales: the scene is solved once on a computer, then each robot localizes itself.

Talking to 100 robots: Mari

The platform · Mari 1/3 net core firmware on the robot gateway in the room

Problem Wi-Fi and BLE struggle past about 50 robots

Solution About 100 robots per gateway, low latency for interactive control, a TSCH schedule for reliability

Figure 24: One gateway, up to 102 robots with responsive control.

• The gap: Wi-Fi and BLE struggle past about 50 robots
• TSCH on ordinary BLE radios: nRF52840, nRF5340
• More robots, more gateways, with no coordination between them

Figure 25: Mari: Responsive Wireless Communication for Low-Power Large-Scale Robot Swarms. Ad Hoc Networks, 2026 (journal pre-proof). DOI 10.1016/j.adhoc.2026.104423

Best Demo Award

Figure 26: Demo: Mari Allows Connecting Large Scale Robot Swarms using TSCH over BLE and Multiple Independent Gateways. EWSN 2025. hal-05280262

How do you talk to a hundred robots at once (Figure 24)? The Mari paper (Figure 25, Ad Hoc Networks 2026) starts from a gap: Wi-Fi and BLE are what swarms usually use, and scaling those beyond about 50 robots is hard. Cellular systems scale, but are inappropriate for small low-power robots.

Mari, the Micro-robot Access Radio Infrastructure, has two parts. A link layer based on TSCH, which runs on ordinary 2 Mbps BLE radios; it is implemented on the nRF52840 and the nRF5340. And an infrastructure: gateways that do not need to coordinate with each other, all connected through an MQTT broker, with a Python library, marilib, on top. One gateway serves up to 102 robots with responsive control; more robots means more gateways. It is open source: firmware, libraries and monitoring tools. The live demo of Mari (Figure 26) won the Best Demo Award at EWSN 2025.

One slot each: the schedule

The platform · Mari 2/3

Figure 27: The smallest Mari schedule, for up to 10 robots, as in the Mari paper.

+2.5 ms per robot added to the slotframe

265.22 ms slotframe for 102 robots, 149 slots

40 to 231.9 ms median round trip, 10 to 102 robots

Here is how one gateway shares the air (Figure 27). Beacons hop over the 3 BLE advertising channels, every other slot over the remaining 37 channels. TSCH is time-slotted channel hopping: time is cut into slots, each slot on a different channel. A sequence of slots is a slotframe, and it repeats. Beacon slots let the gateway announce itself and keep everyone in sync; shared slots are where new robots ask to join, and the gateway answers in the downlink slot right after; and every robot owns one uplink slot per slotframe, so robots never collide with each other.

Mari drops link-layer acknowledgments, which keeps a slot at 1.78 ms, against 10 ms in IEEE 802.15.4e. The trade-off: each extra robot adds about 2.5 ms to the slotframe. The paper defines four schedules: tiny, 10 robots, 30.26 ms slotframe, 40.0 ms median round trip; medium, 44 robots, 119.26 ms, 96.0 ms; big, 66 robots, 179.78 ms, 146.1 ms; and huge, 102 robots, 265.22 ms, 231.9 ms.

Moving between gateways

The platform · Mari 3/3

Figure 28: Handovers in Mari: the robot decides, the gateways never talk to each other.

>97% packets delivered, 100 robots, 1 gateway

<4 s for all 100 to join at once

0.73 s 95% of handovers, 100 robots moving together

226 ms round trip with 200 robots on 2 gateways

Mari, Ad Hoc Networks, 2026: up to 200 nodes in the evaluation, 724 robots on 8 gateways in the DotBot testbed.

One gateway stops at 102 robots, so Mari scales sideways: add gateways (Figure 28). The gateways do not coordinate at all; they all reach the same MQTT broker, and a gateway simply drops messages for robots that are not its own. The robot decides when to move: while joined, it uses the slots that are not its own to listen for beacons of other gateways, and it switches when another gateway is clearly stronger, 12 dB in the paper’s setup, then waits at least 5 seconds before considering another switch.

The numbers, all from the paper. With 100 nodes on one gateway: more than 97% of packets delivered at 2 metres, 231.9 ms median round trip, and all 100 associated in under 4 seconds when they join at the same time. When all 100 move together between two gateways, 95% of handovers complete in 0.73 s from the robot’s side; a single robot can hand over in less than 50 ms. With 200 nodes on two gateways, the round trip stays at 226 ms. And in the DotBot testbed, 8 gateways connected up to 724 robots.

Mari in action

The platform · Mari video

Figure 29: Mari mobility tests, on YouTube: Mari is a new link layer for connecting robot swarms! (mobility tests), youtube.com/watch?v=AXdZniSUftc

Play the Mari mobility tests video (Figure 29). The slide shows the video thumbnail, which opens YouTube in a new tab. For an offline venue, download the video beforehand to website/videos/mari-mobility.mp4 and re-render: the slide then plays the local file.

Safe programming: SwarmIT

The platform · SwarmIT 1/2 runs on the robot: bootloader + sandboxed app

Problem Buggy user code can take a robot out of the testbed

Solution Your app runs in a TrustZone sandbox, so every robot can be stopped, reflashed and recovered over the air

Figure 30: SwarmIT on the nRF5340: your app runs in a hardware sandbox beside the secure bootloader, and the second core keeps the radio link alive.

Figure 31: SwarmIT: Turn Your Collection of Robots into a Robust and Programmable Swarm Testbed. DCOSS-IoT, 2026. hal-05661394

Next question: how does your code get onto 20 robots, and what happens when it is buggy? That is SwarmIT (Figure 31, DCOSS-IoT 2026). A common design for testbeds is to attach a small Raspberry Pi-like computer to every robot to manage it, which can more than double the cost. SwarmIT is software only: it reuses ARM TrustZone, a hardware feature of the robot’s microcontroller.

In Figure 30, on the application core, the SwarmIT bootloader lives in a secure 64 kB region, and your app runs in the non-secure world, with access to most peripherals but not to the parts SwarmIT needs. Position, battery and radio come to your app through a few secure functions. Your app must feed a watchdog at least once a second; if it crashes or loops forever, the watchdog resets the core into the bootloader. Meanwhile the network core never stopped, so the robot is still connected: your code cannot brick it, and nobody has to walk over with a cable. Boot takes under 252 ms.

One command, the whole swarm

The platform · SwarmIT 2/2 runs on your PC

dotbot swarm flash spin -ys   # flash every robot over the air, then start
dotbot swarm stop             # back to the bootloader
dotbot swarm start            # run the loaded app again

Figure 32: From your PC to every robot at once.

~1 min 110 devices, 12 kB app (SwarmIT paper)

<4 min 600 robots, 4 kB app (Mari paper)

• Broadcast in 128 B chunks: the next chunk goes out once every robot has acknowledged the last one
• Checked before it runs: each robot compares a SHA-256 hash, and the bootloader switches only if it matches

From your laptop this is one command: I ran it this morning to put remote-control on every robot, and duos who are ahead run it themselves in the extra module, Flash it. Figure 32 shows the path: your PC, the MQTT broker, the gateway, then the radio to every robot at once; on each robot the bootloader receives the app, start runs it in the sandbox, and stop brings the robot back to the bootloader. Over the air, the update is broadcast to all robots at once: first a notification with the image size and its SHA-256 hash, then 128-byte chunks, each sent once every robot has acknowledged the previous one. At the end, each robot checks the hash, and the bootloader switches to the new app only if it matches.

The published numbers: about a minute to program a 12 kB app on 110 devices, measured in the SwarmIT paper; and in the Mari paper’s DotBot deployment, a 4 kB image on 600 robots in under 4 minutes.

Software: PyDotBot

The platform · PyDotBot 2/2 runs on your PC

Problem Many parts to fit together

Solution One command line, a controller with a REST API, a console and a simulator

One dotbot command for the whole workflow, from one robot to a thousand. Install it with pip install pydotbot.

dotbot fw Build, fetch and list firmware. Never touches hardware.

dotbot device Flash one board on a USB cable and read its info.

dotbot swarm The whole fleet over the air: status, flash, start, stop.

dotbot run Processes on your computer: controller, gateway bridge, simulator, demos.

Every command and flag: the CLI reference at pydotbot.readthedocs.io.

Everything you touch today is PyDotBot, the Python control plane for the DotBots. It is one command, dotbot, with four main subcommands, picked by what you are doing right now. fw builds or fetches firmware files and never touches a robot. device flashes one board on a cable. swarm talks to the whole fleet over the air: that is the extra module, Flash it. run starts processes on your computer: the controller, the bridge to a gateway, the simulator, demos. Two more, config and site, manage your settings and the place you work in; you run dotbot config init in step 3. All of it is documented in the CLI reference on Read the Docs, which is your textbook today.

How it fits together

The platform · Architecture

Figure 33: From you to the robots: the console, PyDotBot’s web page served by the controller, and your script talk to the controller’s REST API. Run it as dotbot run controller to reach the real robots, or as dotbot run simulator for the same API with simulated robots inside.

Figure 33 reads from left to right, starting with you. The console in your browser and your Python script both talk to the controller over its REST API. The console is PyDotBot too: the controller serves it, which is why it is green like the controller.

The controller runs in one of two modes. dotbot run controller connects to an MQTT broker; the broker can be hosted, like the broker at Inria, or run locally in this room. The gateway relays MQTT to the Mari radio, and each robot’s network core runs Mari and keeps the robot connected, while the application core runs your app inside the SwarmIT sandbox. dotbot run simulator is the same controller with simulated robots inside: no broker, no gateway, no robots, the same API and the same console. That is why the same script runs on both.

dotbot swarm flash, start and stop also start from your side: they go through the broker and the gateway to every robot at once, which is SwarmIT over the air.

Scale: 725 robots

The platform · Scale

Figure 34: 725 DotBots in one campaign, Limerick, January 2026, on YouTube: The 1,000 DotBots Testbed: First Large-Scale Deployment, youtube.com/watch?v=3Pfa05X7uXc

Everything you saw today also runs at scale. This video (Figure 34) is the largest deployment so far: 725 DotBots in one campaign, in Limerick, in January 2026. The Mari paper reports the network side: up to 724 robots connected through 8 gateways, and a firmware update of 600 robots in under 4 minutes. Today we use 20 robots and one gateway, with the same software.

The slide shows the video thumbnail, which opens YouTube in a new tab. For an offline venue, download the video beforehand to website/videos/725-deployment.mp4 and re-render: the slide then plays the local file.

We hide the complexity

The platform · How you program it 1/2 runs on your PC

All of this is packaged for you. This is a whole program:

hello.py

import time

import academy

academy.connect("http://localhost:8000")  # your simulator
robot = academy.bot("000000")  # its first robot, by label
robot.led(255, 0, 0)  # red: red, green, blue, each 0 to 255
time.sleep(1)
robot.led(0, 255, 0)  # green
time.sleep(1)
robot.led(0, 0, 255)  # blue
robot.drive(speed=50, seconds=2)  # 50 mm/s for 2 s: about 100 mm

What it does not have to deal with

• 📡 radio slots, gateways and the MQTT broker
• 📍 base stations and calibration
• 🛡️ the sandbox and the bootloader
• 🤖 motors, encoders and the control loop

The same script runs on the simulator and on the real robots. No cables.

Everything I just showed you, the radio schedule, the localization, the sandbox, the gateways, is packaged so that you never have to think about it today. The script on the left is the program you build in step 4, one command at a time: connect to the controller, pick a robot, change its LED color, drive it forward at 50 mm/s for two seconds. The controller does the rest: it talks to the broker, the broker to the gateway, the gateway to the robot, and the robot holds that wheel speed with its own control loop. And because the simulator serves the same API, the same script runs on both, with no cable anywhere.

Many ways to program a DotBot

The platform · How you program it 2/2

Figure 35: The same robot, four ways in: from a Python script for the whole swarm down to C on one robot over a cable. Today you use the two green rungs, with no cables; the grey ones are also possible.

The platform does not lock you in at the top. Figure 35 shows the ways in, all on the same robot. Today you use the two green rungs. At the top, a Python script talks to the controller’s REST API and moves the whole swarm, with no cables: steps 4 to 8. Just below, prebuilt sandbox apps, like spin or lights, go to every robot over the air with dotbot swarm flash: that is how remote-control got onto every robot this morning, and you can do it yourself in the extra module, Flash it.

The grey rungs are also possible. You can write your own sandbox app in C, even bare-metal code that writes the chip’s registers directly, like the regblink example that blinks the LED, build it, and flash it over the air to the whole swarm with the same command. And at the very bottom, you can plug one DotBot into a USB-C cable and program it directly through its on-board programmer, with any firmware you like, outside the sandbox. The rule of the platform is that every layer is a real way in, and you can move between them without starting over.

Hands-on

Next: step 3, your swarm in the simulator

Now it is your turn. Step 3 first, all together: check your install and start your own simulator. Then step 4, your own script in that simulator. The next slides are the ones I come back to at the start of each step.

Check your install, start it now

Step 3 · Your swarm in the simulator

cd ~/dotbot-academy
source .venv/bin/activate
dotbot --version
dotbot config init
dotbot run simulator --robots 4

Windows: .\.venv\Scripts\Activate.ps1 to activate. Told to upgrade? pip install --upgrade pydotbot

Together Check the version, start the simulator: four robots on the map

Duos Core: drive one from the console pad

Something fails? Raise your hand: we fix it now, not at step 4.

Step 3, together, right now: everyone does it at the same time, and I walk the room. Go to the dotbot-academy folder, activate the environment, and print the version. If I announce a newer one, upgrade with pip install –upgrade pydotbot. Then dotbot config init, once, and dotbot run simulator –robots 4: the browser opens on four simulated robots. The step 3 page has the same commands. Duos who started installing during the platform talk check that pip has finished.

Common fixes. pip fails to build pygame: that is Python 3.14, or 3.10 or older; install 3.13, delete the .venv folder and create it again. dotbot: command not found: the environment is not active in that terminal. The simulator starts and exits a second later, with no clear error: port 8000 is already taken, usually by a simulator left running; stop it, or add –controller-http-port 8001. No browser tab: open http://localhost:8000/console/ by hand. A laptop that refuses to install anything: move the duo to a lab Mac.

Light it, drive it

Step 4 · My script moves a simulated robot

hello.py

import time

import academy

academy.connect("http://localhost:8000")  # your simulator
robot = academy.bot("000000")  # its first robot, by label
robot.led(255, 0, 0)  # red: red, green, blue, each 0 to 255
time.sleep(1)
robot.led(0, 255, 0)  # green
time.sleep(1)
robot.led(0, 0, 255)  # blue

Together Download academy.py (the box at the top of the step 4 page), save hello.py, run python hello.py: robot 000000 turns red, green, blue

Duos Core: add a drive(), change its speed and time, then add a spin()

Challenge If there is time: a square, turning left

led(), drive(), spin(): speeds in mm/s, and each move stops by itself.

Step 4, one command at a time. Together: download academy.py from the box at the top of the step 4 page, save hello.py, then python hello.py. Robot 000000 turns red, green, then blue: led sets the color. Then the duos add one line, drive, forward at 50 mm/s for two seconds, about 100 mm, and change the speed and the time: 100 mm/s for one second should cover the same distance. Then one more line, spin, which turns on the spot for a time, not by an angle; a negative speed turns left. Speeds are in millimetres per second, and every move stops by itself after its seconds. If there is time, the challenge: a square, one color per side, turning left at each corner, so it stays clear of the robot to its right. QUARTER_TURN, the seconds for about 90 degrees, is approximate, so a duo may have to tune it. Skip it if the room runs late: step 6 runs hello.py first.

The real path

Step 5 · Connecting to the real robots

Figure 36: What you need from step 5 on: your console and your script talk to my controller at http://<instructor-ip>:8000; it reaches the robots through the broker, the gateway and the radio.

Step 5. Figure 36 is all you need from the architecture of Figure 33. Your script and your browser no longer talk to the simulator on your laptop: they talk to my controller, the one I started this morning with –controller-http-host 0.0.0.0, so that your laptops can reach it over the Wi-Fi. Its address is on the board. Behind it, the MQTT broker runs on my laptop and carries every message; the gateway, the board plugged into my laptop, turns those messages into Mari radio packets; and every robot runs remote-control, the program that answers the controller. None of this changes your code: only the address and the label.

Find your two robots

Step 5 · Connecting to the real robots

connect.py

"""Step 5: connecting to the real robots.

Point academy at the instructor's controller, find your two robots by their
labels, and light them up to check they are yours.
You should see: your two robots on the floor turn green, and their dots in
the instructor's console turn green too.
"""

import academy

BASE_URL = "http://192.168.1.10:8000"  # TODO: the instructor's controller, from the board
LABELS = ["A1B2C3", "D4E5F6"]  # TODO: the labels on your two robots

robots = academy.connect(BASE_URL)
print(len(robots), "robots on the controller")

for label in LABELS:
    robot = academy.bot(label)
    print("Found", label, "at", robot.position())
    robot.led(0, 255, 0)  # green: this one is yours

Instructor The console link on the board: http://<instructor-ip>:8000/console/

Duos Find your two labels in the console, then light them with connect.py: both turn green

Open my console, find your two robots by the labels on their stickers in the List view, then run connect.py with my controller’s address and your two labels: both robots turn green, on the floor and on the map. Nothing moves yet: a duo whose robots do not light up is the one to sort out now, before scripts start driving. Keep the address and the labels at hand: step 6 uses them.

On the floor

Step 6 · My script moves a real robot

real.py

import time

import academy

BASE_URL = "http://192.168.1.10:8000"  # TODO: the instructor's controller
LABEL = "A1B2C3"  # TODO: the label on one of your two robots

academy.connect(BASE_URL)
robot = academy.bot(LABEL)
robot.led(255, 0, 0)  # red: red, green, blue, each 0 to 255
time.sleep(1)
robot.led(0, 255, 0)  # green
time.sleep(1)
robot.led(0, 0, 255)  # blue

Duos Core: real.py on one robot, then add the step 4 lines one at a time: drive, back, spin

Challenge If there is time: the square, with QUARTER_TURN tuned again

Same script, two lines changed. Watch where it ends.

Step 6, the promise of the whole workshop: the script you wrote against the simulator, on a real robot. real.py is step 4’s first hello.py with two lines at the top: BASE_URL, the address of my controller, the same as in connect.py, and LABEL, one of your two robots. Light it first, then add the step 4 lines one at a time: drive forward and back, then the spin. Put a small mark beside the robot before you start. Watch where it ends: it comes back close to the mark, not on it, and the spin is not quite a full turn. If there is time, the square: same file as step 4, BASE_URL and LABEL changed, and QUARTER_TURN tuned again, because a turn for a time gives a different angle on a real floor. The wheels slip, the robot runs on supercapacitors that run down, and the dot on the map is measured, not computed. Keep that drift in mind: step 7, after the break, is the answer. For a duo that is ahead: run the square on both robots and see where each one ends.

Go there by itself

Step 7 · Moving to a certain position

example.py

import time

import academy

academy.connect("http://localhost:8000")  # your simulator
robot = academy.bot("000000")  # its first robot

x, y = robot.position()  # in mm: x grows to the right, y grows DOWN the map
print("Start:", x, y)

for target in [(x, y - 300), (x + 300, y - 300), (x, y)]:  # up, right, back
    robot.led(0, 0, 255)  # blue while it drives
    robot.goto(*target)
    while not robot.arrived():
        time.sleep(0.5)
    robot.led(0, 255, 0)  # green: there
    off = academy.distance(robot.position(), target)
    print("At", robot.position(), f"{off:.0f} mm from {target}")

• drive(), spin(): open loop, they count time
• goto(x, y): closed loop, the robot checks its position until it is there
• (x, y) in mm, origin at the top-left, y grows down
• arrived() instead of sleep()

Duos Core: there and back with goto()

Step 7, after the break. Your step 6 robot did not end exactly where the simulator’s did, and the square does not quite close on the floor: drive and spin are open loop, they run the wheels for a time and never check where the robot ended. goto is closed loop: the robot reads its own lighthouse position all the way and corrects until it is within the threshold, 60 mm by default. position gives x and y in millimetres, with the origin at the top-left corner of the map and y growing down, so up the map is y minus 300. goto returns at once, so wait with arrived in a loop instead of guessing a sleep. The example goes up, right and back, and prints how far from each target it stopped. Core: there and back with goto. For a duo that is ahead: a goto square, which comes back where it started, and how close it stops for smaller thresholds.

Both at once

Step 8 · My two robots at once

goto() returns at once: give every robot its target first, then wait for all of them.

Together Run two.py as it is: A drives, then B, one after the other

Duos Core: make them leave at the same moment, with goto()

Optional academy_parallel.py: drive() and spin() on both robots at the same time, with wait=False

Step 8, in two moves. First, two.py as it is: robot A turns red, B blue, and A drives 200 mm, then B, because drive returns only once its robot has stopped. Then the duos’ change: goto returns at once, so give both robots their goto first, 200 mm up the map, then one loop that waits for both, and they leave together. drive and spin can do it too, with the optional tool at the end of the step 8 page, academy_parallel.py: with wait=False each move returns at once and a background thread keeps the robot moving, and wait() waits for both. For a duo that is ahead: time the two ways; with twenty robots instead of two, that is the whole point of a swarm.

Extra: Flash it

Extra · For advanced groups or when time allows

Put your own programs on your two robots, over the air: lights, spin, then remote-control again.

Duos With your duo.toml: dotbot swarm -c duo.toml stop, then flash lights -ys, spin, remote-control

Every number in these slides comes from the papers on the References page or from the team’s DotBot v3 hardware notes. Docs: pydotbot.readthedocs.io.

The extra module, for duos who finish step 8 early: the Extra: Flash it page. With the duo.toml I give you, you flash your own two robots over the air, the dotbot swarm flash of the SwarmIT slides: lights, then spin, then remote-control, which every script needs, so always end on it. Advanced duos can go one rung lower and flash regblink, a bare-metal app that writes the LED registers by hand.

Extra slides

For questions and duos ahead

Backup material, shown only if someone asks.

Calibrating from circles

Extra · Localization

Figure 37: A robot spinning on one wheel traces small circles. From an angle they are ellipses (left); the method finds the view in which they are circles again, which is the floor seen from above (right).

7.77 mm mean error, calibrated from circles

5.37 mm with the manual method, for comparison

Figure 38: Automatic Lighthouse Calibration Using Conics for Indoor Robot Localization. IEEE RA-L, 2025. DOI 10.1109/LRA.2025.3575319

The 4-corner calibration you will see today needs someone to place a robot on known points, which is labour that does not scale to hundreds of robots. The 2025 paper in Figure 38 replaces it with the robot’s own motion: the robot powers one motor and spins, its photodiode tracing a circle 5 cm across. Seen from the base station at an angle, those circles are ellipses (Figure 37). Conic algebra finds the transformation that turns them back into circles, which is the floor seen from above.

Tested on a 2 by 2 metre area against camera motion capture: 7.77 mm mean error, close to the 5.37 mm of the earlier method based on manual measurements, with minimal user intervention. The paper calls it a step toward scalable, decentralized calibration for large robotic systems.

OpenSwarm, and who funds this

Extra · Funding

• OpenSwarm is a research project funded by the European Union, 2023 to 2026
• Its testbed: 1,000 small wheeled robots for indoor spaces, such as a building floor, that researchers can monitor, control and reprogram remotely
• The DotBots are that testbed: about 1,150 were produced for OpenSwarm, and the robot, Lighthouse, Mari and SwarmIT papers all acknowledge its grant
• Partners in the papers: Inria in Paris, with KU Leuven and the University of Sheffield on the CapBot robot
• Since May 2026 the testbed continues at Inria Paris

Figure 39: The OpenSwarm project logo.

Horizon Europe · Grant Agreement No. 101093046 This project has received funding from the European Union’s Horizon Europe Framework Programme under Grant Agreement No. 101093046. Views and opinions expressed are however those of the author(s) only and the European Commission is not responsible for any use that may be made of the information it contains.

If someone asks who pays for this. The DotBot testbed was built in OpenSwarm (Figure 39), a research project funded by the European Union’s Horizon Europe Framework Programme, grant agreement number 101093046, which ran from 2023 to April 2026. Its goal on our side was a testbed of 1,000 small wheeled robots for indoor environments that researchers can monitor, control and update remotely; about 1,150 DotBots were produced for it. Every paper behind this deck acknowledges that same grant, and no other funding: the DotBot demo, Lighthouse and its calibration, Mari and SwarmIT. So does CapBot, a battery-free robot from KU Leuven, with Inria and the University of Sheffield. The project ended in April 2026, and the testbed now continues at Inria Paris.