IEEE Robotics & Automation Magazine - December 2013 - 67

fast data access. For each sensor/actuator type, multiple implementations are possible, corresponding to models that differ in
computational cost, accuracy, and realism. In addition, sensors
and actuators are tightly coupled with robot component entities. For instance, the foot-bot wheel actuator writes into the
wheel-equipped entity component of the foot-bot. Such coupling greatly enhances code reuse. New robots can be inserted
by combining existing entities, and the sensors/actuators
depending on them work without modification.
Visualizations read the simulated space to output a representation of it. Currently, ARGoS offers three types of visualization: 1) an interactive graphical user interface based on Qt
and OpenGL, 2) a high-quality offline 3-D renderer based on
POV-Ray, and 3) a textual renderer designed to interact with
data analysis and plotting software such as Matlab and
GNUPlot. Figure 7 shows some of the visualization possibilities of ARGoS.
One of the most distinctive features of ARGoS is that the
simulated space and the physics engine are separate concepts. The link between them is the embodied entity, which
is stored in the simulated space and updated by a physics
engine. In ARGoS, multiple physics engines can be used
simultaneously. In practice, this is obtained by assigning sets
of embodied entities to different physics engines. The assignment can be done in two complementary ways: 1) manually,
by binding directly an entity to an engine, or 2) automatically, by assigning a portion of space to the physics engine, so
that every entity entering that portion is updated by the corresponding engine. Physics engines are another type of module. Currently, three physics engines are available: 1) a 3-D
dynamics engine based on the open dynamics engine (ODE)
library, 2) a 2-D dynamics engine based on the Chipmunk
library, and 3) a custom-made 2-D kinematic engine.
To further enhance scalability, the architecture of ARGoS is
multithreaded. The simulation loop is designed in such a way
that race conditions are avoided and CPU usage is optimized.
The parallelization of the calculations of sensors/actuators and
of the physics engines provides high levels of scalability. The
results reported in [35] show that ARGoS can simulate 10,000
simple robots 40% faster than real time. ARGoS has been
released as open source software (http://iridia.ulb.ac.be/argos/)
and currently runs on Linux and Mac OS X.

The swarmanoid search-and-retrieval behavior that we
developed is shown in Figure 8. Eye-bots collectively explore
the environment and search for the target location (Eye-Bot
Swarm Search). They gradually build a wireless network that
spans the environment by sequentially connecting to the ceiling. Each new flying eye-bot that joins the search is guided to
the edge of the network by the eye-bots already in place.
Having reached the edge of the network, the searching eyebot continues flying, thus exploring new terrain. The eye-bot
will, however, stop flying and attach to the ceiling when at the
limit of its communication range with the rest of the network.
The network remains connected using the range and bearing
communication system [30].
To free up potentially scarce eye-bot resources, foot-bots
incrementally form a complementary wireless network on the
ground that follows the eye-bot network topology, but extends
only in the most promising search directions identified by the
eye-bots (Foot-Bot Chain). The eye-bot network and the footbot network can pass range and bearing messages between
each other, and thus together act as an integrated heterogeneous exploration and communication network. As the
slower foot-bot network catches up with the eye-bot network,
eye-bots are freed up for further exploration. Thus the

(a)

Swarmanoid in Action
Search and Retrieval: Behavioral Control
To demonstrate the potential of the swarmanoid concept, we
developed an integrated search and retrieval behavior. The
search-and-retrieval behavior is designed to allow the
swarmanoid to retrieve objects in a complex 3-D environment. Objects are placed on one or more shelves in a human
habitable space (such as an office building). The swarmanoid
robots are assumed to start from a single deployment area.
The swarmanoid must first find the shelves containing relevant objects and then transport the objects from the shelves
back to the deployment area.

(b)
Figure 7. Screen-shots from different visualizations: (a) Qt-OpenGL
and (b) POV-Ray.

DECEMBER 2013

IEEE ROBOTICS & AUTOMATION MAGAZINE

http://iridia.ulb.ac.be/argos/

Table of Contents for the Digital Edition of IEEE Robotics & Automation Magazine - December 2013