Source-linked AI summary
The Robotarium: A remotely accessible swarm robotics research testbed
Daniel Pickem, Paul Glotfelter, Li Wang, Mark Mote, Aaron Ames, Eric Feron, Magnus Egerstedt
TL;DR
Multi-robot testbeds are essential for moving beyond simulation, but their cost and operational complexity limit access. The paper presents the Robotarium, a remotely accessible testbed combining flexible experimentation with formal, minimally invasive safety guarantees. Its experiments demonstrate long-term autonomous operation, while its safety architecture also supports scalable decentralized computation.
Problem
Multi-robot research needs physical deployment because simulations and analytical models cannot faithfully capture all coordination issues, yet testbeds are costly and complex to operate.
Method
The paper develops a remotely accessible testbed combining centralized server coordination, simulation-based verification, safety scores, and formal collision-avoidance methods.
Results
The Robotarium provides flexible remote experimentation with provable collision avoidance; autonomous charging achieved success rates of 98.1%, 99.1%, and 100% across three experiments.
Takeaways & Limitations
The Robotarium demonstrates that multi-robot hardware can be made remotely accessible to trusted and untrustworthy users without overly constraining executable control algorithms.
Abstract
from arXiv · showhide
This paper describes the Robotarium -- a remotely accessible, multi-robot research facility. The impetus behind the Robotarium is that multi-robot testbeds constitute an integral and essential part of the multi-robot research cycle, yet they are expensive, complex, and time-consuming to develop, operate, and maintain. These resource constraints, in turn, limit access for large groups of researchers and students, which is what the Robotarium is remedying by providing users with remote access to a state-of-the-art multi-robot test facility. This paper details the design and operation of the Robotarium and discusses the considerations one must take when making complex hardware remotely accessible. In particular, safety must be built into the system already at the design phase without overly constraining what coordinated control programs users can upload and execute, which calls for minimally invasive safety routines with provable performance guarantees.
I. INTRODUCTION
Multi-robot deployment remains difficult despite advances in algorithms and hardware, because simulation cannot faithfully capture all coordination issues. The Robotarium addresses this gap with flexible, remotely accessible experimentation and formal safety measures.
- I. INTRODUCTION: Multi-robot research still faces a difficult transition from theory and simulation to robust, large-scale deployment.Physical deployment exposes issues that simulations and analytical models cannot fully capture.
- I. INTRODUCTION: The Robotarium is an open, remote-access testbed designed to support diverse scientific questions and coordination algorithms.Its flexibility is intended to address the theory-simulation-practice gap.
- I. INTRODUCTION: The platform treats safety as avoidance of damaging collisions and uses safety scores to determine whether submitted code can execute unmodified.This enables remote access for trusted, untrustworthy, and malicious users while providing provable damage avoidance.
- I. INTRODUCTION: Existing mobile testbeds often use larger, more expensive robots, obstructing experiments with large numbers of robots.A GRITSBot costs approximately $60 to build or $100 preassembled.
- I. INTRODUCTION: Unlike other remotely accessible mobility testbeds, the Robotarium explicitly guarantees provable damage avoidance even for untrustworthy or malicious users.Built-in online and offline safety measures prevent accidental or purposeful robot damage.
B. Sensor Networks Testbeds and Cybersecurity
The Robotarium is designed as a publicly accessible swarm-robotics research facility that lowers entry barriers while supporting flexible experimentation, maintenance, and safe code execution.
- B. Sensor Networks Testbeds and Cybersecurity: The Robotarium provides public web access for testing varied multi-robot algorithms and supporting robust, long-term operation with minimal intervention.Its design combines position tracking, automated recharging, and provably collision-free motion execution.
- B. Sensor Networks Testbeds and Cybersecurity: Its high-level requirements target accessibility, easy maintenance, intuitive interaction, and safe, secure code execution.These requirements follow from its purpose as a shared remotely accessible facility.
- B. Sensor Networks Testbeds and Cybersecurity: The platform is intended to support inexpensive replication through low-cost, open-source robots, with up to 20 robots currently available.The requirement emphasizes accessible hardware and replication.
- B. Sensor Networks Testbeds and Cybersecurity: A public web interface supports code submission, intuitive interaction, and simple retrieval of experimental data and video.This requirement makes remote experimentation accessible to users without direct local access.
- B. Sensor Networks Testbeds and Cybersecurity: The design links simulation and physical execution through data-driven characterization of the simulation-hardware gap.The stated goal is a seamless switch between development in simulation and robot execution.
- B. Sensor Networks Testbeds and Cybersecurity: Automatic charging and tracking reduce the cost and complexity of maintaining a large robot collective.These convenience features support operation with less manual maintenance.
- B. Sensor Networks Testbeds and Cybersecurity: Guaranteed collision avoidance is integrated to protect the testbed from damage and misuse.Safety is treated as a design requirement rather than an external operating procedure.
B. Prototype Design
The Robotarium combines compact robots, tracking, wireless communication, charging, simulation, virtualization, APIs, and server coordination into an integrated remotely accessible testbed.
- B. Prototype Design: The hardware includes robots, overhead position tracking, wireless communication, and arena-integrated charging, while the backend provides simulation, virtualization, APIs, and coordination.These components support interaction among users, robots, and the testbed.
- B. Prototype Design: The current testbed measures 130×90×180 cm and uses inexpensive miniature GRITSBots to simplify operation and maintenance.The compact footprint is paired with features intended to support effortless swarm maintenance.
- B. Prototype Design: GRITSBots use a modular main board for intelligence, connectivity, power conditioning, and charging, alongside a motor board for motion.The modular design separates high-level and motion-related functions.
- B. Prototype Design: The system architecture separates local infrastructure components from user-facing remote components, with tracking, wireless communication, and virtualization directly interacting with robot hardware.Other components manage users, code verification and upload, and testbed data.
- B. Prototype Design: The ESP8266 upgrade supports wireless communication, pose estimation, low-level control, and high-level robot behaviors.Its WiFi transceiver supports IEEE 802.11 B/G/N standards with bandwidth up to 54 MBit.
- B. Prototype Design: An overhead webcam and ArUco tags provide global robot positions needed for feedback control and automated maintenance.Global position data support tasks such as recharging and experiment setup.
- B. Prototype Design: Wireless charging uses receiver coils on the robots and Qi-standard transmitters embedded in the arena surface.Automatic recharging is presented as essential for long-term, self-sustaining operation.
2) Software:
The Robotarium software combines simulation, user interaction, and centralized coordination to support remote multi-robot experimentation with layered safety controls.
- The software is organized into simulation-based components, testbed-interaction components, and coordinating server applications.
- Simulation: Simulation supports user-code prototyping, pre-execution verification, and the addition of virtual robots.Users can test algorithms locally before submitting them, while the same infrastructure checks execution before deployment.
- Interaction: Users interact locally through provided APIs or remotely through web-based code upload.Local access is primarily for development, while remote submissions are tested in simulation before execution.
- Coordination: A central server executes user code, routes commands and data, provides global position data, manages virtual robots, and logs generated data.Centralized execution improves robustness, simplifies logging, supports formal safety guarantees, and facilitates automatic maintenance, though communication bottlenecks can arise.
- Safety: Remote experiments combine offline simulation verification with online barrier-certificate collision avoidance, while users may bypass online safeguards after achieving a sufficiently high safety score.Real-time teleoperation is not enabled, and remote access requires applicant screening.
A. Simulation-based Verification
The Robotarium evaluates experiments through Monte Carlo safety scoring and enforces collision avoidance with minimally invasive safety barrier certificates.
- Simulation-based Verification: Monte Carlo simulation estimates an experiment’s collision damage and safety over multiple runs with uncertain dynamics, initial positions, and camera observations.The current procedure uses 50 simulation runs.
- Safety scoring: Damage D is modeled as cumulative kinetic-energy loss during collisions across N robots over a time horizon T.The indicator I_i(t) identifies collision intervals, while δ_i(t) represents the rate of kinetic-energy loss.
- Safety scoring: The discrete-time damage approximation uses robot mass, velocity changes, and the camera-driven time step Δt = 1/30s.The robot mass is m = 60g, and the approximation treats velocity reduction as proportional to lost kinetic energy.
- Safety scoring: The cumulative safety score compares experiment damage with a maximum allowable threshold, while individual scores compare each robot’s damage with its own threshold.Experiments can proceed without modified deployment when the relevant safety score is sufficiently high.
- Safety Barrier Certificates: Safety barrier certificates constrain commands to a forward-invariant safe set, guaranteeing provably collision-free operation.The constraints include pairwise robot separation and workspace boundaries, and are implemented through a convex safe-command polytope.
- Safety Barrier Certificates: Collision avoidance runs in real time at an update rate exceeding 30 Hz.The paper illustrates the mechanism with ten GRITSBots swapping positions while safety barrier certificates remain active.
- Safety Barrier Certificates: The safety model assumes bounded single-integrator robot velocities and encodes minimum inter-robot distance through pairwise safe sets.The single-integrator model can be mapped to the GRITSBot’s unicycle dynamics, and barrier certificates can extend to more complex systems.
- Safety Barrier Certificates: A quadratic-program controller minimizes deviation from user commands subject to safety constraints, modifying commands only when collisions are imminent.When no collision is impending, user code is executed faithfully; otherwise, the closest safe command in the least-squares sense is applied.
Scalability of Safety Barrier Certificates:
Centralized barrier-certificate computation becomes less scalable as robot count grows, whereas decentralized computation maintains low latency for large swarms.
- Centralized safety-barrier computation has linearly increasing decision variables and quadratically increasing pairwise safety constraints as the swarm grows.The paper identifies centralized computation as a scalability concern and proposes neighborhood-based decentralized alternatives.
- With an 8cm safety distance and 20cm neighborhood radius, each robot’s neighborhood contains at most 26 other robots.This bounds each decentralized quadratic program to 2 decision variables and at most 26 linear constraints.
- Decentralized safety-barrier computation remains below 10ms for 100 robots and supports 100 GRITSBots at 185Hz.The reported result characterizes a fully parallel implementation after dividing total decentralized computation time by N.
V. USAGE
The Robotarium’s usage features target continuous operation, safe remote access, and reduced simulation-to-hardware execution gaps.
- The Robotarium emphasizes continuous operation, automatic robot recharging, safe remote access, and characterization of the simulation-hardware gap.
- These features are presented as mechanisms for long-term operation with minimal operator intervention and maintenance.
A. Long-term Operation
The Robotarium demonstrated reliable long-term operation through autonomous wireless charging across three continuous multi-robot experiments.
- The experiments provided evidence for the reliability of the GRITSBot wireless charging mechanism and continuous Robotarium operation.Reliable autonomous charging is identified as a prerequisite for robust long-term operation.
- 98.1%, 99.1%, and 100% were the autonomous charging success rates across three experiments.Each experiment used three robots and ran continuously for 140, 148, and 240 minutes, respectively.
- Three robots completed 37, 39, and 60 autonomous recharge cycles in the respective experiments.The experiments recorded 111, 117, and 180 total autonomous charge cycles, with manual intervention required twice in the first and once in the second.
B. External Users
External users developed algorithms with the Robotarium simulator and executed them remotely on the physical testbed, demonstrating the platform’s breadth and remote-access capability.
- External user experiments were developed in the Robotarium-provided simulator and executed using the testbed’s software infrastructure.The examples were selected to represent the breadth of algorithms executable on the Robotarium and to validate remote access.
- Figure 5 overlays external users’ experimental data on images of the Robotarium setup.Square markers indicate initial GRITSBot positions, while curves indicate trajectories.
1) Distributed Formation Control of Cyclic Formations from the University of Texas, Dallas:
The external-user examples exercised distributed formation, rendezvous, and synchronization algorithms while relying on Robotarium mappings, safety barriers, and simulation calibration.
- 1) Distributed Formation Control of Cyclic Formations from the University of Texas, Dallas:: The cyclic formation controller used local relative-position measurements and prohibited inter-agent communication.Its Robotarium execution required barrier certificates and a single-integrator-to-unicycle dynamics mapping because the original formulation omitted collision avoidance.
- 1) Distributed Formation Control of Cyclic Formations from the University of Texas, Dallas:: A cycle graph specified local information exchange for an eight-robot rigid-body formation experiment.The experiment also relied on the single-integrator-to-unicycle mapping.
- 2) Fault-tolerant Rendezvous from the University of Illinois Urbana-Champaign:: The fault-tolerant rendezvous algorithm moved agents toward points within a safe set while maintaining connectivity through extendable sensing.Because the original model lacked collision avoidance, execution used Robotarium barrier certificates and dynamics mapping; Figure 5b shows six robots.
- 2) Fault-tolerant Rendezvous from the University of Illinois Urbana-Champaign:: A passivity-based attitude synchronization algorithm used the passivity property of general rigid-body motion in SE(3) to synchronize group attitudes.The supplied passage identifies the algorithm as originally presented in.
- C. The Simulation-Hardware Gap: 30,000 data points were used to estimate linear regression coefficients linking observed velocities to evaluations of the unicycle model.The coefficients were determined by least squares from observed and modeled velocity collections.
- C. The Simulation-Hardware Gap: The calibrated simulator used α1 = 0.8645, α2 = 0.8119, and α3 = 0.4640 to model robot dynamics.The recorded data displayed a linear relationship between observed and modeled velocities, supporting the regression accuracy.
- C. The Simulation-Hardware Gap: The simulation-hardware comparison calculated average trajectory error using the simulated and experimental trajectories.The reported experiment yielded an average difference of 5 mm between simulation and hardware execution.
VI. CONCLUSION
The paper presents the Robotarium as a remotely accessible multi-robot research facility designed to combine flexibility with provable safety for diverse user algorithms.
- The Robotarium combines remote-access hardware and software with formal methods for minimally invasive, provable collision avoidance.The conclusion states that these methods avoid damage without overly constraining executable control algorithms.
- External user examples demonstrated the testbed’s flexibility and versatility with little implementation overhead and provable collision avoidance.