Multi-robot systems promise to provide efficient solutions for an ever increasing variety of different applications, such as exploration of hostile environments, disaster recovery, construction, and nano-scale medicine.
Each of these applications is characterized by several aspects, such as environment dynamics (e.g. orbit, water flow, wind, rough terrain, bloodstream), robot types (e.g., mechatronics, sensors, actuators), and communication means (e.g., wifi, vision, stigmergy, etc.).
Physics-based simulation plays a fundamental role in the study of solutions for this wide set of applications.
We identified three main requirements for a successful simulator design:
Existing simulators do not provide the necessary features to support large-scale heterogeneous robot swarms.
The existing general-purpose simulators that emphasize flexibility give best results in single-robot or small-scale multi-robot applications, but their performance degrades fast with large numbers of robots.
Simulators that focus on effiency achieve remarkable performance by supporting a single, very simple robot types (e.g., circle-shaped wheeled robots), and limiting accuracy drastically (e.g., 2D-kinematics instead of 3D-dynamics models).
Regarding accuracy, most of the existing robot simulators are wrapped around a specific physics library. The accuracy of the results is thus tightly linked to the accuracy of the physics library employed.
We designed ARGoS with the intent of providing the research community with a tool that meets all of the above requirements.
We pursued a deeply modular approach. All the relevant aspects of a simulation can be overridden, for maximum flexibility. Modules are implemented as plug-ins loaded at run-time.
With respect to existing simulators, ARGoS allows the user to add functionality in the form of new sensors, actuators, robot components, visualizations, and even new physics engines and new communication means (media). For short-lived or experiment-specific extensions ARGoS offers a plug-in called loop functions, which is a set of hook functions executed during the main simulation loop.
Robot controllers use a robot-specific API called the control interface. The same API is implemented on the robot, allowing seamless transition of code from simulation to reality.
Traditional physics-based simulators are characterized by the physics engine they employ. It is common to say that a simulator is 2D or 3D, or that it performs dynamics or kinematic simulations.
In ARGoS, physics engines are just a plug-in. The user can choose which physics engine to employ for a simulation. In addition, the physical space can be divided in several regions, each controlled by a specific physics engine. In other words, ARGoS allows for multi-engine simulations. As robots navigate the environment, they get trasferred from engine to engine automatically.
Multi-robot systems are not only characterized by physics. Communication plays a fundamental role, too. For this reason, in ARGoS we introduced the concept of medium. A medium is a plug-in that implements suitable algorithms to simulate robot communication means (e.g., range-and-bearing, WiFi, stigmergy through RFID, etc.). A medium can be seen as a further type of engine ARGoS runs to perform detailed simulations.
Simulated objects are constructed as a composition of entities. Each entity serves a specific purpose, e.g., storing state, or acting as shared resource between modules.
The design choices in ARGoS allow for an efficient exploitation of multi-core processors.
The main simulation loop is distributed across multiple threads. Two types of threads exist: master and slave. The master thread assigns tasks to the slaves. A tasks consists in the update of a single plug-in (sensor, actuator, entity component, engine, etc.).
The user can set the number of threads as part of the experiment configuration. In addition, ARGoS offers two methods to distribute work across threads: scatter-gather, depicted above, and h-dispatch. The former provides best results when the tasks have similar computational cost; the latter when tasks are very diverse. The first case is typical of experiments involving large swarms of identical robots. Conversely, the latter case occurs when extremely different robots take part in an experiment.
An important aspect is that parallelism is embedded in the ARGoS core, but it is completely transparent for the plug-in developer. Thus, when creating a new plug-in, the developer does not need to cope with arbitration over shared resources.