CoppeliaSim (formerly V-REP): a Versatile and Scalable Robot

Simulation Framework
Eric Rohmer, Surya P. N. Singh and Marc Freese1

Abstract— From exploring planets to cleaning homes, the There are currently several robot simulation platforms
reach and versatility of robotics is vast. The integration of available, for instance Open HRP [1], Gazebo [2] or Webots
actuation, sensing and control makes robotics systems [3]. While some offer competing functionality, many fail in
powerful, but complicates their simulation. This paper offering a large and complementary palette of programming
introduces a versatile, scalable, yet powerful general-purpose techniques, and their simulation models and controllers are
robot simulation framework called V-REP. only partially portable: models, controllers and other
The paper discusses the utility of a portable and flexible functionality are clearly distinct, and thus need separate
simulation framework that allows for direct incorporation of handling. For example, controller recompilation on a
various control techniques. This renders simulations and different hardware or platform is often necessary, or the
simulation models more accessible to a general-public, by simulation model and controller need to be carefully matched
reducing the simulation model deployment complexity. It also
since they represent at least two distinct files, and when
increases productivity by offering built-in and ready-to-use
functionalities, as well as a multitude of programming
scaling is supported, it is done via relatively obscure hard-
approaches. wired mechanisms.
This allows for a multitude of applications including rapid The Virtual Robot Experimentation Platform [4] (main
algorithm development, system verification, rapid prototyping, user interface shown in Fig. 1) – or simply V-REP simulator
and deployment for cases such as safety/remote monitoring, – is the result of an effort trying to council all requirements
training and education, hardware control, and factory into a versatile and scalable simulation framework. Next to
automation simulation. offering the traditional approaches also found in other
simulators, V-REP adds several additional approaches.
I. INTRODUCTION Section II of this paper describes V-REP’s control
architecture, in which the various possible controller types
The exponential increase in processing power of are explained, in particular embedded scripts. That is, they
computers (not to mention 3D graphics hardware) along with can be an integral part of a simulation model, thus extremely
the plethora of open software and hardware standards has portable and scalable. Section III discusses the overall offered
drastically changed the landscape in the field of (3D) robotics simulation functionality, and its integration into simulation
simulation. Not only has this enabled more complexity on the models, also for the sake of portability. Finally, section IV
desktop, but conversely it has provided the ability to run examines three practical V-REP simulation models and their
simulations (in real-time) with hardware in-the-loop, or to implementation, as an illustration of this paper’s content.
have mobile/embedded systems controlled from a simulation
framework.
While it is possible to assemble a simulator from the
various kinematics, physics and graphics libraries, the
architecture and control methodology are crucial to
determining how these elements interact and thus the overall
performance and accuracy of the system. A robust systems
approach advocates for a versatile, scalable and fine-grained
simulation strategy.
Practically, a general-purpose robot simulator has to
provide multitude tools and functionalities simultaneously,
while abstracting the underlying robotic systems and their
complexity since system specificities cannot be foreseen.
Additionally, one wants a flexible controller approach that
can be portable and easily coded (and maintained), Figure 1. An example V-REP simulation scene showing the diversity of
generalizable to various models, and scalable (i.e. simulation robot types that may be simulated simultaneously
entities should handle multiple models, controllers or any
other functionality).
II. SIMULATION CONTROLLERS
1
Corresponding author: [email protected] If one wants to build complex simulation scenarios, then
Eric Rohmer is a lecturer at the State University of Campinas, Brasil there is almost no escape from a distributed control
Surya Singh is a lecturer at the University of Queensland, Australia framework. It simplifies the task by partitioning control
Marc Freese is CEO of Coppelia Robotics, Switzerland. entities, it speeds-up simulation by distributing the CPU load
over several cores or several machines, and it allows a
simulation model be controlled by native code execution. The most common implementations of the above
There are however simulation requirements that should not techniques (i.e., using external executables or plug-ins) have
be forgotten in pursuit of that goal. as a direct consequence poor portability and poor scaling of
One of the most important and often neglected aspect is simulation models: indeed, since the control code is not
the flexibility, portability and scalability of the simulation attached to its respective simulation model, it will have to be
model: how easy is it to adjust its control code(s)? How distributed/compiled/installed separately. This increases
many files have to be distributed in order to run the same compatibility problems across platforms, as well as
simulation model on another machine? Will it require conflict/dependency issues with other libraries. Flexibility is
also reduced, since one would have to recompile and reload
recompilation on other platforms? How many versions of the
an executable/plug-in for each small code modification.
same controller are in circulation? Can various versions
Model duplication, as in a multi-robot simulation scenario,
operate side-by-side? Can a simulation model easily be will have to be supported via hard-wired mechanisms that
instantiated several times, without losing functionality? launch new control instances for each simulation model
Other simulation control requirements are linked to the instance.
simulation loop. Some elements, especially the low-level
controls such as real-time motion level controllers, require B. V-REP Implementation
synchronization with the simulation loop. (i.e. executed at
V-REP allows the user to choose among various
the same moment at each simulation pass).
programming techniques simultaneously (Table 1) and even
The importance of providing synchronous/asynchronous,
symbiotically (Fig. 2):
external/embedded, native/non-native distributed control
techniques in robotics simulations is discussed hereafter. • Embedded scripts. This represents the most
powerful and distinctive feature of V-REP. The main
A. Overview of Common Techniques simulation loop is a simple Lua [5] script (called
The execution of the control code of a simulation or a “main script”), part of a given simulation scene, that
simulation model is handled using the following three handles general functionality (e.g. it will call distinct
techniques: functions to handle kinematics or dynamics, for
instance). The main script is also in charge of calling
• The control code is executed on another machine.
child scripts in a cascaded way (with respect to the
This could represent a distinct machine or a robot,
scene hierarchy). A child script, unlike the main
connected to the simulator machine via a specific
script, is attached to a specific object in the
network (e.g. socket, serial port, etc.). The main
simulation scene, and handles a particular part of the
advantage of this approach is the originality of the
simulation. It is an integral part of its scene object,
controller (the control code can be native and running
and will be duplicated and serialized, together with it.
on the original hardware). Another advantage is the
As such, it represents a perfectly portable and
reduced computing load on the simulation machine.
scalable control element: there is one single file
On the other hand, this approach imposes serious
containing the model definition together with its
limitations in regards to synchronization with the
control or functionality, there is no compatibility
simulation loop, and the communication delay/lag
issue across platforms, no need for explicit
dictated by the network.
compilation, no conflict among several versions of
• The control code is executed on the same machine, the same model, model instantiation is implicit, etc.
but in another process (or another thread) than Child scripts can be executed in a threaded and non-
the simulation loop. Here also, we can benefit from threaded fashion. The threaded version of child
a reduced, or rather balanced load on the CPU cores, scripts still keeps the advantages of the technique
but this comes accompanied with a lack of described in point 3 of section II, A: indeed, V-
synchronization with the simulation loop. And most REP’s thread scheduler handles threads in a way that
of the time, it comes in pair with a communication makes them behave and appear as coroutines, which
lag or thread switching delay (many resources allow to precisely control the time at which the
require locking before access, or some algorithms thread execution is switched back and forth,
aren't reentrant). This control technique is often effectively allowing for an excellent synchronization
implemented via external executables or plug-ins with the main script or other child scripts.
loaded by the simulator. Additionally, each thread can programmatically
request being set into a free-running mode (i.e.
• The control code is executed on the same machine allowing them to temporarily behave as real threads).
and in the same thread as the simulation loop. The Embedded scripts can also be seen as a “glue
main advantage of this approach is the inherent component”, that binds the various supported
synchronization with the simulation loop, and the programming techniques around V-REP: child
absence of any execution, communication or thread scripts can register ROS publishers/subscribers, they
switching lag or delay. This however is only made can open and handle communication lines (e.g.
possible with an increased load on the simulation socket or serial port), launch executables,
loop CPU core. This control technique is often load/unload plug-ins, or start remote API server
implemented via plug-ins loaded by the simulator. services (see point 4 hereafter). Embedded scripts
include also callback scripts, used as low-level
 customized joint controllers for instance. The functions, with two exceptions however: remote API
functionality of embedded scripts can be extended by functions accept an additional argument which is the
the user via two mechanisms: with Lua extension operation mode, and return a same error code. The
libraries, or with custom Lua functions registered operation mode allows calling functions as blocking
through a plug-in. (will wait until the server replies), or non-blocking
(will read streamed commands from a buffer, or
• Add-ons. In a similar way as embedded scripts, add- start/stop a streaming service on the server side). The
on are supported in V-REP via Lua scripts. They can ease of use of the remote API, its availability on all
be used as stand-alone functions (convenient for platforms, and its small footprint, makes it an
writing importers/exporters), or as regularly executed interesting alternative to the ROS interface (see next
code (convenient as a lightweight simulator item).
customization method).
• ROS [6] nodes. V-REP implements a ROS node
• Plug-ins. Plug-ins are used in V-REP as a convenient with a plug-in which allows ROS to call V-REP
simulator customization tool. They can register commands via ROS services, or stream data via ROS
custom Lua commands, allowing the execution of publishers/subscribers. Publishers/subscribers can be
fast callback functions from within an embedded enabled with a service call, and also directly enabled
script. They can also extend the functionality of a from within V-REP, via an embedded script
particular simulation model or object. Often they also command.
implement specific importers/exporters, or offer an
interface to a specific hardware. The remote API
interface as well as the ROS interface (see next
items) are implemented via plug-ins.

TABLE I. COMPARISON OF THE FIVE PROGRAMMING TECHNIQUES

SUPPORTED IN V-REP

Figure 2. V-REP control architecture. Greyed items are control entities.

(1) C/C++ API calls, (2) cascaded child script execution, (3) Lua API calls,
(4) custom Lua API callbacks, (5) V-REP event callbacks, (6) remote API
function calls, (7) ROS transit, (8) custom communication (socket, serial,
pipes, etc.)

III. SIMULATION FUNCTIONALITY

V-REP is designed around a versatile architecture. There
• Remote API clients. The remote API interface in V- is no main or central functionality in V-REP. Rather, V-REP
REP allows interacting with V-REP or a simulation, possesses various relatively independent functionalities, that
from an external entity via socket communication. It can be enabled or disabled as required, also on a model-base.
is composed by remote API server services and
remote API clients. The client side can be embedded Imagine a simulation scenario where an industrial robot
as a small footprint code (C/C++, Python, Java, has to pick-up boxes and move them to another location; V-
Matlab & Urbi) in virtually any hardware including REP computes the dynamics for grasping and holding the
real robots, and allows remote function calling, as boxes and performs a kinematic simulation for the other parts
well as fast data streaming back and forth. On the of the cycle when dynamic effects are negligible. This
client side, functions are called almost as regular approach makes it possible to calculate the industrial robot's
movement quickly and precisely, which would not be the • Graphs: graphs can record a large variety of
case had it been simulated entirely using complex dynamics predefined or custom data streams. Data streams can
libraries. This type of hybrid simulation is justified in this then be displayed directly (time graph of a given data
situation, if the robot is stiff and fixed and not otherwise type), or combined with each other to display X/Y
influenced by its environment. graphs, or 3D curves.
In addition to adaptively enabling various of its • Cameras: they allow scene visualization when
functionalities in a selective manner, V-REP can also use associated with a viewport.
them in a symbiotic manner, having one cooperate with
another. In the case of a humanoid robot, for example, V- • Lights: lights illuminate a scene or individual scene
REP can handle leg movements by (a) first calculating objects, and directly influence cameras or vision
inverse kinematics for each leg (i.e., from a desired foot sensors.
position and orientation, all leg joint positions are calculated); • Paths: they allow complex movement definitions in
and then (b) assigning the calculated joint positions to be space (succession of freely combinable translations,
used as target joint positions by the dynamics module. This rotations and/or pauses), and are used for guiding a
allows specifying the humanoid motion in a very versatile welding robot's torch along a predefined trajectory,
way, since each foot would simply have to be assigned to or for allowing conveyor belt movements for
follow a 6-dimensional path: the rest of calculations are example.
automatically taken care of.
• Dummies: a dummy is a reference frame, that can be
Functionality is related to specific scene objects, or to used for various tasks, and is mainly used in
specific calculation modules, both of them are described conjunction with other scene objects, and as such,
hereafter. can be seen as a “helper.”
A. Scene Objects • Mills: they represent customizable convex volumes
A V-REP simulation scene, or simulation model contains that can be used to simulate surface cutting
several scene objects or elemental objects that are assembled operations on shapes (e.g., milling, laser cutting,
in a tree-like hierarchy. The following scene objects are etc.).
supported in V-REP:
• Joints: joints are elements that link two or more
scene objects together with one to three degrees of
freedom (prismatic, revolute, screw-like, or
spherical). They can operate in various modes (e.g.
force/torque mode, inverse kinematics mode, etc.)
• Shapes: shapes are triangular meshes, used for rigid
body simulation and visualization. They can be
optimized for fast dynamic collision response
calculation, as a grouping of primitive or convex
shapes. Other scene objects or calculation modules
heavily rely on shapes for their calculations
(proximity sensors, the dynamics module, or the
mesh-mesh distance calculation module for
example). Figure 3. Proximity sensor in V-REP

• Proximity sensors (Fig. 3): they perform an exact

minimum distance calculation to the part of a shape A. Calculation Modules
contained in a configurable detection volume [7], as Scene objects are rarely used on their own, they rather
opposed to simply performing detection based on operate on (or in conjunction with) other scene objects (e.g. a
rays. This results in a more continuous operation and proximity sensor will detect shapes). In addition, V-REP
thus allows for more realistic simulation. offers several calculation modules that can directly operate
on one or several scene objects. Following are the main
• Vision sensors: vision sensors allow to extract calculation modules:
complex image information from a simulation scene
(colors, object sizes, depth maps, etc.). A built-in • Kinematics module: allows kinematics calculations
filtering and image processing function enables the (forward/inverse) for any type of mechanism
composition of blocks of filter elements. Vision (branched, closed, redundant, containing nested
sensors make use of hardware acceleration for the loops, etc.). The module is based on calculation of
raw image acquisition (OpenGL). the damped least squares pseudoinverse [8]. It
supports conditional, damped/undamped, and
• Force sensors: they represent rigid links between weighted resolution.
shapes, that can record applied forces and torques,
and that can conditionally break apart when a given • Dynamics module: allows handling rigid body
threshold is overshot. dynamics calculation and interaction (collision
 response, grasping, etc.) via the Bullet Physics Following three examples illustrate nicely the versatility and
Library [9] and the Open Dynamics Engine [10]. portability of simulation models offered in V-REP.
Dynamics-based simulations still being in its infant
shoes and often based on approximations, it is A. Simulation Model of a Laser Scanner
important to not only rely on one single physics Fig. 4 shows a laser scanner simulation model in V-REP.
engine, in order to validate results. At the time of The model is composed by a body or casing, a revolute joint,
writing, a third, high fidelity physics support via and a ray-type proximity sensor mounted on the joint. A non-
Vortex Dynamics [11] is in preparation. threaded child script is attached to the sensor casing, and is in
• Collision detection module: allows fast interference charge to move the joint by a given angle, read the proximity
checking between any shape or collection of shapes. sensor, generate a line primitive in the scene (and an
This module is fully independent from the collision auxiliary point primitive where a detection occurred), then
response calculation algorithm of the dynamics move to the next angular position. Since the child script runs
module. It uses data structures based on a binary tree non-threaded, it will have to process as many joint angle
of oriented bounding boxes [12] for accelerations. positions as the joint would have moved within one
Additional optimization is achieved with a temporal simulation step.
coherency caching technique. The model can be dragged and dropped into a scene, and
• Mesh-mesh distance calculation module: allows will be immediately operational during simulation. The
fast minimum distance calculations between any whole model fits into a single file directly usable on other
shape (convex, concave, open, closed, etc.) or platforms too, and compatible with current as well as future
collection of shapes. The module uses the same data V-REP versions. The model can be duplicated as often as
structures as the collision detection module. required, and its control code modified at will.
Additional optimization is also achieved with a
temporal coherency caching technique.
• Path/motion planning module: handles holonomic
path planning tasks and non-holonomic path
planning tasks (for car-like vehicles) via an approach
derived from the Rapidly-exploring Random Tree
(RRT) algorithm [13]. Path planning tasks of
kinematic chains are also supported.

For versatility the above modules are implemented in a

general way, without making any assumptions on the
underlying simulation scenes or models. The purpose of
having them integrated in V-REP, instead of relying on
external libraries is somewhat similar to the purpose of
having embedded scripts, as described in section II, B: a vast Figure 4. Laser scanner and hexapod model in V-REP
majority of simulations or simulation models do not require
any specific or high-end tool. They instead require a good set In a similar way, other such models can easily be created,
of basic tools. If those are integrated to the simulator, and be it a drawing pen, a paint nozzle, a gripper, a blob detection
their task definitions directly attached to simulation models, camera, or a whole robot.
then models become extremely portable: distribution of a
simulation model to a different machine or platform is done B. Simulation Model of a Parallel Manipulator
via a single model file; there is no need to distribute, Fig. 5 shows a parallel manipulator model controlled in
recompile, install or reload a plug-in. In a similar way, this forward kinematics from an external application that
makes models very scalable too: duplicated models are connects via the remote API to it. In order to correctly handle
automatically functional, without the need to modify any all the loop closure constraints, the model is handled via V-
source code. The duplication process can even happen during REP’s kinematics module. Since all related kinematics task
simulation. definitions are attached to the model, this model is self-
The traditional approach of extending functionality via a contained too, and immediately duplicable and operational on
plug-in, in order to support a specific simulation model is of other platforms too. Even physical scaling of the model,
course also supported in V-REP. which is another feature that V-REP supports, will
automatically adjust all kinematic tasks (among others), and
keep kinematic resolution consistent - without the need to
IV. A CASE STUDY
adjust any code.
Sometimes there is no escape from using a controller that
is separate from its simulation entity, typically when dealing C. Simulation Model of a Smart Human
with a robot’s main controller, that can take very complex Fig. 6 illustrates a simulation model of a human,
proportions. Or when the controller needs to run natively. performing path planning tasks between its current position
But other times, is it really necessary to implement a plug-in and a desired target position. While the path planning task in
for each small sensor, new feature or small function?
itself is computed by V-REP’s path planning module, a child complex assembly chains in factory automation applications,
script attached to the model will trigger path planning to robot task planner and controller.
calculations, actuate legs and arms, and correctly move the
model along the calculated path. Here also, the model is fully ACKNOWLEDGMENT
self-contained and fully portable.
Eric Rohmer thanks the Sao Paulo Research Foundation
FAPESP for its financial support.
V. CONCLUSION
V-REP is introduced as a versatile and scalable simulation REFERENCES
framework. By offering a multitude of different [1] F. Kanehiro, H. Hirukawa, and S. Kajita, “Open HRP: Open
programming techniques for its controllers, and by allowing Architecture Humanoid Robotics Platform,” Int. J. of Robotics
Research, vol 23, pp. 155-165, 2004
to embed controllers and functionalities in simulation [2] N. Koenig, and A. Howard, “Design and use paradigms for Gazebo,
models, it eases the programmers task and reduces the an open-source multi-robot simulator,” in Proc of Int. Conf. on
deployment complexity for the users. Intelligent Robots and Systems, pp. 2149-2154, Sendai, Japan, Sept.-
Oct. 2004
[3] O. Michel, “Webots: professional mobile robot simulation,” Int. J.
Adv. Robot. Syst., vol. 1, pp. 39-42, 2004
[4] V-REP simulator : http://www.coppeliarobotics.com
[5] Lua: http://www.lua.org
[6] M. Quigley, B. Gerkeyy, K. Conleyy, J. Fausty, T. Footey, J. Leibsz,
E. Bergery, R. Wheelery, and A. Ng, “ROS: an open-source Robot
Operating System,” in Proc of IEEE Int. Conf. of Robotics and
Automation, Kobe, Japan, May 2009
[7] M. Freese, F. Ozaki, and N. Matsuhira, “Collision Detection, Distance
Calculation and Proximity Sensor Simulation using Oriented
Bounding Box Trees,” 4th International Conference on Advanced
Mechatronics, pp. 13-18, Asahikawa, Japan, Oct. 2004
[8] C. W. Wampler, “Manipulator Inverse Kinematic solutions based on
Vector Formulations and Damped Least Squares Methods,” in IEEE
Trans. Syst., Man, Cybern., vol. 16, pp. 93-101, 1986
[9] Bullet physics library : http://www.bulletphysics.org
[10] Open dynamics engine: http://www.ode.org
[11] Vortex Dynamics: http://www.vxsim.com
[12] S. Gottschalk, M. C. Lin, and D. Manocha, “OBB-tree : a hierarchical
structure for rapid interference detection,” ACM SIGGRAPH, pp. 171-
180, New Orleans, USA, Oct. 1996
[13] J. J. Kuffner Jr., “RRT-Connect: an Efficient Approach to Single-
Query Path Planning,” in Proc of IEEE Int. Conf. of Robotics and
Figure 5. Delta Arm manipulator model in V-REP Automation, San Fransisco, USA, Apr. 2000

Figure 6. Path planning human model in V-REP

Currently V-REP has grown to a robust and widely used

robot simulator and controller, present in the academic as
well as industrial field. It performs tasks ranging from
system verification, algorithm optimization, simulation of