Swarmanoid simulation

ARGoS' official website

Computer simulation is a fundamental tool to aid the development and study of robotic systems. Existing simulation packages for multi-robot systems do not provide the flexibility, scalability, and computational efficiency necessary to deal with the challenges posed by the Swarmanoid project. Therefore, we have designed and implemented the ARGoS, a novel continuous-time simulator for general multi-robot simulation that includes full support for the simulation of the three different types of robots-- eye-bots, hand-bots and foot-bots--composing the swarmanoid.

The simulator has been designed to provide the following core properties and functionalities to the user:

  • Modeling of all the components of the swarmanoid and of the environment according to multiple, selectable, levels of physical detail.
  • Computational efficiency, to allow running simulations of complex indoor real-world scenarios including relatively large numbers of robots, and to ease the use of computationally-demanding algorithms for learning and control.
  • Effective monitoring and visualization of the activities and performance of the single robots and of the entire swarmanoid.
  • Transparent migration of robot control code from the simulator to the real robots.
  • High modularity, to facilitate reuse and integration of available software modules, permit independent code development from different contributors, and ease both the static and dynamic addition and removal of components and functionalities such as sensors, actuators, controllers, physics engines, and visualization modalities.


General characteristics

ARGoS is a discrete-time simulator for multi-robot systems acting in 3D spaces. The main code is entirely written in C++ and is all based on the use of free software libraries.

Each robot, and, more generally, each entity active in the 3D space, is a seen as composition of a physical structure, a set of sensors and actuators, and a controller module. The simulator includes an extensive set of sensors and actuators, and in particular all those necessary to allow the realistic simulation of the three types of robots composing the swarmanoid.

The simulator also includes multiple physics engines, that allow dealing with the simulation of the physics of movements and collisions according to different levels of realism and computational effort. During the same simulation run the physics of different groups of robots can be handled by different physics engines.

Figure 1 shows the general architectural characteristics of ARGoS concerning the simulation of a single robot.

Architecture

Figure 1

The Swarmanoid Space is the 3D arena where the robots and all the other simulated entities (e.g., objects such as bookshelves and tables, or active entities such as light emitters) live and act. It is implemented as a scene graph.

Sensor and actuators can be "specific", in the sense that they depend on the specific characteristics of the physics engine (see discussion below), or "generic", in the sense that they are independent of the physics engine and relates only to the general 3D coordinate system of the Swarmanoid Space.

The Common Interface is an abstraction layer that allows the robot controller to access the robot on-board devices irrespective of the fact that the controller is running on a simulated or a real robot. This means that the same controller code can be transparently compiled for running on a simulated and on a real platform.



Input description of the scenario and visual output

The simulation scenario describing all the characteristics of the environment, of the robots, and of the other entities, is given in input to the simulator in the form of an XML file using a quite self-explanatory syntax. A simple example scenario including two foot-bots and one physics engine is given in this XML scenario description file.

The Simulator design includes also multiple levels of textual tracing of the activities of the robots, as well as graphical visualization based on the use of popular open source three-dimensional graphical renderers such as 3D OpenGL and Ogre. Figure 2 shows an output frame using OpenGL of a simulation example where foot-bots and eye-bots are tracking "prey" entities (the text is added just to clarify the different roles). Figure 3 includes two output frames using Ogre showing respectively foot-bots (left) and hand-bots (right). Clinking on the images it shows they enlarged version.

OpenGL example

Figure 2


Ogre example with footbots Ogre example with handbots

Figure 3



Multiple physics engines and their concurrent use

The simulator includes the definition of multiple physics engines to handle the calculations of the physical kinematics and dynamics of the robots and the collisions happening among the physical entities in the simulation arena.

The presence of multiple physics engines gives to the user the possibility to model the different robots and their physical interaction according to the desired level of physical precision and, accordingly, of allocated computational resources. A simulation run can include the concurrent use of one or more physics engines, with each engine devoted to model with the desired level of detail the Newtonian physics for the objects falling within a specific subspace of the 3D Swarmanoid Space. Each subspace managed by each different physics engine can be a 1D, 2D, or 3D subspace (our 3D physics engines are based on the use of the ODE libraries, while the other engines are based on custom implementations). In practice, each engine independently lets the robots assigned to it acting in a local coordinate system specific to the engine subspace. A geometrical transformation maps the local coordinates into the reference ones of the common Swarmanoid Space. In this way, each robot, even if for instance is physically simulated as living in a 2D subspace, has anyway access to the full 3D representation of the arena to consistently communicate with and sense the other robots and entities.

These characteristics are unique features of ARGoS. From one hand, the presence of multiple physics engines, provides a to the user a range of selectable levels of physical precision. From the other hand, the fact that multiple physics engines can run concurrently taking care of different parts of the simulation allows to optimize the usage of computational resources, allocating more resource (i.e., precision) only where it is more necessary.

For instance, if the focus of an experiments is on eye-bots' behavior, and the foot-bots are supposed to be rather passive, then, physics calculations on the entire ground level and for all the foot-bots on it can be dealt with considering a simplified 2D representation. All the physical interactions on the ground can be managed by a simple physics engine based on a 2D geometry that considers only the simulation of the kinematics and not of the dynamics of the foot-bots.

Figure 4 shows a sort of extreme situation where the simulation in the 3D Swarmanoid Space is actually managed by three different physics engines working on different 2D orthogonal subspaces. In this case, in which precision is definitely sacrificed for sake of computational optimization, the foot-bots are approximated as 2D entities on the ground, the eye-bots are approximated as 2D entities moving on a horizontal plane located at a certain height from the ground, and the hand-bots are approximated as 2D entities acting on the wall.

Example of using three 2D physics engines

Figure 4



Sensors and actuators

The simulator provides a number of sensors and actuators that can be attached to a controller to produce a realistic of simulation of a foot-bot, eye-bot, or hand-bot, or to create any new virtual entity to be used during the simulation.

Each sensor or actuator is either "specific" for the characteristics of a physics engines (e.g., a camera sensor to be used inside a 2D physics engine implements a camera returning a mono-dimensional array of pixels, while a camera sensor for a 3D subspace returns a 2D pixel array), or "generic", if it is always related to the global 3D structure of the Swarmanoid Space.

In both cases, the controllers access sensors and actuators trough the Common Interface abstraction layer that makes transparent to the controller the fact that it is acting on a simulated or on a real robots. This important feature makes it possible to directly port on the real robots the controller code debugged and tested in simulation.

A list (incomplete) of the main sensors and actuators currently implemented and/or already scheduled for implementations is the following:

  • wheel actuator,
  • IR proximity sensor,
  • gripper actuator,
  • joint encoder,
  • force-torque sensor,
  • light sensor,
  • IR range and bearing sensor,
  • microphone and sound detector,
  • inclinometer,
  • omni-directional camera,
  • linear camera,
  • wi-fi transmitter and receiver,
  • laser beam actuator
  • rotor blades actuator
  • ...