DANCERS (Distributed, Autonomous, Networked and CooperativE Robots Simulator)

Welcome to the DANCERS' wiki ! DANCERS is a tool for realistic simulation of communicating multi-robot systems. DANCERS leverages the co-simulation paradigm to model both the robotics aspect and the networking aspect of multi-robot systems, enabling them to be studied jointly. The DANCERS architecture can interconnect any physics simulator with any network simulator, but in particular we provide the connectors for three physics simulators (Gazebo,Mini-Dancers (Based on CTU's multi-rotor dynamics models) and Robotsim) and one network simulator ns-3.

DANCERS is distributed either as a Docker container here or can be compiled from source. We recommend using ROS2 colcon build tool to do so.

To overcome the challenges of co-simulation, we took inspiration on the ROS-NetSim infrastructure presented in this paper and whose original code is available on this GitHub repository. ROS-NetSim was a good starting point but the architecture and overall functioning of DANCERS now largely differs from ROS-NetSim.

Overview

DANCERS provide the functionalities to make two simulators work together. The Coordinator can handle any type of physics or network simulator, but a connector has to be written to connect a simulator with DANCERS. We provide the connectors for three physics and one network simulator, quickly described hereafter:

• Gazebo is - at the time of writing - the most widely used robotic simulator. It complies with any type of robots, scales to multi-robot and provide a reasonably well developed API allowing easy integration with other bits of software. Its strength is its very active and helpful community, and a large library of already functional robots, sensors, actuators and worlds.

• Robotsim is a "hand-made" multi-agent simulator originally developed to study flocking algorithms. It a C-written monolithic application providing a visual interface and quadrotors dynamics. It is fast, can handle large groups of agents and can be used for learning approaches.

• Mini-dancers is our own multi-UAV simulator based on a multi-rotor dynamic model developed by the multi-robot systems group at CTU, Prague. Is also leverages ROS2 and Rivz2, a visualization software, to provide visualization. It is faster than a full-blown Gazebo + PX4 simulation but does not enable collisions. We believe it is easier to use than Robotsim.

• ns-3 is the most used network simulator in the world of academic research. It provides realistic simulation of the network stack, including protocols, radio wave propagation models and applications.

Example of GUI for Gazebo (left), Robotsim (center) and mini-dancers (rights):

DANCERS is built around a central module called the Coordinator. It is really the co-simulator's heart. As an orchestra director, it controls the execution of the two simulators, ensuring time-synchronization and providing information exchange capabilities.

DANCERS has many advantages :

• Any type of robots
• Works for heterogeneous fleets
• Any type of communicating technologies (supported in ns-3), including Wi-Fi, cellular, Ultra-Wide Band, LPWAN, etc.
• Support for Software-in-the-Loop (SITL) for the PX4 Autopilot
• Handle real network packets
• Integrates in the ROS2 infrastructure
• Allows user-defined obstacles

DANCERS is Open-Source, Copyleft licensing, under the GPLv3 license.

Architecture

The Coordinator, in the middle, manages a bidirectional communication bridge between the two connectors and ensures synchronicity with a scheme that we call "decoupled time-stepped with scheduler", explained after.

The connectors, on each side, manage the standalone simulators, handling input and output conversion when necessary, and the exchange of message with the Coordinator. One connector by simulator has to be developed, as it depends on the API of this specific simulator.

Synchronization

One of the great challenges of co-simulation is to keep the two simulators in sync. For more information on this challenge, see Co-simulation.

To overcome this difficulty, we introduce decoupled time-stepped synchronization mechanism. It functions as follow :

1. A common iteration duration is decided (e.g. 10 milliseconds), independent step duration are decided for each simulator (e.g. 1ms for network simulator, 5ms for robotic simulator)
2. Using two threads, the Coordinator sends a BEGIN message to the two simulators, triggering the execution of a "step" (basically, "simulate the next step duration milliseconds")
3. Once a simulator has finished the necessary computations for step_size seconds, it answers the Coordinator with an END message. (basically, "I'm ready for next step").
4. When it receives an END message, the coordinator do two things:

• If it comes from the simulator with the smallest step duration: Update the global simulation clock clock = clock + step_duration
• If the simulator did not finish its number of step per iteration, send a new BEGIN message. Otherwise, set this simulator to "ready".

6. When both simulators are "ready", a new cycle begin (go back to step 2)

The following visual show an example of this mechanism for one simulation iteration. Here, iteration_size = phy_step_size = 5*net_step_size and the network simulators is slower to compute one simulation interaction, so the physics simulator holds until the network simulator is finished.

Information exchange

The second challenge of co-simulation is passing information between simulators. Ultimately, information passing will always have an impact on the overall simulation performance. Any inter-process communication (IPC) methods can be used, with their respective pros and cons. In DANCERS, we use sockets. Two types of sockets are implemented:

• Unix Domain Sockets (UDS)
• TCP sockets

In the case of local computing (all the modules executing on the same computer), UDS should be used as they provide a better simulation speed, but TCP sockets are provided for distributed computing (e.g. running the Gazebo simulation on a remote server).

We use Google's Protobuf messages, which makes it easy to configure new messages.

The information exchange happen between the iterations, and generates a computation time. For this reason, the user of DANCERS should try to always minimize the size of the information exchanged between the two simulators.

Documentation methodology

This wiki aims at providing documentation for the DANCER co-simulator for any level of understanding. In order to be as useful as possible, we will try to follow the documentation system framework presented by Divio, and hence break down the documentation in four categories: tutorials, how-to guides, reference and explanation.

• Tutorials
• How-to Guides
• Reference
• Explanation

Credits and founding

This work has been mainly done by Théotime Balaguer, in the context of its Ph.D. thesis, started in 2023. It has been founded (half/half) by the "Institut National des Sciences Appliquées de Lyon" and the "Agence d'Innovation de Défense". DANCER is also more broadly a part of the CONCERTO (ANR-20-ASTR-0003) project founded by the "Agence Nationale de la Recherche" and the "Agence d'Innovation de Défense".