V-Rep. Presentation no.

12

Writing code in and around V-

REP
Highlights
• Writing code in and around V-REP
• Embedded scripts
• V-REP API framework
Writing code in and around V-REP
V-REP is a highly customizable simulator: every aspect of a simulation
can be customized. Moreover, the simulator itself can be customized
and tailored so as to behave exactly as desired. This is allowed
through an elaborate Application Programming Interface (API).

Six different programming or coding approaches are supported, each

having particular advantages (and obviously also disadvantages) over
the others, but all six are mutually compatible (i.e. can be used at the
same time, or even hand-in-hand).
Writing code in and around V-REP |

The control entity of a model, scene, or the simulator itself can be

located inside:
• an embedded script (i.e. customizing a simulation (i.e. a scene or
models) via scripting): this method, which consists in writing Lua scripts,
is very easy and flexible, with guaranteed compatibility with every other
default V-REP installations (as long as customized Lua-commands are not
used, or are used with distributed plugins). This method allows
customizing a particular simulation, a simulation scene, and to a certain
extent the simulator itself. This is the easiest and most used
programming approach.
Writing code in and around V-REP |

• an add-on: this method, which consists in writing Lua scripts,

allows to quickly customize the simulator itself. Add-ons can
start automatically and run in the background, or they can be
called as functions (e.g. convenient when writing
importers/exporters). Add-ons should not be specific to a
certain simulation or model, they should rather offer a more
generic, simulator-bound functionality.
Writing code in and around V-REP |

• a remote API client (i.e. customizing the simulator and/or a

simulation via a remote API client application): this method
allows an external application (e.g. located on a robot,
another machine, etc.) to connect to V-REP in a very easy way,
using remote API commands.
Writing code in and around V-REP |

• a BlueZero node (i.e. customizing the simulator and/or a

simulation via a BlueZero node): this method allows an
external application (e.g. located on a robot, another machine,
etc.) to connect to V-REP via BlueZero.
Writing code in and around V-REP |

• a plugin (i.e. customizing the simulator and/or a simulation via

a plugin): this method basically consists in writing a plugin for
V-REP. Oftentimes, plugins are only used to provide a
simulation with customized Lua commands, and so are used in
conjunction with the first method.
Embedded scripts
V-REP is a highly customizable simulator: almost every step of
a simulation is user-defined. This flexibility is allowed through
an integrated script interpreter. The scripting language is Lua,
which is an extension programming language designed to
support general procedural programming.
Writing code in and around V-REP |Embedded scripts

An embedded script is a script that is embedded in a scene (or

model), i.e. a script that is part of the scene and that will be
saved and loaded together with the rest of the scene (or
model). There are different types of embedded scripts that are
supported.
Writing code in and around V-REP |Embedded scripts

Each type has specific features and application areas:

[Embedded script types]

Writing code in and around V-REP |Embedded scripts

Two major types of embedded scripts are supported:

• Simulation scripts: simulation scripts are scripts that are

executed only during simulation, and that are used to
customize a simulation or a simulation model. The main
simulation loop is handled via the main script, and
models/robots are controlled via child scripts.
Writing code in and around V-REP |Embedded scripts

• Customization scripts: those are scripts that can also be

executed while simulation is not running, and that are used
to customize a simulation scene or the simulator itself.
Writing code in and around V-REP |Embedded scripts

• Among the different script types, it can be useful to

remember that some are associated with scene objects
(attached to scene objects, i.e. associated scripts) such as
child scripts, joint control callback scripts and customization
scripts, and others are unassociated (i.e. unassociated
scripts).
Writing code in and around V-REP |Embedded scripts

• Associated scripts, which form the basis of V-REP's

distributed control architecture, share the convenient
property to be automatically duplicated if their associated
object is duplicated.
V-REP API framework
The V-REP API framework groups all interfaces around V-REP. It comes
in 5+1 different flavours:

• The regular API

