TOOLS FOR DYNAMICS SIMULATION OF ROBOTS - EXTENDED REPORT 1

Tools for dynamics simulation of robots: a survey

based on user feedback
Serena Ivaldi†,‡ , Vincent Padois†,‡ and Francesco Nori§

Abstract—The number of tools for dynamics simulation has software tools, for the reader’s interest. In the appendix, we
grown in the last years. It is necessary for the robotics community also report free comments about the subjective user experience
to have elements to ponder which of the available tools is the (major problems and desiderata).
best for their research. As a complement to an objective and
quantitative comparison, difficult to obtain since not all the tools
arXiv:1402.7050v1 [cs.RO] 27 Feb 2014

are open-source, an element of evaluation is user feedback. With A. Why user feedback?
this goal in mind, we created an online survey about the use of
dynamical simulation in robotics. This paper reports the analysis Most middleware for robotics (ROS, YARP, OROCOS,
of the participants’ answers and a descriptive information fiche Player, etc.) are already open-source, some also cross-
for the most relevant tools. We believe this report will be platforms. This makes it possible to produce interesting per-
helpful for roboticists to choose the best simulation tool for their formance comparisons that can help the roboticists to pick the
researches. best middleware for their needs [1]. Similar ideas (open-source
and cross-platform compatibility) should be used to compare
I. I NTRODUCTION dynamics models and simulators. For example, an interesting
evaluation and performance comparison of contact modeling
With the progress of powerful computers enabling fast
algorithms was presented in [2], [3].
computations, dynamics simulation in robotics is no longer
As a complement to quantitative comparisons, a useful
expected to be an offline computational tool. It is used to
element of evaluation (often un-mentioned and neglected) is
rapidly prototype controllers, evaluate robots design, simulate
user feedback. What do users really think of the software
virtual sensors, provide reduced model for model predictive
they use for simulation? Would they suggest it? What is
controllers, supply with an architecture for real robot control,
their experience in their particular use case? We believe user
and so on.
feedback may be useful to avoid time-consuming tuning and
There is a growing number of tools for dynamics simulation,
inappropriate choices of software to researchers. It could point
ranging from dynamic solver libraries to systems simulation
a researcher to a community that is actively using the tool
software, provided through either open or closed source code
and that is sharing the same concern: for example, it is likely
solutions, each more or less tailored to their expected domains
that people simulating flying robots have different needs than
of application.
those simulating wheeled robots or those controlling bipeds.
The spectrum of robotics applications being large and in
Furthermore, user feedback can provide useful suggestions to
expansion, it is necessary for the developer community to have
the developers community about the things that matter the
a feedback about the users’ needs, and for the researchers to be
most to users in simulation.
aware of the available tools and have the elements to ponder
which of the available tools is the best for their research.
With this goal in mind, we created an online survey about B. Challenges in simulation
the use of dynamical simulation in robotics.1 The survey was Dynamics simulators for robotics have more strict require-
divided into four parts: general information about the user, ments than the ones used for animating virtual characters,
user experience with dynamics simulation in general, user where time, computational burden and physical reality can be
experience with one tool of his choice, technical questions less constraining. In entertainment (e.g. video-games), unfea-
and subjective evaluation about the selected tool. The survey sible forces may not be a problem since the law of physics can
was advertised on the main robotics mailing lists (e.g., euron- be violated. In bio/mechanical studies, simulators can be used
dist, robotics-worldwide) as well as in other mailing lists of offline to analyze or synthesize behaviors. Although the field
correlated disciplines (e.g. comp-neuro), and kept open for of dynamics modeling and simulation has matured over the
approximately one month. last decades [4], [5], [6], the growing need to control whole-
This paper summarizes the analysis of the users’ answers. body movements of complex structures, such as humanoids,
We also report a descriptive fiche for the most relevant poses additional challenges to simulators for robotics:
1) numerical stability, which poses strong limitations on the
E-mail: [email protected]
† Sorbonne Universités, UPMC Paris 06, UMR 7222, Institut des Systèmes use of simulations in real-time control settings [2], [3];
Intelligents et de Robotique (ISIR), F-75005, Paris, France. 2) the capability to be used as predictive engines in real-time
‡ CNRS, UMR 7222, Institut des Systèmes Intelligents et de Robotique
control loops [7], which requires the ability to be extremely
(ISIR), F-75005, Paris, France.
§ Robotics, Brain and Cognitive Sciences Dept., Italian Institute of Tech- fast in computing the dynamics and the guarantee for the
nology. solvers to converge to physically feasible solutions upon a
1 Online survey: http://goo.gl/Tmyf5A certain time [8];
TOOLS FOR DYNAMICS SIMULATION OF ROBOTS - EXTENDED REPORT 2

3) the simulation of rigid and soft bodies in contact with but are not meant to provide seamless control of robotics
rigid and compliant environments [9], [10]: the inaccurate platforms.
computation of contact forces between bodies may result in Another element of discrimination is the way the simulator
unrealistic contacts or physically unfeasible contact forces represents rigid-body structures: on one hand we have software
(this issue has been particularly evident in the virtual phase of based on ODE and Bullet, such as Gazebo, iCubSim, MORSE,
the Darpa Robotics Challenge - DRC); which represents joints as constraints between bodies; on the
4) the capability to model and simulate new types of actua- other we have softwares like XDE, OpenHRP, which make
tion systems, such as variable impedance or soft actuators [11], use of parameterized rigid-body dynamics representations,
and different types of contacts, for example with deformable where joints are simply part of the robotics structure. These
materials, compliant and soft surfaces [12]. two classes determine not only the way forward/inverse dy-
Finally, the robotics community urges for standardized namics are computed (and of course the second group also
software tools and particularly open source software. The benefits from the straightforward computation of quantities
benefit of open-source is not only in the community that can useful in robotics, such as Jacobians, mass matrices etc.),
grow around the software, developing new tools, improving its but most importantly the way contact forces are computed.
quality and avoiding to “re-invent the wheel” at each time, but The first class considers contacts forces as bilateral/unilateral
also in checking its efficiency and robustness on real platforms constraints, which are added to the list of constraints used to
(which is expensive). describe the joints; then the same solver is used to find the
forces for the global system, including contacts and joints. In
the second class, on the contrary, only constraints from the
C. The iCub case contacts are solved, which notably simplifies the problem. In
The iCub community recently faced the problem of choos- generla, finding the correct contact forces can be burdensome.
ing the correct tool for whole-body dynamics simulation. The Current approaches to solve this problem are mostly based
existing simulator iCubSim [13], is based on ODE and is on the Linear Complementarity Problem (LCP) [3], and in
mostly used as a tool for testing behaviors before trying some cases there are mixed approaches combining LCP with
them on the real robot. It is provided with an interface that optimization techniques, such as in MuJoCo [7].
emulates the low-level control of iCub, so the same code In short, there are several “objective” criteria that one can
can be used to control simulated and real robot. However, look at, on the basis essentially of what is advertised by
the dynamics engine makes it inadequate for research about the developers as a “supported feature”. However, it is very
control of contacts and compliant surfaces. At the moment two difficult to find practical comparison of different simulators
solutions are investigated: one based on XDE and the other on test problems, for many reasons: first, an extensive com-
based on Gazebo. The choice of these tools has been based on parison would require access to the source code but not all
objective criteria (license, developing community, stability of software is released under open-source; second, even open-
the software simulation), previous experience and “subjective source softwares can be difficult to compare, because their
feedback” acquired orally discussing with colleagues, that pro- requirements in terms of architecture, dependencies etc. are
vided partial and unstructured information. A more structured different; finally, not all softwares are well-documented and
information about user feedback would have been helpful. We easy to test in the same way, so non-experienced users may
believe this survey analysis could be a further element for not know all the tweaks to boost simulations. We compensate
choosing the best simulation tool in a research project. the lack of objective experimental comparison with the user
feedback provided by this survey.
D. Comparing simulators
II. S URVEY OVERVIEW
It is certainly difficult to enumerate all the criteria that one
The analysis of the survey is reported hereinafter.
can examine to choose a dynamics simulator, especially for a
humanoid robot that is supposed to have physical interactions
with rigid and compliant environments. A. About the participants
First, one can choose between physics engines (e.g. ODE, The survey was filled by 119 participants (92% male, 8%
Bullet) and more complex softwares that include system female; age 32 ± 6, min 20, max 57), whose 62% holds a
simulation (e.g. Gazebo, V-Rep). PhD degree and 35% a BS or MS degree, mostly from USA,
Second, facing the decision to adopt a simulator for a robot, France, Italy and Germany (see Figure 2). Participants work
a researcher should first decide between softwares that also mostly in University (70%) or do R&D in public (16%) or
include system simulation, and softwares which only simulate private (14%) institutes.
the dynamics of multi-body systems. This criterion allows us Their primary areas of research are:
to consider under different perspectives two set of softwares: 21% control, 14% locomotion, 10% machine learning, 9%
the first set, composed of software like Gazebo, OpenHRP, HRI, 8% planning, 6% mechanical design, 5% cognitive
iCubSIM, which facilitate seamless simulation and control robotics, 5% mathematical modeling.
of the virtual characters and their corresponding physical Their primary application field is:
system/robot; the second, like Humans, OpenSIM, Robotran, 26% humanoid robotics, 20% mobile robotics, 11% multi-
that are able to simulate the dynamics of complex systems legged robotics, 8% service robotics, 7% industrial robotics,
TOOLS FOR DYNAMICS SIMULATION OF ROBOTS - EXTENDED REPORT 3

