We wrote a state-of-the-art paper on co-simulation for multi-robot systems, but it is in french. It can be found in the HAL website : Etat de l’art sur la co-simulation robotique et réseau des systèmes multi-robots. This section tries to summarize this work.

Why do we need co-simulation ?

Multi-robot systems span across two well-known research domains : robotics and networks. Fleets of collaborative aerial robots show a good example of this intertwining : on one hand UAVs have movement constraints (steering radius, acceleration, etc.), on the other hand, information exchange between UAVs of the same fleet can be vital (collision avoidance, formation flights, etc.).

Both the robotics and the network research communities have strong knowledge in simulation. It allows for quick, reproducible, safe, in-expensive experimentation, allowing the researchers to test many different configurations and permitting the use of AI to perform training on large datasets.

In robotics, the simulators focus on the physics and control aspects of robots : collisions, frictions are modeled with high fidelity, but also sensors and actuators, including uncertainties and noise.

In networks, a huge work has been done to recreate the protocols as close as possible as what is actually executed by our network cards. Radio wave propagation is also a strong focus point, which is a research area per se and unveil challenges due to its requirements in computational resources.

Realizing the insane amount of work that has been done by each community to provide realistic simulators, researchers working with multi-robots systems quickly turned toward co-simulation - the art of making two or more simulators working together to fill the gaps of one another.

However, when one wants to practically implement a co-simulator, typical problems arise.

Co-simulation challenges

Synchronization

Synchronization is one of the main problems when implementing a co-simulator. In particular, we distinguish two different ways of handling time for simulators : discrete-time and discrete-events.

Robotics simulators usually use differential equations to model the movements of objects in space. To compute the results, it is required to discretize these equations according to a certain time-step. The time between two steps can change during simulation but is usually constant. For robots with normal size and speed, it is standard to choose time-steps on the order of milliseconds (1ms, 4ms, 10ms are reasonable time-steps).

Network simulators have a different representation of time. Networks event are not equally distributed in time : large periods of inactivity in the network can be followed by a fast burst of events, triggered by the reception of a message, for example. This property encouraged the developers of network simulators to implement discrete-event simulators (such as ns-3). Each event in the simulation is marked with a timestamp, and all the events are placed in a file in chronological order. The scheduler then executes the events one after the other, without looking at the time between two events. In this configuration, the "clock" of the simulator advances irregularly : it jumps from one event to the other.

Discrete time (for robotics simulation) :

/images/discrete-time.drawio.png

Discrete-event (for network simulation) :

/images/discrete-event.drawio.png

Information sharing

The second challenge has to do with information sharing. The questions are : what information should be shared between the simulator ? and what technology to use for this information sharing ?

The first question is relative to the level of details wanted for the simulation. It is a tradeoff between computation time and level of details : more information exchange means more computation overhead. Usually in robotic-network co-simulation, the minimum information to share between the two simulators are robots positions and synchronization information.

The second question is about the nature of the pipe in which the information flows. In co-simulation, this pipe is administrated by the coordinator, handling messages in one way or the other. Typical technologies used for information sharing between two simulators are :

• Unix Domain Sockets (UDS)
• TCP/IP Sockets
• Shared Memory
• Message queue

When building a co-simulator, one has to carefully compare the pros and cons of each technology to choose the best for its specific application. In DANCER, both UDS and TCP/IP sockets can be used (default is UDS).

Existing co-simulators

Robotic and network co-simulators started to be investigated in 2013 with RoboNetSim which interfaces ARGoS with ns-2. In the recent years, many projects tackled the task of creating a realistic multi-robot simulator, summed-up in the following table :

/images/comparaison_co-sim_nom1024_1.jpg

Interestingly, most of these initiatives took place in a context of multi-aerial vehicle research, where network connectivity is critical for the safety of the robots. In terrestrial robot networks, short disconnections can happen without being critical for the robot's movements.

Another point of interest is the preeminence of Gazebo for robotic simulation and NS-3 for network simulation for co-simulators born after 2018. These two tools established themselves as the best option for quick development, mainly because of they are open-source and benefit from a large and active community.

Finally, our investigation showed that none of these co-simulators were usable as it is. Most of these tools are not maintained, use obsolete technologies or don't answer the level of details we were aiming for. Thus, we decided to build our own co-simulator.