• The remote API
• The ROS interfaces
• The BlueZero interface
• The auxiliary API
• Other interfaces
Writing code in and around V-REP |V-REP API framework

The auxiliary API is not an interface per

se, but more a collection of helper
functions that can be embedded, and
that operate on their own. The other
interfaces item groups all possibilities
for the user to extend the available
interfaces. Following figure illustrates an
overview of the various interfaces:

[Various locations and interfaces available]

Writing code in and around V-REP |V-REP API framework

The regular API is part of the V-REP API framework.

The regular API is composed by several hundreds of functions

that can be called from a C/C++ application (plugin or main
client application), or an embedded script. V-REP functions and
constants can easily be recognized from their "sim"- or "_sim"-
prefix (e.g. sim.handleCollision). Make sure not to mix-up the
regular API (sometimes also "API" in short) with the remote
API.
Writing code in and around V-REP |V-REP API framework

The remote API is part of the V-REP API framework. It allows

communication between V-REP and an external application (i.e.
an application running in a different process, or on a different
machine), is cross-platform, and supports service calls (i.e.
blocking calls), and bidirectional data streaming. It comes in
two distinct versions/frameworks:
Writing code in and around V-REP |V-REP API framework

• The B0-based remote API: this represents the second

version of the remote API. It is based on the BlueZero
middleware and its interface plugin to V-REP. It is easier and
more flexible to use than the legacy remote API, and most
importantly, it is easy to extend. It currently supports
following languages: C++, Java, Python, Matlab and Lua.
Writing code in and around V-REP |V-REP API framework

The remote API is part of the V-REP API framework. It allows

communication between V-REP and an external application (i.e.
an application running in a different process, or on a different
machine), is cross-platform, and supports service calls (i.e.
blocking calls), and bidirectional data streaming. It comes in
two distinct versions/frameworks:
Writing code in and around V-REP |V-REP API framework

• The legacy remote API (or simply remote API): this

represents the first version of the remote API. It is
comparatively lightweight and has less dependencies than
the B0-based remote API.

It is however less intuitive and less flexible, and more difficult

to extend. It supports following languages: C/C++, Java, Python,
Matlab, Octave and Lua.
Writing code in and around V-REP |V-REP API framework

There are several ROS interfaces available for V-REP. Each one
offers a specific behaviour, feature, or a way to operate:

• The RosInterface: the RosInterface duplicates the C/C++

ROS API with a good fidelity. This makes it the ideal choice
for very flexible communication via ROS, but might require a
little bit more insight on the various messages and the way
ROS operates.
Writing code in and around V-REP |V-REP API framework

• The ROS plugin skeleton: this represents a skeleton project

that can be used to create a new ROS plugin for V-REP. Make
sure to first have a look at the RosInterface source code before
attempting to edit this project.

• ROS interfaces developed by others: those are not directly

supported by us. For instance, the V-REP ROS bridge.
Writing code in and around V-REP |V-REP API framework

All ROS interfaces can normally operate side-by-side, but we

highly recommend you to first try your hands on the
RosInterface, since this is the most flexible and natural
approach. The packages to the first two above listed ROS
interfaces are located here and here.

Use the catkin tools to build those packages, otherwise you

might run into difficulties.
Writing code in and around V-REP |V-REP API framework

The BlueZero interface is part of the V-REP API framework. It

wraps into a V-REP plugin the BlueZero (BØ) framework. You
can recognize BlueZero API functions from the simB0 prefix.

BØ is a cross-platform middleware which provides tools for

interconnecting pieces of software running in multiple threads,
multiple processes and even multiple machines
Writing code in and around V-REP |V-REP API framework

The auxiliary API is part of the V-REP API framework.

The auxiliary API is not an interface per se, but more a

collection of helper functions that can be embedded into your
own code, and that operate on their own. Following auxiliary
API categories are available:

External kinematics: this is a collection of C++ functions that

offer the same kinematic calculations as can be done within V-
REP
Following Highlight
V-Rep. Presentation no. 13

Simulation