(a) iCubSim, based on ODE. (b) iCub in XDE. (c) iCub simulated in Gazebo.
Fig. 1: Simulators of iCub. From left to right: iCubSim, based on ODE, XDE and Gazebo. (credits for Gazebo: Silvio Traversaro)

The software tools that are less known (because maybe

they were not sufficiently advertised or do not have a big
community behind) and the ones that are most known (even
if this does not necessarily means that they are used) can be
retrieved from the column “Never heard of this software” from
Table I3 . The most known tools are ODE (10%), Gazebo
(15%), Blender (15%), Bullet (24%), Webots (27%), Nvidia
PhysX (32%), Stage (38%), V-Rep (39%), OpenSIM (40%)
and ADAMS (45%). Interestingly, the first three are also open-
source projects.
An important information that we acquired through the sur-
vey is about the abandon of software for simulation: this can
be found in the column “Used than abandoned” in Table I. The
Fig. 2: Country of provenience for the participants to the
most abandoned software after use are ODE (22%), Stage
survey.
(16%), Webots (13%), Bullet (10%), Gazebo (10%), Nvidia
PhysX (7%), OpenHRP (6%), Blender (6%), OpenRave (5%),
Vortex (5%). Though this set may seem as a sort of “blacklist”
7% numerical simulation of physical systems, 5% flying
of tools that disappointed users, it must be observed that most
robots.
of them are open-source softwares that could have been the
Among the participants working in humanoid robotics, 16%
“one among many” tools that have been used then in one
is also competing in the Darpa Robotics Challenge (DRC),
researcher’s life; however, it can be equally presumed that the
which makes 8% of the participants to the survey - 10 people.2
high percentage of abandon can be partly correlated to the
difficulty that users have encountered in using these tools and
B. General knowledge about simulating tools partly by their “seniority”.

We asked participants to indicate their familiarity with some

of the most common existing simulation tools. We provided a C. Important features for simulation
list of existing software tools for simulations, used in different We asked participants to indicate the main purposes for
contexts. We asked the users to indicate whether the software the use of dynamics simulation in their research (they could
was currently used or not for their researches, if it had indicate more than one):
been used before or if it was unknown. A summary of the 66% simulating the interaction of the robot with the environ-
percentage of answers for the most relevant tools is shown in ment, 60% simulating the robot locomotion, 59% simulating
Table I. behaviors of the robot before doing them on the real robot,
The software tools that have more than 5% of user share 49% simulating the robot navigation in the environment,
(i.e., positive answers to the fact that the software is currently 48% simulating collisions and interactions between bodies
used and it is the one or one of many main tools): the most (not specifically robots), 41% testing low-level controllers for
used are Gazebo (15%) and ODE (11%), with a gap with robots, 22% simulating multi-fingered grasp, 21% simulating
respect to Bullet, OpenRave, V-Rep, XDE and Blender, all at human movements, 8% animating virtual characters.
5%. These values provide an indicative dimension of the user We also asked participants to evaluate, upon their experi-
community around each software tool. ence, what are the most important features for a good sim-
ulation (they could evaluate the importance of each element
2 Interestingly, the software tool they indicated as the one currently used for
their research (we can presume for the DRC as well) is Gazebo (3), MuJoCo 3 Actually, Table I is only showing values for the most relevant software
(2), Robotran (2), Drake (1), Autolev (1) and ODE (1). tools. To see the full data, we refer the reader to the full report of the survey.
TOOLS FOR DYNAMICS SIMULATION OF ROBOTS - EXTENDED REPORT 4

Tool Currently Currently Currently Used Used Known, Never

used, used, used, once, then but heard of
and its but not just to just to aban- never
the main the main test it test it doned used
tool tool
Gazebo 13% 7% 3% 18% 10% 34% 15%
ODE 11% 12% 5% 18% 22% 22% 10%
Bullet 5% 13% 7% 12% 10% 29% 24%
V-Rep 5% 3% 3% 18% 3% 29% 39%
Webots 4% 7% 1% 16% 13% 32% 27%
OpenRave 5% 3% 2% 7% 5% 29% 49%
Robotran 4% 0% 1% 4% 2% 13% 76%
XDE 5% 3% 0% 3% 1% 14% 74%
Blender 5% 17% 7% 22% 6% 28% 15%
MuJoCo 2% 0% 0% 4% 2% 21% 71%
iCub SIM 4% 4% 2% 3% 3% 29% 55%
Nvidia 1% 1% 4% 12% 7% 43% 32%
PhysX
OpenSIM 3% 4% 3% 8% 1% 41% 40%
HumanS 0% 0% 0% 1% 1% 10% 88%
Moby 2% 1% 0% 0% 2% 14% 81%
Vortex 3% 2% 0% 5% 5% 17% 68%
RoboRobo 3% 1% 0% 0% 1% 4% 91%

TABLE I: Knowledge and past/present use of simulators.

Rank Most important criteria

from “not important at all” - 1 to “very important, crucial” - 5). 1 Simulation very close to reality
Their ranking of important features is reported in Table II. The 2 Open-source
stability of simulation is the only element that was evaluated 3 Same code for both real and simulated robot
4 Light and fast
as “very important”, whereas speed, precision and accuracy 5 Customization
of contact resolution were marked important. Remarkably, the 6 No interpenetration between bodies
same API between real and simulated robot is also signed as
important. TABLE III: Most important criteria for choosing a simulator.

D. Criteria for choosing a simulator

