ROS2swarm: Modular Swarm Robotics Software

• ROS2swarm is a modular, hardware-agnostic software package that provides a decentralized framework for swarm robot behaviors using ROS 2.
• It offers a library of ready-to-use movement and voting primitives, implemented as ROS 2 nodes with standardized interfaces for rapid prototyping.
• The package leverages ROS 2’s DDS middleware to ensure scalable, low-latency communication, enabling seamless integration across simulation and real-world robots.

ROS2swarm is a modular, hardware-agnostic software package for developing and deploying swarm robot behaviors in decentralized multi-robot systems using Robot Operating System 2 (ROS 2). It provides a library of ready-to-use behavioral primitives—both for motion and collective decision-making—implemented as ROS 2 nodes with standardized interfaces and full support for platform parameterization, enabling rapid prototyping and experimentation across heterogeneous robotic platforms such as TurtleBot3 (Burger, Waffle Pi) and Clearpath Jackal UGV. The architecture leverages ROS 2’s decentralized Data Distribution Service (DDS) middleware for peer-to-peer communication, robust namespace isolation, and system scalability, lowering the barrier for reproducible and maintainable swarm robotics research (Kaiser et al., 2024).

1. Architecture and Design Principles

ROS2swarm is split across two packages: ros2swarm_python (behavior primitives in Python) and ros2swarm_msgs (custom message types in C++). The internal structure centers on an object-oriented class hierarchy, shown in its UML (see Fig. 3 of the source), with the following core abstractions:

• AbstractPattern: Base class (inherits from rclpy.node.Node) providing core state logic, timer management, and interface setup.
  • MovementPattern: Subclass for behaviors that generate velocity commands from sensor data.
  • VotingPattern: Subclass for collective decision behaviors acting over communication topics.
  • CombinedPattern: Further subclassing to blend multiple primitives (e.g., motion plus voting).
• HardwareProtectionLayer: A distinct node mediating between behavior-generated velocity commands and safety overrides for obstacle avoidance.

Patterns are implemented as independent ROS 2 nodes, each with its own namespace, facilitating distributed operation. Per-robot settings (sensor ranges, behavioral gains, etc.) are specified in YAML parameter files, and launch scripts can instantiate any set of primitives, remap standard topics, and bring up the hardware protection node per agent. Utility libraries for laser filtering, state machines, and data buffering support lightweight pattern design.

Features of ROS 2 leveraged include: decentralized DDS for communication; node composition and lifecycle management; parameters transferred across DDS; topic QoS tuning (adjustable reliability, history depth, etc.); and high modularity—enabling new behaviors via subclassing and minimal setup.

2. Behavioral Primitives and Underlying Mechanisms

ROS2swarm organizes its primitives into two core families:

• Movement Patterns (Motion Behaviors):
  • Attraction: Agents are drawn toward detected obstacles (including conspecifics) using attractive potential fields.
  • Dispersion: Agents are repelled by nearby obstacles via repulsive potential fields.
  • Random Walk: Finite-state controller switching forward motion and stochastic turns.
  • Flocking: Minimalist implementation of communication-free flocking, e.g., after Moeslinger et al. 2011.
  • Drive: Open-loop, constant-velocity forward motion.
• Voting Patterns (Decision Behaviors):
  • Majority Rule: Adopts the modal opinion within a tumbling time window.
  • Voter Model: Randomly samples a neighbor’s opinion and adopts it.

The mathematical core for motion primitives is based on scalar potential fields. For attraction (for $r_\mathrm{min} < d_{ij} < r_\mathrm{max}$):

$$f_\mathrm{att}(d_{ij}) = k_\mathrm{att}(d_{ij} - r_\mathrm{min})$$

For dispersion ($d_{ij} < d_\mathrm{safe}$):

$$f_\mathrm{rep}(d_{ij}) = \begin{cases} k_\mathrm{rep}\left(\tfrac{1}{d_{ij}} - \tfrac{1}{d_\mathrm{safe}}\right)\tfrac{1}{d_{ij}^2}, & d_{ij} < d_\mathrm{safe} \ 0, & d_{ij} \ge d_\mathrm{safe} \end{cases}$$

The robots sum all force contributions across sensor beams to generate their twist command.

Collective voting is formalized, e.g., by majority rule for agent $i$ at step $t$:

$$x_i(t+1) = \arg\max_{o\in O} |\{x_j(t) = o ~|~ j \in \mathcal{N}\}|$$

where $\mathcal{N}$ is the set of opinions received in the past $\Delta T$ window.

The impact of parameterization is explicitly noted: e.g., larger attraction range $r_\text{max}$ yields faster but less precise aggregation; smaller $d_\text{safe}$ increases collision risk, and shorter voting $\Delta T$ makes consensus fast but potentially unstable.

3. Hardware Abstraction, Platform Independence, and Integration

ROS2swarm was demonstrated across diverse robots:

Platform	Lidar/Range	Notes
TurtleBot3 Burger	360° LiDAR, 0.12–3.5m	Tight aggregation; demoed in sim/hw
TurtleBot3 Waffle Pi	360° LiDAR, 0.12–3.5m	Similar; added camera, tested in hw
Jackal UGV	OS1-16 LiDAR, 0.8–5m	Loose clusters in sim, ROS 1 bridge

Hardware abstraction is realized by requiring only that the platform publish sensor_msgs/LaserScan and accept geometry_msgs/Twist commands. All platform- and sensor-specific parameters (e.g., scan angles, collision radii) are YAML-configured. The HardwareProtectionLayer enforces safety by monitoring /scan and producing override velocity commands if imminent collision is detected.

Integration with ROS 1 is supported by a DDS–ROS1 bridge (ros1_bridge), enabling hybrid deployments where necessary.

4. Extensibility and Development Workflow

Extending ROS2swarm involves:

1. Subclassing MovementPattern or VotingPattern in Python.
2. Writing required callbacks (e.g., on_scan for motion, on_timer for voting).
3. Declaring and consuming ROS 2 parameters.
4. (If needed) Adding new message types to ros2swarm_msgs (C++) and regenerating interfaces.
5. Developing launch files that:
   • Namespace each robot
   • Remap scan and velocity topics appropriately
   • Specify correct YAML for the robot model
6. Validating the new pattern(s) in Gazebo simulation, then deploying to hardware.

For combined behaviors, subclassing CombinedPattern enables parallel or coordinated motion and voting logic—for instance, linking opinion state to dispersion radius.

5. Performance, Scalability, and Practical Deployment

Formal benchmarks are not provided in the source, but the following operational observations are reported:

• DDS-based topic exchange enables scaling to dozens of robots with sub-10 ms latency on local networks.
• On a Raspberry Pi 4, continuous potential-field computation for movement patterns occupies less than 15% CPU per node (single-threaded).
• Communication overhead per robot is minimal: a single laser scan and Twist message per control cycle, plus occasional opinion/vote messages for collective decision tasks.
• Users are encouraged to empirically benchmark throughput (e.g., ros2 topic hz /cmd_vel), monitor resource consumption (htop, ros2 node info), and perform DDS domain traffic analysis (ddsperf) as swarms grow large. QoS queue and history parameters should be tuned accordingly for swarms exceeding 50 agents.

6. Installation, Configuration, and Best Practices

To deploy ROS2swarm:

1. Install at least ROS 2 Dashing Diademata.
2. Clone ros2swarm_python and ros2swarm_msgs into the workspace.
3. Resolve dependencies and build with colcon.
4. Select the appropriate parameter file per robot model.
5. Validate deployment initially in Gazebo simulation, using unique namespaces per robot to prevent topic collisions.
6. Adjust hardware protection radii to slightly exceed actual safety radius.
7. Confirm inter-robot topic visibility (e.g., all see /opinions).
8. For large swarms: use an ad-hoc Wi-Fi configuration and consider ROS_DOMAIN_ID partitioning for traffic isolation.
9. Unit-test core behavioral logic before full integration, especially for novel patterns.

Common troubleshooting points include filtering out erroneous obstacles in laser data (e.g., walls attracting robots), ensuring sufficiently high QoS settings under network load, and monitoring Wi-Fi resource contention at higher robot counts.

---

In summary, ROS2swarm is a modular, extensible library of movement and decision primitives for swarm robots, emphasizing hardware abstraction and ease of behavioral extension under a fully decentralized ROS 2 communication framework. Its architecture, parameterization strategies, and integration with simulation and real robots represent a reference workflow for rapid prototyping of swarm algorithms and multi-agent behaviors on heterogeneous robots (Kaiser et al., 2024).