6% Webots, 5% OpenRave, 4% Robotran, 4% XDE. All the
We asked participants to indicate the most important criteria other tools (see Figure 4) have less than 4% of user share.
for choosing a simulator. The answer was broken in three parts, These tools are the ones we are focusing on in our following
i.e. participants could point out the first, second, and third analysis. Some technical information about the selected tools
most important criteria. The first most important criteria: 32% can be indicative of the user needs and use:
simulation very close to reality, 24% open-source, 19% same • Primary OS: 66% GNU/Linux, 30% Windows, 4% MAC
code for real and simulated robot, 11% light and fast, 6% OSX.
customization, 3% no inter-penetration between bodies, 5% • Primary API language: 52% C++, 18% python, 13%
other. The second and third choice for the important criteria Matlab, 8%C, 3% LUA, 2% Java; 3% of participants do
follow more or less accordingly. Considering the three criteria not use an API
as a whole, i.e. grouping the three of them on the same level, • License: 67% of the tools are open-source (GPL, Apache,
the important criteria is 23% simulation very close to reality, BSD and analogous/derivatives licenses), only 17% of the
20% open-source, 18% light and fast, 16% same code for tools have a commercial license, 16% have an academic
real and simulated robot, 14% customization, 4% no-inter- license (i.e., they are free but not open-source).
penetration between bodies, 1% ease to learn/use, 1% real time • Hardware: 39% a powerful desktop (i.e., multi-core,
- based simulation, 2% other. If instead we consider the weight 8/16GB RAM), 35% everyday laptop, 18% powerful
of each selection (most important=3, second important=2, third desktop with powerful GPU card, 5% multi-core cluster.
most important=1), then grouping the answers we have: 26% • Middleware: 52% is not using the tool with a middle-
simulation very close to reality, 22% open-source, 17% same ware, the remainder is using ROS (25%), YARP (6%),
code for both real and simulated robot, 17% light and fast, OROCOS (4%).
11% customization, 4% no inter-penetration between bodies
The research areas being different, we extracted the most
(5% other)
used tools for a selection of research areas: results are shown in
Table IV. The most relevant results are for humanoid robotics
E. Currently used tools (31 users, that is 26% of the participants to the survey) and
We asked participants to indicate the current simulation tool mobile robotics (25 users, that is 21% if the participants).
they are using. Results are shown in Figure 3. For humanoid robotics, the most diffused tools are ODE
The most diffused software among the participants are: and Gazebo, and there is a variety of several custom-made
13% Gazebo, 9% ARGoS, 8% ODE, 7% Bullet, 6% V-Rep, simulators. It is interesting to notice that Gazebo supports
TOOLS FOR DYNAMICS SIMULATION OF ROBOTS - EXTENDED REPORT 5

Rank Feature Overall Evaluation Rating Median rating

1 Stability of simulation Very important 4.50 ± 0.58 5
2 Speed Important 4.05 ± 0.75 4
3 Precision of simulation Important 4.02 ± 0.71 4
4 Accuracy of contact resolution Important 3.91 ± 0.92 4
5 Same interface between real & simulated system Important 3.67 ± 1.26 4
6 Computational load (CPU) Neutral 3.53 ± 0.85 3
7 Computational load (memory) Neutral 3.22 ± 0.90 3
8 Visual rendering Neutral 3.02 ± 1.02 3

TABLE II: Most important features for a simulator.

Fig. 3: The simulation tools currently in use among the participants to the survey. The vertical axis reports the number of users
that indicated the tool as their principal.

ODE and Bullet as physical engines, hence it is probable that project leader (40%).
the quota of ODE for humanoid robotics is higher. For mobile We asked participants to evaluate their level of satisfaction
robotics, the most diffused tools among the survey participants of the use of their tool, in a global way, from Very negative (1)
are Gazebo, ARGoS and Webots. to Very Positive (5): all software tools were evaluated “pos-
itive”, whereas only MuJoCo was “very positive” (subjective
The different concentration of tools for the different re- evaluation by 3 users). We also asked participants to indicate
search areas reveals that some tools are more appropriate than their level of satisfaction with respect to some specific aspects
others for simulating robotic systems in different contexts (documentation, support, installation, tutorials, advanced use,
or applications. A researcher may therefore let his choice active project and community, API), and to rate each element
about the adoption of a simulator be guided by the custom on a scale from 1 to 5. Table V reports the mean and standard
in his field. With this in mind, we investigated what was deviation of the notes received by the users of each tool.
the main reason for a researcher to pick up his current tool.
Overall, the main reasons why they chose the current tool
is: 29% the best tool for their research upon evaluation, 23% F. Tools for robots
“inheritance”, i.e. it was “the software” (already) used in their
laboratory, 8% they are the developers, 8% it was chosen The majority of participants to the survey is using the
by their boss/project leader, 7% it is open-source, 7% it was software tool to simulate robots (91%). Users could point out
happily used by colleagues. Only 3% of the participants chose the robots they are simulating (more than one in general):
the tool because of a robotic challenge. Interestingly there is the aggregated table of simulated robot is shown in Figure 4,
quite a demarcation between the first reasons and the others. where the x-axis shows how many users selected the robot.
There are certainly some tools that distinguish for the fact that We extracted the principal tools used for simulating the main
they have been chosen as best option for research, for example robots:
V-Rep (71%), Bullet (63%) and Gazebo (53%). Some tools • iCub: 25% Arboris-Python, 17% ODE, 17% Robotran,
have instead been adopted by “inheritance”, i.e., they were 17% iCub SIM
already used in the lab: ARGoS (45%), Robotran (40%) and • Atlas: 50% Gazebo, 25% MuJoCo, 12% Autolev, 12%
XDE (40%). For the latter, it is also a choice imposed by the Drake
TOOLS FOR DYNAMICS SIMULATION OF ROBOTS - EXTENDED REPORT 6

Research area Users Most used software Other used software

Humanoid Robotics 32 (4) ODE, (3) Gazebo, Robotran, (1) Drake, MapleSim, MuJoCo, OpenSIM, Robotic-
OpenRave, Arboris-Python, (2) XDE, sLab, SL, Vortex, V-Rep, Webots, own code
iCub SIM
Mobile Robotics 25 (5) Gazebo, ARGoS, (3) Webots, (2) V- (1) ADAMS, Autodesk Inventor, Bullet, ODE,
Rep, Vortex Morse, roborobo, Sim, own code
Multi-legged robotics 13 (3) Webots, (2) ODE (1) Gazebo, ADAMS, Autolev, Bullet, Moby,
RoboticsLab, SIMPACK, VoxCad
Service robotics 12 (4) Gazebo, (3) OpenRave (1) OpenSIM, V-Rep, Morse, RCIS, SL
Numerical simulation of physical systems 8 (2) Bullet (1) MuJoCo, ODE, OpenSIM, Simulink, trep, XDE
Flying robots 6 (2) ARGoS (1) Robotran, crrcsim, Gazebo, Simulink/Matlab
Swarm robotics 5 (4) ARGoS (1) roborobo
Industrial manipulators 5 (1) Bullets, Dymola, Matlab, V-Rep, XDE
Mechanical design 4 (1) Moby, MuJoCo, V-Rep, own code
Human Motion analysis 3 (1) Robotran, Bullet, XDE
Snake robots 3 (2) ODE (1) Matlab

TABLE IV: Most diffused tools for a selection of the research areas.

Tool Documentation Support Installation Tutorials Advanced use Active project API Global
& community
Gazebo 3.47 ± 0.99 4.00 ± 1.07 3.93 ± 1.03 3.53 ± 1.12 3.80 ± 0.86 4.73 ± 0.45 3.67 ± 0.82 3.88 ± 0.91
ARGoS 3.40 ± 0.70 3.90 ± 0.99 4.70 ± 0.48 4.20 ± 0.63 4.60 ± 0.70 4.10 ± 0.74 4.30 ± 0.67 4.17 ± 0.70
ODE 3.80 ± 0.63 3.40 ± 1.07 4.10 ± 1.28 3.20 ± 1.13 3.90 ± 1.37 3.30 ± 1.25 3.40 ± 1.26 3.59 ± 1.15
Bullets 3.37 ± 1.06 3.62 ± 0.91 4.75 ± 0.46 4.00 ± 0.76 3.75 ± 0.71 4.37 ± 0.74 3.87 ± 0.83 3.96 ± 0.78
V-Rep 4.28 ± 0.76 4.43 ± 0.79 4.71 ± 0.76 4.14 ± 0.90 4.28 ± 0.76 4.43 ± 0.53 4.14 ± 1.07 4.25 ± 0.80
Webots 3.86 ± 1.07 3.57 ± 1.13 4.43 ± 0.79 3.43 ± 1.51 4.42 ± 0.78 4.14 ± 0.69 4.57 ± 0.53 4.20 ± 0.96
OpenRave 3.50 ± 0.55 4.67 ± 0.52 4.17 ± 0.75 3.50 ± 1.22 4.33 ± 0.82 4.33 ± 0.52 4.33 ± 0.52 4.12 ± 0.70
Robotran 3.60 ± 0.55 3.80 ± 0.45 3.80 ± 0.45 3.20 ± 0.84 4.20 ± 0.84 3.20 ± 0.84 3.80 ± 0.45 3.66 ± 0.63
Vortex 3.33 ± 1.15 3.67 ± 1.53 5.00 ± 0.00 2.67 ± 0.58 3.67 ± 0.58 2.67 ± 1.15 3.33 ± 0.58 3.48 ± 0.80
OpenSIM 4.33 ± 0.58 4.67 ± 0.58 3.67 ± 0.58 3.00 ± 1.00 4.00 ± 0.00 4.67 ± 0.58 3.67 ± 0.58 4.00 ± 0.55
MuJoCo 2.33 ± 1.15 1.67 ± 0.58 4.33 ± 1.15 3.33 ± 1.15 4.67 ± 0.57 4.00 ± 0.00 5.00 ± 0.00 3.62 ± 0.66
XDE 1.40 ± 0.55 2.80 ± 1.09 3.60 ± 0.55 2.80 ± 1.09 3.40 ± 1.10 2.80 ± 0.84 3.00 ± 1.00 2.83 ± 1.07

TABLE V: Ratings for the level of user satisfaction of the most diffused tools.

Fig. 4: The simulation tools currently in use among the participants to the survey. The vertical axis reports the number of users
that indicated the tool as their principal.
TOOLS FOR DYNAMICS SIMULATION OF ROBOTS - EXTENDED REPORT 7

• PR2: 21% OpenRave, 14% Gazebo, 14% MuJoCo, 7% • Mostly used in Belgium (36%) and Italy (27%)
Bullet, 7% V-Rep • Used for: 46% mobile robotics, 36% swarm robotics,
• Multi-legged robot: 22% ODE, 11% SL, 11% Bullet, 11% 18% flying robots
Webots • Main simulated robots: 64% khepera/e-puck/thymio, 36%
• Wheeled vehicle: 14% Gazebo, 14% V-Rep, 11% AR- marXbot/footbot, 27% quadrotor
GoS, 7% Morse, 7% Webots, 7% Vortex
• Quadrotor: 24% Gazebo, 24% ARGoS, 12% V-Rep C. ODE
III. S OFTWARE INFORMATION FICHES ODE (Open Dynamics Engine) is an open-source library
for simulating rigid body dynamics, used in many computer
We report in the following some essential information for
games and simulation tools. It is used as physics engines in
the main software tools (the most diffused) that may be of help
several robotics simulators, such as Gazebo and V-Rep.
for the interested reader. Most of the information gathered here
is extracted from the survey (each item is marked by a filled ◦ Web: http://www.ode.org/
dot, •). When it is not the case, an empty dot ◦ is used. For ◦ License: GNU LGPL and BSD
• Survey participants: 10
the subjective user feedback we refer the reader to the full
• OS share: 100% GNU/Linux
report of the survey. Data are reported with %, however to
• Main API: 80% C++
have a fair comparison we report in brackets the number of
• Main reason: 50% best tool upon evaluation, 20% used
participants that selected the specified tool. Note that in the
following “main simulated robots” refers to real robots that before, 10% boss choice, 10% open-source, 10% software
are simulated in the software. already used in the lab
• Mostly used in France (20%)
• Used for: 50% humanoid robotics, 20% multi-legged
A. Gazebo
robotics, 20% snake robots, 10% numerical simulation
Gazebo is a multi-robot simulator for outdoor environments, of physical systems
developed by Open-Source Robotics Foundation. It is the • Main simulated robots: 40% multi-legged robot, 20%
official software tool for the DRC. It supports multiple physics iCub
engines (ODE, Bullet).
◦ Web: http://gazebosim.org/
D. Bullet
◦ License: Apache 2
• Survey participants: 15 Bullet is an open-source physics library, mostly used for
• OS share: 100% GNU/Linux computer graphics and animation. The latest release5 also
• Main API: 80% C++ supports Featherstone’s articulated body algorithm and a
• Main reason for adoption: 53% best tool upon evaluation, Mixed Linear Complementarity Problem solver, which makes
20% software already used in the lab, 20% official tool it suitable for robotics applications.
for a challenge, 7% open-source ◦ Web: http://bulletphysics.org
• Mostly used in USA (33%) ◦ License: ZLib license, free for commercial use
• Mainly used for: 33% mobile robotics, 27% service • Survey participants: 8
robotics, 20% humanoid robotics • OS share: 50% Windows, 38% GNU/Linux, 12% MAC
• Main simulated robots: 40% Atlas, 33% custom platform, OSX
27% wheeled vehicle, 27% quadrotor, 27% turtlebot, 20% • Main API: 75% C++
PR2 • Main reason: 63% best tool upon evaluation, 25% open-
• Main middleware used with: 93% ROS source, 12% colleagues using it
• Main simulated robots: 40% Atlas, 33% custom platform, • Mostly used in France (25%), Italy (25%) and Belgium
27% wheeled vehicle, 27% quadrotor, 27% turtlebot, 20% (25%)
PR2 • Used for: 25% humanoid robotics, 25% numerical simu-
lation of physical systems, 12.5% industrial manipulators,
B. ARGoS 12.5% human motion analysis, 12.5% mobile robotics,
ARGoS is a multi-robot, multi-engine simulator for swarm 12.5% multi-legged robotics
• Main simulated robots: 25% multi-legged robot
robotics, initially developed within the Swarmanoid project4 .
◦ Web: http://iridia.ulb.ac.be/argos/
◦ License: GPLv3.0 E. V-Rep
• Survey participants: 11 V-Rep is a robot simulator software with an integrated
• OS share: 91% GNU/Linux, 9% MAC OSX development environment, produced by Coppelia Robotics.
• Main API: 73% C++ Like Gazebo, it supports multiple physics engines (ODE,
• Main reason: 45% software already used in the lab, 27% Bullet, Vortex).
colleagues using it
5 At the time we are submitting this paper, the latest version is 2.82, released
4 http://www.swarmanoid.org/ at the end of october 2013 - after the survey.
TOOLS FOR DYNAMICS SIMULATION OF ROBOTS - EXTENDED REPORT 8

◦ Web: http://www.coppeliarobotics.com/ • Survey participants: 5

◦ License: Dual-licensed source code: commercial or GNU • OS share: 80% Windows, 20% GNU/Linux
GPL • Main API: 60% C
• Survey participants: 7 • Main reason: 40% software already used in the lab, 20%
• OS share: 57% GNU/Linux, 43% Windows best tool upon evaluation, 20% developer, 20% open-
• Main API: 57% C++, 29% LUA source (free)
• Middleware: 43% ROS, 57% None • Used only in Belgium (40%) and Italy (60%)
• Main reason: 72% best tool upon evaluation, 14% col- • Used for: 60% humanoid robotics, 20% human motion
leagues using it, 14% boss choice analysis, 20% flying robots
• Used for: 29% mobile robotics, 14% industrial manipu- • Main simulated robots: 60% Coman, 40% iCub
lators, 14% humanoid robotics, 14% mechanical design,
14% cognitive architectures, 14% service robotics
I. XDE
• Main simulated robots: 29% Nao, 29% quadrotor, 29%
wheeled vehicle, 29% Bioloid, 29% khepera/ e-puck/ XDE is an interactive physics simulation software environ-
thymio ment fully developed by CEA LIST.
◦ Web:
F. Webots http://www.kalisteo.fr/lsi/en/aucune/a-propos-de-xde
◦ License: Commercial and free non commercial license
Webots is a development environment used to model, pro- • Survey participants: 5
gram and simulate mobile robots developed by Cyberbotics • OS share: 60% GNU/Linux, 40% Windows
Ltd. • Main API: 100% python
◦ Web: http://www.cyberbotics.com ◦ Middleware: OROCOS
◦ License: Commercial or limited features free academic • Main reason: 40% boss choice, 40% software already
license used in the lab, 20% developer
• Survey participants: 7 • Used only in France (100%)
• OS share: 57% GNU/Linux, 29% Windows, 14% MAC • Used for: 40% humanoid robotics, 20% industrial manip-
OSX ulators, 20% numerical simulation of physical systems,
• Main API: 71% C++ 20% human motion analysis
• Main reason: 29% best tool upon evaluation, 29% soft- • Main simulated robots: 40% industrial robots, 40%
ware already used in the lab, 14% boss choice, 14% KUKA LWR, 20% iCub, 20% wheeled vehicle
official tool for a challenge, 14% used before
• Used for: 43% mobile robotics, 43% multi-legged
IV. C ONCLUSIONS
robotics, 14% humanoid robotics
• Main simulated robots: 29% KUKA LWR, 29% Lego With the growing interest of robotics for physical interac-
Mindstorm, 29% wheeled vehicle tion, simulation is no longer a tool for offline computation and
visualization, but is used in particular for rapidly prototyping
controllers. That is why researchers stressed the importance
G. OpenRave
of more realistic simulation, same code for both real and
OpenRave is an environment for simulating motion planning simulated robot, beside the availability of the source code.
algorithms for robotics. This shift in the expectations from simulation reflects in the
◦ Web: http://openrave.org/ migration from physics engines classically used for animation
◦ License: LGPL and Apache 2 of virtual characters and computer graphics towards physics
• Survey participants: 6 engines supporting robotics descriptions of bodies and more
• OS share: 100% GNU/Linux contact solvers. The users’ knowledge of multiple simulation
• Main API: 83% python tools and their activity in testing and abandoning eventually
• Main reason: 50% best tool upon evaluation, 33% col- a tool, suggest that users look for the right tool that meets
leagues using it, 17% boss choice their requirements and is fit for their problem. For instance,
• Mostly used in USA (33%) the robotics community demands physics engines with direct
• Used for: 50% humanoid robotics, 50% service robotics support of robotics descriptions of multi-body systems. This
• Main simulated robots: 50% PR2 is the reason why Bullet is now supporting LCP solvers and
Featherstone’s ABA, and new physics engines like MuJoCo6
H. Robotran or Vortex have been created.
Robotran is a software that generates symbolic models of A good compromise is a modular software that supports
multi-body systems, which can be analysed and simulated multiple physical engines, enabling a tradeoff between simu-
in Matlab and Simulink. It is developed by the Center for lation accuracy and computational resources. Those features,
Research in Mechatronics, Université Catholique de Louvain. together with the stability of the simulation, are of main
◦ Web: http://www.robotran.be/ 6 MuJoCo is not merely a physics engine, it incorporates control and
◦ License: commercial and free non commercial license optimization modules.
TOOLS FOR DYNAMICS SIMULATION OF ROBOTS - EXTENDED REPORT 9

concern for the users. This strategy, adopted with Gazebo by [13] V. Tikhanoff, A. Cangelosi, P. Fitzpatrick, G. Metta, L. Natale, and
the research community and with V-Rep at industrial level, F. Nori, “An open-source simulator for cognitive robotics research: the
prototype of the icub humanoid robot simulator,” in 8th Workshop on
seems to pay off in terms of user feedback, because the Performance Metrics for Intelligent Systems, 2008, pp. 57–61.
first is the most diffused among the survey participants and [14] J.-B. Mouret, S. Koos, and S. Doncieux, “Crossing the reality gap:
the second the best rated. Subjective free-comments7 reported a short introduction to the transferability approach,” in ”Evolution in
Physical Systems” Workshop in ALIFE, 2012.
that users of those tools, though acknowledging their current
limitations, were confident in the announced developments that
could sensibly improve the tools.
To conclude, we overviewed the panorama of simulation
tools that are currently used in robotics. Each software inherits
its specificities from the expected domains of application or
the original application for which is was conceived, which Serena Ivaldi received the M.S. degree in Computer
results in a variety of tools with different features ranging from Engineering with highest honors in 2006 at the Uni-
dynamic solver libraries to systems simulation software. More versity of Genoa (Italy) and her PhD in Humanoid
Technologies in 2011, jointly at the University of
recent tools, like Gazebo and V-Rep, have the potential to be Genoa and Italian Institute of Technology. There
of general use thanks to their good support and community and she also held a research fellowship in the Robotics,
the support of different physical engines. Notwithstanding, we Brain and Cognitive Sciences Department. Since
2011 she is a postdoctoral researcher in the Institut
remind that designing a perfect physics engine is impossible des Systèmes Intelligents et de Robotique (ISIR),
and there will always be a difference between simulation and where she coordinates the experiments of MACSi,
reality, a gap that should be taken into account by the simulator EDHHI and CODYCO projects on iCub. Her re-
search is centered on humanoid robots interacting physically with humans
and the robot controllers [14]. and environment. Web: http://chronos.isir.upmc.fr/∼ivaldi

ACKNOWLEDGMENT
The authors are supported by the EU Project CODYCO
(FP7-ICT-2011-9, No. 600716) - www.codyco.eu.

R EFERENCES
Vincent Padois is an associate professor of Robotics
[1] E. Einhorn, T. Langner, R. Stricker, C. Martin, and H. Gross, “Mira
and Computer Science and a member of the Institut
- middleware for robotic applications,” in IEEE/RSJ Int. Conf. on
des Systèmes Intelligents et de Robotique (ISIR,
Intelligent Robots and Systems, 2012, pp. 2591–2598.
UMR CNRS 7222) at Université Pierre et Marie
[2] E. Drumwright and D. Shell, “An evaluation of methods for modeling
Curie (UPMC) in Paris, France. In 2001, he receives
contact in multibody simulation,” in IEEE Int. Conf. on Robotics and
both an engineering degree from the Ecole Nationale
Automation, 2011, pp. 1695–1701.
d’Ingènieurs de Tarbes (ENIT), France and his mas-
[3] ——, “Extensive analysis of linear complementarity problem (lcp) solver
ter degree in Automatic Control from the Institut
performance on randomly generated rigid body contact problems,” in
National Polytechnique de Toulouse (INPT), France.
IEEE/RSJ Int. Conf. on Intelligent Robots and Systems, 2012, pp. 5034–
From 2001 to 2005, he is a PhD student in Robotics
5039.
of the ENIT/INPT Laboratoire Génie de Production.
[4] R. Featherstone and D. E. Orin, Handbook of Robotics. B. Siciliano
In 2006 and 2007, he is a post-doctoral fellow in the Stanford Artificial
and O. Khatib Eds., Springer, 2008, ch. Dynamics, pp. 35–65.
Intelligence Laboratory and more specifically in the group of Professor
[5] A. Jain, Robot and Multibody dynamics: analysis and algorithms.
O. Khatib. Since 2007, his research activities at ISIR are mainly focused
Springer, 2011.
on the automatic design, the modelling and the control of redundant and
[6] E. Todorov, “Analytically-invertible dynamics with contacts and con- complex systems such as wheeled mobile manipulators, humanoid robots
straints: theory and implementation in mujoco,” in IEEE Int. Conf. on as well as standard manipulators evolving under constraints in complex
Robotics and Automation, 2014. environments. He is also involved in research activities that aim at bridging
[7] E. Todorov, T. Erez, and Y. Tassa, “Mujoco: A physics engine for model- the gap between adaptation and decision making techniques provided by
based control,” in IEEE/RSJ Int. Conf. on Intelligent Robots and Systems, Artificial Intelligence and low-level, reactive control. Since 2011, he holds
2012, pp. 5026–5033. the ”Intervention Robotics” RTE/UPMC chair position.
[8] E. Todorov, “A convex, smooth and invertible contact model for tra-
jectory optimization,” in IEEE Int. Conf. on Robotics and Automation,
2011, pp. 1071–1076.
[9] B. Brogliato, A. ten Dam, L. . Paoli, F. Gnot, and M. Abadie, “Numer-
ical simulation of finite dimensional multibody nonsmooth mechanical
systems,” Applied Mechanics Reviews, vol. 55, pp. 107–150, 2002.
[10] Y.-B. Jia, “Three-dimensional impact: energy-based modeling of tan-
gential compliance,” Int. J. Robotic Research, vol. 32, no. 1, pp. 56–83,
2013. Francesco Nori was born in Padova in 1976. He
[11] C. Duriez, “Control of elastic soft robots based on real-time finite received his D.Ing. degree (highest honors) from the
element method,” in IEEE International Conference on Robotics and University of Padova (Italy) in 2002. He received
Automation. IEEE, 2013, pp. 3982–3987. his Ph.D. in Control and Dynamical Systems from
[12] C. Duriez, F. Dubois, A. Kheddar, and C. Andriot, “Realistic haptic the University of Padova (Italy) in 2005. From 2007
rendering of interacting deformable objects in virtual environments,” he joined the Istituto Italiano di Tecnologia, con-
IEEE Transactions on Visualization and Computer Graphics, vol. 12, tributing significantly to the development of the iCub
no. 1, pp. 36–47, 2006. humanoid robot. His research interest are currently
focused on whole-body motion control exploiting
7 They can be read in the extended version of the survey report: http://www. multiple contacts.
codyco.eu/survey-simulation.
TOOLS FOR DYNAMICS SIMULATION OF ROBOTS - EXTENDED REPORT 10

(a) Gazebo. (b) V-Rep.

Fig. 5: The simulation environment of Gazebo and V-Rep (credits: http://gazebosim.org and
http://www.coppeliarobotics.com).

(a) Gazebo (b) V-Rep

Fig. 6: A graphical representation of the software architectures of Gazebo and V-Rep (credits: http://gazebosim.org
and http://www.coppeliarobotics.com).

Rank Most currently used main tool (>5%) % user share

A PPENDIX A 1 Gazebo 13%
U SERS KNOWLEDGE OF SIMULATION TOOLS 2 ODE 11%
3 Bullet 5%
4 OpenRave 5%
5 V-Rep 5%
6 XDE 5%
We asked subjects to indicate their familiarity with some 7 Blender 5%
existing simulation tools. We provided a list of existing
software tools for simulations, used in different contexts. We TABLE VI: Best software upon user rating.
asked the users to indicate whether the software was currently
used or not for their researches, if it had been used before or
if it was unknown. A summary of the percentage of answers A PPENDIX B
for the most relevant tools was shown in Table I. F REE COMMENTS ABOUT MAJOR PROBLEMS IN
SIMULATION
The most currently used main tools (i.e., tools that have
more than 5% of positive answers to the fact that the software We report hereby the users free comments about their se-
is currently used and it is the main tool) are reported in lected simulation tool. We choose to not alter the answers (e.g.,
Table VI. The least unknown software tools (i.e., tools that correct grammar, punctuation, etc.) to preserve the integrity of
were marked as “never heard of” by the users) are reported in the user’s answers, except for bad language that was replaced
Table VII. The software tools that have been abandoned the by ***.
most after use are reported in Table VIII. • ADAMS
TOOLS FOR DYNAMICS SIMULATION OF ROBOTS - EXTENDED REPORT 11

Rank Least unknown software tool % user that have

never heard about – Not precise enough
this software – Does not apply to my case
1 ODE 10% – Lack of continuos collision detection
2 Gazebo 15%
3 Blender 15%
– Lack of a well understood and properly calibrated
4 Bulle t 24% contact model.
5 Webots 27% – Not able to handle kinematic chains well. Oscillation
6 Nvidia PhysX 32%
7 Stage 38%
of objects.
8 V-Rep 39% – Realism and precision
9 OpenSIM 40%
10 ADAMS 45%
• crrcsim
– customization is done in c++, code is quite convo-
TABLE VII: Least unknown software tool. luted
• Drake
Rank Most abandoned software tool % user that aban-
doned this soft- – The fact that I have to write and maintain it myself.
ware
1 ODE 22% • Dymola
2 Stage 16% – being physics based, usually realistic simulations
3 Webots 13%
4 Bullet 10%
need a very deep knowledge of underlying physical
5 Gazebo 10% parameters (e.g. for contact)
6 Nvidia PhysX 7%
7 OpenHRP 6%
• Gazebo
8 Blender 6% – Lack of documentation, quite slow when simulation
9 OpenRave 5%
10 Vortex 5%
start to be a bit complex. Collisions may results in
non-realistic jumps of the robot.
TABLE VIII: Most abandoned software tool. – The simulations are very slow if it is in a real
environment.
– Gazebo does not yet support all Bullet features,
– Adams could be too slow and requires a lot of system especially non-rigid bodies although we will need
resources. this in future - that might lead to abandance of
– Speed Accuracy Gazebo and use Bullet directly, although lots of
• Arboris-Python efforts
– Lack of surface/surface contact models Use of prim- – Customization
itive shapes only – The dynamics engine is not very sophisticated
– Arboris-Python is slow and has a limited set of – Tuning simulated pid controllers for having stable
features. simulation when real inertias and robot model are
– Computation speed is slow. used.
• ARGoS – It’s hard to create worlds.
– Real-time factor is >50%. Makes it very difficult
– In general, I am very happy with ARGoS, because
to use in semi-virtual experimental setups, where
it does exactly what I expect it to do.
simulated environment is a part of human-centric
– a bit slow for swarming
system.
– Limited to the computational capability of the com-
– Fast simulation required (1kHz+) AND good con-
puter which is provided by the school.
tacts/frictions (this is e.g. when using XDE, not with
– more documentation C++ ***
Gazebo...)
– Difference between reality and simulation (sensors)
– high computational load − > does not cause failures,
– Issue when gripping objects.
but costs lots of time
– None
– With all simulation tools I have tried so far, just
– Visualization of additional information related to the
installing and setting up the simulator properly has
simulation.
been very time and effort consuming.
– Better debugging facilities would be nice.
– Lacking ability to run it on multiple operating sys-
– for now none.
tems. Lacks rewindability and very slow playback of
• Autodesk Inventor logs.
– Programmin for that is not user-friendly. – Deformation modeling
• Autolev – Customization of large environment is time consum-
– Impact and contact modeling. ing.
• Bullet – Simulation of contact with non-rigid bodies like
– The simulation of floor contact. I need very high terrain. Difficulty in simulating fast and dynamic
friction contact points that don’t slide on the floor motions. Computationally slow and demanding.
and this doesn’t work quite right. • own code
TOOLS FOR DYNAMICS SIMULATION OF ROBOTS - EXTENDED REPORT 12

– Not completely realistic simulation of fast humanod depends of prior validations and tuning. This make
motions, due to the fact an internal ankle flexibility some tests slow. This lack of robustness, can be
was represented by the compliant ground contact improved in the future.
• iCub SIM – No robot-model file-formats are supported (e.g.
– No force sensors available on the simulator. COLLADA, VRML, etc.)
– Can run slowly. – stability and numerical accuracy to handle stiff con-
tacts
• MapleSim
– Computationally demanding for simulating full 53
– No major problem: my own code is optimized for degrees of freedom. In particular simulating colli-
speed, which is crucial for numerical optimization. sions between small rigid bodies such as the iCub’s
• Matlab hands.
– They do not model friction well enough – The contact forces that I need to validate my con-
– Yet it is fast performing a complete simulation cycle, troller are often unrealistic.
It is not close to real-time, which is a disadvantage – 1. Stability is the most problem
because re-setup simulation parameters can not be • OpenRave
don ”on the fly”. The accuracy of the simulator, – Slow
depends of prior validations and tuning. This make – Simulating compliant surfaces is difficult/poorly sup-
some tests slow. This lack of robustness, can be ported.
improved in the future – Unstable physics, even can change upon release.
• Moby – The Collision detection module is extremely com-
– Trying to make sure that our control loops run at putational expensive for non-convex objects,so the
the same rate on the simulation as they do on our usage is limited only for convex objects if the
hardware. simulations needs to run in reasonable time.
– I’m not having any problems with the simulations. – Better friction/contact rendering
• Morse • OpenSIM
– integration with other parts of the overall robotics – Sometimes they are really hard to design.
ecosystem. In other words: customization, reuse, – Generating new models of robots or musculoskeletal
composability systems.
– setting up dependencies of software, generating sim- – lack of real-time representation
ulated environments as i am not familiar with blender • RCIS
• MuJoCo – The simulation is computationally demanding if you
– Meshes colors are not supported yet need to run several instances of the simulation in
– Modeling accuracy. What you call ”Gap between parallel.
simulation and reality” • roborobo
– Visualization – The fastest the better
• NeuroRD – It takes some knowledge of the simulator to set up
– They take a long time to complte. the simulation. Unless having one common api for
• ODE all simulators I don’t think that this problem can be
solved
– - lack of feedback by the dynamic engine (what is
the torque actually applied at this joint, after having • RoboticsLab
applied all the constraints?) - lack of stability - no – Collision is unstable very occasionally but it can be
way to predict how confident the simulator is fixed by adjusting parameters.
– CPU load – C++ programming environment.
– Yet it is fast performing a complete simulation cycle, • Robotran
It is not close to real-time, which is a disadvantage – Numerical instability when a control input is non-
because re-setup simulation parameters can not be smooth or if the model is very stiff.
don ”on the fly”. The accuracy of the simulator, – The user has to compute the contact forces and the
depends of prior validations and tuning. This make collision detection
some tests slow. This lack of robustness, can be – Identification of the human physiology
improved in the future. – Speed
– Lack of documentations, steep learning curve, and • SIMPACK
hard customization.
– fast
– Yet it is fast performing a complete simulation cycle,
It is not close to real-time, which is a disadvantage • Simulink + spatial v2
because re-setup simulation parameters can not be – slow (because of Matlab)
don ”on the fly”. The accuracy of the simulator, • Simulink and Matlab
TOOLS FOR DYNAMICS SIMULATION OF ROBOTS - EXTENDED REPORT 13

– it takes a lot of time to build what is not exists. – Customizable tradeoff between simulation precision
• SL and computational resources
– In case of SL the biggest issue could be collision, – Dynamic of human movements is to fast to be
since the robot geometry is not considered. Also, accuratley reproduced in simulation : movemenst are
only point contact is considered. This could be not the same and fast movements leads to a lost of
improved. balance and fall of the manikin.
– Documentation – contacts forces time evolution
• trep
– Our software has no automatic handling of contact A PPENDIX C
or impact maps. Additionally, adaptive time-stepping F REE COMMENTS ABOUT DESIRABLE FEATURES MISSING
breaks some of the guarantees of structured integra- IN THE SOFTWARE
tion. • ADAMS
• Vortex – Easy interface with pro/e or other CAD softwares.
– Lack of the proper documentation, simulation of – customization ( coding a new body element) ”Re-
sand and digging in it. thinking the modeling the technique”
– not specific to software: getting material properties • Arboris-Python
and other parameters right
– Catalogue of contact models Use of custom shapes
– Having to write copious amounts of C++ to get
– C++ coding, general collision detection.
things going.
– It lacks of the same code for real and simulating
• VoxCad environment.
– Need more speed
• ARGoS
• V-Rep
– Integration with other tools is the next big task to
– They can be slower on an older laptop, and we need work on. Also, increasing the number of supported
real time(ish) actuation when the operator is in the robots.
loop. But that is just a question of horse power. – a nice documentation, but as the support is reactive,
– repetability of some dynamic events (e.g. grasping it compensiates.
when fingered) – Changing the environment without having to pause
– GPU and redu function not vast enough the simulation and moving the objects manually.
– No problems until now. It does what I need it to do. – better logging infrastructure
– Most of them take place in the future ;-) meaning: – Magnetics and soft bodies + contact forces simula-
the above answers are based on what I want to do tion
with V-Rep, but I have not yet found the time and – I’m sure many, but for my work, none.
resources to do it. – None
– No elastic bodies simulation support – Visualization: - showing additional metadata for each
– Difficulty building models for multi-point grasping robot (current values of variables etc.); - interactive
(humanoid style hand). exploration of the current situation (e.g. shortest path
• Webots visualizations).
– difficulty in describing dynamics. – More robots simulated.
– Slowness: for evolutionary robotics, I need many – scripting, but it’s coming soon
repeats/trials. When simulating modular robots, the • Autodesk Inventor
system grinds to a halt when simulating more than
– A toolbox in Matlab or Simulink for automated
a couple of dozen modules.
connection between Inventor and Simulink
– our controller require the simulation to be realtime,
which it is not on complicated environments when • Autolev
the camera is simulated. The root problem is our – Handling systems with large numbers of degrees of
controller not the simulator though. freedom. However, this software was not built for
– Inaccuracies, contact model, MODELING COMPLI- this purpose.
ANCE IN A GOOD WAY WITHOUT SIMULA- • Bullet
TION EXPLOSION, closed chain kinematics, being – Comprehensive and accurate documentation.
different from reality, difficulty porting to the robot – Precision of body interaction
– robot planning algorithms – Does not apply to my case
– Robot description could be made more user friendly – GPU based simulation pipeline
• XDE – Better explanation of the contact model it uses and
– Compatibilty with software dependencies extensions to better handle friction between surfaces
– Documentation may be insufficient to solve some and preventing all limb detachments and object in-
difficulties in the setup/control of the simulation. terpenetrations.
TOOLS FOR DYNAMICS SIMULATION OF ROBOTS - EXTENDED REPORT 14

– Better handling of kinematic chains (open and closed middleware: HLA, MQP, DDS,... Logging of simu-
loop). lation experiments, in HDF5 files, with a simulation
– None campaign meta model.
• crrcsim – 2d projection of simulation
– - system identification to import real robot models - • MuJoCo
ROS support - simulated sensors, esp. camera – Rendering
– Inverse dynamics with contacts.
• Drake
– None
– We add them as we need them. We link against bullet
• NeuroRD
for collision detection, but otherwise have rolled the
entire implementation ourselves. – Easy way of specifying the model.
• ODE
• Dymola
– - feedback (that is, accurately simulating force and
– lack of reusable libraries
torque sensors) - confidence estimations of the sim-
• Gazebo ulation
– An up-to-date and complete documentation, up-to- – God’s hand: ability to interact with the simulated
date tutorials. environment from outside the simulation when we
– The documentation and possible computation times. mix simulation and real feedbacks.
– physics simulation of non-rigid bodies (Bullet) – easy customization. Currently this is possible, but
– A better dynamics simulation engine, more realism requieres expert coding habilities.
in general and better look in general of the virtual – easy use of APIs
worlds – easy customization. Currently this is possible, but
– Easy way (graphic interface) for designing robot requires expert coding abilities.
model. – - Supporting robot-model file-formats (e.g. COL-
– A model editor. LADA, VRML, etc.). - Providing sensor objects (e.g.
– Real-time calculation Gyro, LRF, camera, accelerometer, etc.) - Providing
– Say, deformable bodies simulation... (for XDE). a rendering tool (I want a simple one, such as using
AND a decent documentation.... OpenGL). - Providing a sophisticated C++ interface.
– a mode to trade off accuracy for speed – Adding other robots.
– Software stability, adequate interoperability with – Easier interfaces and better accuracy.
ROS. – 2. ability to run in a non-gui mode
– Needs ability to rewind or replay simulations easily. • OpenRave
– Better time navigation, deformations, cross-platform – Good physic engine that is free
support – Simulation of compliant surfaces and contact models.
– Built in model editor – Simulation of compliant surfaces and contact models.
– Easy and quickly setup of the simulation environ- – Stable physics, more C++ documentation (there are
ment Python examples, which is not bad, but it would be
• iCub SIM easier the other way around).
– Possibility to simulate force/torque sensors and skin. – Better Collision Detection algorithm for non-convex
– Would really like to have a better way to import 3D objects, with better force computation. And a more
mesh objects into the iCub simulation. There is some robust and interactive constraint solver.
basic functionality, but it only seems to work for very – sensors and human
simple shapes. • OpenSIM
• MapleSim – Environment building. We need something like
– Good documentation of all possible API commands. minecraft for that.
– An open source gui to create new models. Currently,
• Matlab we have to generate them by writing xml files.
– easy customization. Currently this is possible, but – lack of rigid contacts
requieres expert coding habilities. • Own code
• Moby – Flexible part simulation, more realistic contact sim-
– Could be more user friendly. ulation
– It would be great if Moby were better linked with – clean code and documentation.
Gazebo or V-Rep. • RCIS
• Morse – Documentation
– Standardization in model representations. (And i • roborobo
do not want a ”one size fits all” ”standard” – The fastest the better! And also: (1) parrallel imple-
like URDF! Support for professional communication mentation is currently missing (2) save/load snapshot
TOOLS FOR DYNAMICS SIMULATION OF ROBOTS - EXTENDED REPORT 15

of current state of the simulator (to relaunch from – maybe compliant contact, even if soft bodies (cables)
exact same point). exist
– - clear documentation – Documentation
• RoboticsLab – Documentation ... Also not sure you can specify an
– None external force as a task in the controller.
– inter-operation with MATLAB – soft contacts simulation
• Robotran
A PPENDIX D
– 3D collision detection and speed of simulation. F REE COMMENTS ABOUT CONTACT MODELS
– A bio-mechanics library
– Compatibilty towards UNIX. • Autodesk Inventor
• Simulink + spatial v2 – You have to determine which contact surface is
important for you, then it seems that the software
– geometric models
interacts with it similar to a joint.
• Simulink and Matlab
• Morse
– being real-time while interacting with real world.
– Contacts are the last thing I want to see people
• SL rely on a simulator! The real world physics is too
– More user-friendly interface. complex to get into a simulator...
– Documentation • ODE
• trep – differential algebraic stiff solvers
– We are the developers, so we could add them our- • OpenRave
selves. – ODE/BULLET/PQP flexible implementation.
• Vortex • Robotran
– documentation / tutorials – H. Dallali, M. Mosadeghzad, G. Medrano-Cerda,
– Better documentation; more ’end-user’ API function- N. Tsagarakis, D. Caldwell, A Dynamic Simula-
ality tor for the Compliant Humanoid Robot, COMAN,
• VoxCad To Appear in ICRA Wokrshop on Developments
– Many of Simulation Tools for Robotics & Biomechanics,
• V-Rep Karlsruhe, Germany, May 10, 2013.
– none, the forum allows to do feature requests if any, – The contact model I am using has been written by
and they usually appear in the next release (once other researchers, and it is not provided with the
every 2-3 months) simulator (robotran).
– Support of more CAD file formats, which are not • Simulink + spatial v2
mesh-based. – physically realistic nonlinear spring+damper in both
– It would be interesting if it was possible to run the normal and tangent direction, + clutch in tangent
simulator as a web server, so students could run direction implementing genuinely conical friction
simulations with their controllers over the internet. cone; all changes of state being detected accurately
– Lecture material that can be reused to let students using Simulink’s zero-crossing detection.
use the software in courses. (We are working on this • V-Rep
in collaboration with another University though). – No
– More friendly interface – I think the most important aspect of contact solving
– More general ROS API is to get it qualitatively right. At the end of the day,
• Webots it is only true experimentation in the physical world
– several: easier usage in terms of programming, more that will determine if the combined mechanism and
simulating robots, more sensor information, better controller etc are performing properly.
documentation • Webots
– Truly headless operation – I think Webots uses bullets.
– Non rigid surfaces, fluids
• XDE
– having it free and open source would be great of
course. – I heard XCD is based on a Gauss-Seidel Algorithm
– 1- being physically realistic. It is ok, but not perfect. • own software
2- access to internal forward dynamics states. – It is an multi-robot simulator where each robot is
– fast merge between it and LISP simple modelised as an non-honolomic particul.
– Open source
• XDE
– Documentation