ORCA: A physics based, robotics simulator able to distribute ...

ORCA: A physics based, robotics simulator able to
distribute processing across several peers
Hourdakis E 1 ., Chliveros G 1 . and Trahanias P 1,2 .
1 Institute of Computer Science, Foundation for Research and Technology Hellas,
2 University of Crete, Computer Science Department, Hellas
ehourdak@ics.forth.gr, chlivero@ics.forth.gr, trahania@ics.forth.gr
Heraklion, Crete GR70013
Abstract—The nature of the research and development
workflow in robotics has reshaped drastically during the
last decade. Activities are fundamentally interdisciplinary
and usually wide-spread across several research institutions.
To cope with these new requirements, researchers are
increasingly using simulation to communicate algorithmic
developments, and seamlessly integrate their work into
larger projects. In the current paper we present the ORCA
simulator, a versatile 3D-based physics simulator that was
designed to facilitate those needs. ORCA integrates a
middleware backend directly into the server-simulator
environment, making the sharing of resources amongst
peers a seamless task. To this end, we present ORCA’s main
features, its ability to load and render large environments,
as well as the capacity of the simulator to share resources
amongst different workstations.
Index Terms-Robotics, physics, animation, distributed systems
I. INTRODUCTION
Recent advances in hardware, software and sensing
systems, have steered robotics research towards the
development of large-scale integrated systems. Scientists,
instead on focusing on the solution of single problems, are
nowadays required to assimilate their algorithms into
interoperable systems, aimed to deal with complex
problems. Therefore, integration has become a crucial
milestone in the workflow of activities that take place in
any large scale robotics project. The need is also depicted
in several European initiatives, including the Robot
Standards and Reference Architectures (RoSta) [1] and
BRICS – Best Practice in Robotics [2], which have
identified integration as one of the main issues in any
robotics development process.
In this context, an important cornerstone in robotics
research is simulation, which has now become a standard
in most collaborative projects. There are several reasons
for the advent of simulators, including the ability to: (i)
render any robotic platform with very low costs, (ii) make
cost-free modifications on existing robotic configurations,
as well as (iii) share resources amongst researchers and
organizations, to name a few. Most state of the art
simulators can adequately confront the first two issues, by
providing user-friendly interfaces, configurations for
popular robotic platforms, as well as virtual components
to equip the underlying robots, such as sensors, actuators
and controllers.
The requisite for integration is usually covered
indirectly, by providing support for middleware
components, with several being developed in recent years,
including Robot Operating System (ROS) [3], playerstage
[4], OpenRDK [5] and Miro [6]. These libraries
have quickly gained an increased popularity amongst
researchers because they provide an interface to
communicate results across teams or integrate algorithmic
developments into a single robotic platform. However,
due to the fact that they are built on top of software
packages, the functionality that is offered is usually
bounded to communicating only a small set of properties,
i.e. it is not integrated directly into the 3D simulation
environment.
In contrast to all existing software, ORCA (Open
Robot Control Architecture) uses a different approach, in
which a middleware component is built at the core of all
of its software packages. That is, ORCA is equipped with
a dedicated backend, which enables the utilization of the
streams of information produced by a simulation. As a
result of this architecture, it can provide valuable features
to the development workflow of a robotics project,
including environment sharing, distributing resources
across workstations and algorithmic integration.
Moreover, ORCA maximizes the potential of its
architecture to tackle the processing needs of
computationally intensive environments. Computational
costs, especially for large environments are difficult to
handle, despite the increase in computational power or the
use of chipset/multicore based languages such as CUDA
[7] and OpenMP [8]. One of the most popular solutions to
this problem is discretization, i.e. the distribution of
resources amongst different workstations. The ORCA
simulator was designed with this property in mind. It is
based on a 3-tier architecture, consisting of a server
object, client instances and add-on modules. A direct
consequence of this architecture is the ability to share
resources between simulation instances, thus discretizing
and rendering a large environment into smaller sub-parts.
In the current paper, we provide a detailed outline of
the main traits of the ORCA simulator, and describe two
important features: (i) its ability to render virtually
unlimited environments and (ii) share information
amongst simulation instances. The current version of
ORCA is freely available at
http://139.91.185.14/Orca_Release/orca_setup.exe. A
video accompanying the publication, and demonstrates the
environment sharing ability of the ORCA simulator can be
found at http://139.91.185.14/Orca_Release/isrdemo.mp4

Due to their increasing popularity, several simulation
packages have becomee available in the robotics
community, including Gazebo [9], MORSE [10], Webots
[11] and SimRobot [12]. When selecting simulation
software, one
usually evaluates several important factors,
including its
physics processing capabilities, available
robotic platforms, sensor models and packages that it can
support.
Amongst the aforementioned
simulators,
SimRobot and Webots use the Open Dynamics Engine
(ODE) [13] to handle physics processing. MORSE builds
upon Blender’s python API [14], which in turn uses the
Bullet library
[15] for its physics implementation. Finally
Gazebo [9], is an open source simulator that supports
ODE and more recently Bullet.
ORCA (Fig. 1) uses the Newton Dynamics Engine
(NDE) [16], a powerful engine that has recently become
available as open source. One of the main benefits of NDE
is that it allows writing specific behaviors on how physical
entities interact with each
other. Consequently, onee can
define explicit material properties for each object, , and
thus control properties such as collision, friction n and
elasticity.
Figure 1. (left) 3-tier architecture of the ORCA
software package.
The choice of an engine is a matter of context. Several
works have used various
metrics [17] to evaluatee the
properties that affect the quality of physics processingg [18-
20]. Amongst the most important include friction models,
modeling scalability, energy preservation. In [21], the
authors use the Physics Abstraction Layer to carry out an
evaluation of 7 commercial and open-source physics
engines, including ODE and NDE. They present thee two
engines as having similar capacities, with NDE being
more accurate when modeling friction and a rolling contact
events. In [22] the authors present a more thorough
evaluation between the two engines, in which they
undergo a series of tests including bounce, stability of
constraints, energy preservation and gyroscopic force
modeling. Test results indicate, that NDE outperforms
ODE in most
cases.
III.
II. RELATED WORK
ORCA SIMULATION ENVIRONMENT
To facilitate research and development tailed made for
robotics research, we have
designed ORCA based on a 3-
tier architecture. At the core of the software there exists a
server object which is responsible for handlingg all
communication events amongst the different simulation
instances. Each package is
then built on
top of the server
object, and is responsible forr rendering and a sharing a
specific aspect of f the environment. Packagess fall into two
categories: (i) Simulation instances, which are responsiblee
for replicating a specific aspect or structure of the
environment (including objectss and robots) and (ii) add-
ons, which provide some functionality to each simulation
instance. The result of this architecture is that different
simulation instances can process differentt parts of an
environment, andd communicatee concurrently
through the
server object. Inn addition, with the use of add-ons,
researchers can augment a an existing project with new
functionalities using an I/O convention. In the following
section we outline in detail the functionality of each
component in the ORCA package.
A. Orca Server
All communication between simulator instances is
handled through a network protocol that supports a great
variety of messages and control commands. Packages are
broadcast in a designated d listening port by the serverr
either on demand, by publishing a message when
available, or in a timely manner, where a package is
posted on regular intervals. Client modules produce
packages either:
As a result of a specific event (e.g. a module attached to
a motion sensor produces a package when motion is
detected).
Periodically (e. g. a module attached to a laser scanner
produces a neww frame at regular intervals).
As a result off incoming data (e.g. a text-generatort
r
module produces annotated text for an exhibit, each
time new text iss created).
When a requestt is received (e.g. a server, attached to a
high-resolution
camera, that produces frames containing
camera images only afterr an explicit request is
received).
Network
communication
is accomplished
by
publishing packages to the server. Communications are
organized in a “producer-con“
nsumer” basis. That is, alll
pieces of information that needd to be exchanged between
modules are organized into packets (categories) and each
packet is assignedd a different code (packet code). c Packets
and their codes are a defined according to the application,
and are stored in a configuration file. The communicationn
server reads the configuration
c
file and for each e different
packet code, the server creates two lists:
the list of connections c (modules) thatt produce this
particular packet (producers), and
the list of connections (modules) that consume this
particular packet (consumers).
The server object is responsible for regulating r the
TCP/IP bandwidth amongst t the different software
components. When running, each instance registers and
can then publishh information n throughout the network.
When the serverr receives a package from a specificc
connection, it reads the contents of the data field and
expects to find a string and two lists of integers. Thesee
lists correspond to the codess of the packets that are

produced and
consumed respectively by
the module at the
other side of
the connection. For each listed l packet code,
the server accordingly updates its
corresponding
“producers” and “consumers” lists. When a module
disconnects from the server, the latter erases all references
to the corresponding connection from
the “consumers”
and the “producers” lists of all packages and terminates
the corresponding connection thread.
Currently
ORCA supports more than
100 TCP/IPP type
packet messages that pertain to information about control
commands, sensor information, physicss related data, HRI
interface commands and object handling messages. In
addition,
ORCA provides
templates for client
redistributables for Java, ANSI C++ and
C. Consequently,
through the server communication protocol, one cann run
instances of
a simulation on any machine, including
Windows and Linux, and
use the server to handle their
interaction.
More importantly, the communication protocol can be
easily extended using a text-based structure. The server
object scanss a set of predefined directories upon
initialization and registers new messages as required.
Therein we demonstrate how ORCA’ s protocol can be
used to share
information processed by one instance of the
physics simulation to other instances, thus t allowing it to
tackle the computational
needs of a simulation, s despite
them being intensive.
B. Simulator
ORCA includes several features which enable
developers to
generate new world scenarios seamlessly,
without requiring advanced computer skills. Rendering,
handled by OpenGL, and physics processing, by NDE, are
coupled together through a tree-based
hierarchy, called
environment tree, which can be setup using configuration
files. Currently, ORCA’s environment tree supports the
insertion of (i) objects, (ii) kinematicc constraints, (iii)
sensor, (iv) robot models and (v) interaction behaviors.
Object definition
Upon initialization the simulator loads an environment
file, which contains the definitions and physics properties
of each object. Several different types of objectss are
supported, including (i) primitive geometries (cube,
polygon, capsule and triangles), (ii) containers, that bundle
entities together, as well as (iii) freeform objects, which
allow importing meshes from CAD software directlyy into
a simulated world (ORCA
supports thee .obj format, used
by several modeling packages, including Blender).
Through the
NDE physics engine, ORCA providess the
largest number of primitive objects than
any other engine.
In addition, it supports the definition of extrude objects,
i.e. abstract geometries defined by a series s of 3D point
edges, as well as various light sources.
Mesh and boundary
informationn are generated
automatically
for each object that is inserted inn the
simulation environment. In
addition, one has the choice of
selecting what type of bounding boxes will be generated
from each object entered into the world. Additional
options include the initial position of an object, orientation
vectors, object materials, m whether it will be subject to
gravitational forces, its mass and density.
Kinematic Constraints
ORCA also supports the definition of various different
types of constraints, which can be used to limit the
movement of kinematic structures in one or more axes.
These are also specified s upon initialization, using the
environment tree hierarchy, andd can be used to restrict the
motion of a body in relation to o another. Currently various
different types of constraints are supported, including i ball,
hinge and socket joints. ORCAA exports all the properties
supported by the physics engine, type and stiffness of the
joint, pivot points and transformation axis, as well as
acceleration bounds.
Sensor models
Most robots have h a large number of mounted sensors.
These can be modeled accurately for a simulator that is
intended for research based purposes. ORCA
has a great
variety of sensor models available, which can be inserted
directly into its environment e tree. Currently it supportss
sensor objects, used to monitor the forces that different
geometries exert upon each other, bumping sensors,
responsible for detecting the collision among objects, as
welll as virtual cameras, that simulate a scene using RGB
and depth data (Fig. 2). The simulator also
supports the
definition of extrinsic and intrinsic camera parameters, as
welll as specific camera models including
the Kinect
RGBD, PointGrey and Logitech Quickcam Pro 50000
camera.
Each sensor model can be easily inserted to a
simulation, by defining a set of initial parameters. For
cameras,
available
properties
include the image
width/height and pixel per unit, model parameters for
distortion and noise, as well as intrinsic and extrinsic
parameters. To facilitate the realistic simulation we have
also incorporatedd appropriate sampling rates for each
sensor, which can be specified upon initialization.
Figure 2. Client output produced from ORCA’s RGBD simulated
sensor.
In addition, ORCA supportss range objectt sensors, such
as laser and sonar. Available parameters forr these objects
include the number of measurements at each time step, the
minimum and maximum radius of the range sensors, as
welll as noise models m relative to the distance of the
measurement.

Robot models
Using the aforementioned threee components, a
developer can instantiate any type of f robotic platform.
However, ORCA comes with a number of pre-defined
structures for
some popular robots (Fig. 3), includingng the
Pioneer 3-AT
platform, the iRobot3ADm, the Kuka LWR
and a generic
hand and arm
model with 27-DoF.
national projects. As a result of f these projects, the package
was extended to include severall add-ons.
The first class of add-ons regards human-robot
communication technologies t
(Fig. 4). These include
components for natural n language interaction and virtual
emotions, as well as HRI interfaces for human-robot
interaction.
Figure 3. (left)
The simulated
iRobotB21R. (right) The simulated
Pioneer 3-AT platform.
In addition, we are working towards including other
platforms, such as the NAO and Hoap3 humanoids, the
Kuka mobile
platform and
the PR2 robot. These will be
made available upon ORCA’s next major release, andd will
be optimized
to reflect the physical properties of the actual
hardware robotic platforms.
Interaction Behaviors
One of the main benefits of ORCA
is that it defines
explicitly how objects and physical entities will interact
with each other. This is supported through NDE’s ability
to define explicit materials on each object. Properties of
the interaction include the
use of gravity, collision mode,
convex collision tolerance, net force limit, linear
damping, translation and rotational impulse velocity.
Moreover, each behavior can be set to run based on
different collision primitives, be it mesh, or primitive
bounding boxes, and can
assign different mass, density
values to interacting objects. Finally, torque and
collision estimation can be performed
locally for each
behavior, through the implementation of appropriate
callback functions.
One important benefit from this feature is that it gives
complete control on the physical representation of objects
in the world. One can use it to describe how different
materials will interact together, and as a a result define
explicitly cross-object interactions, instead of describing
a set of simple physics properties, as it i is the case with
other simulators. One important result from this feature,
is that one can turn off and on the physics processing of
an object on demand, by freeing its assigned behaviors at
any time, thus improving the speed of simulationn by
eliminating redundant entities. In the video that
accompanies
the publication we demonstrate an example
in which we
make use of this property, to segment the
physics processing of a simulation environment into
different workstations.
C. Add-ons
ORCA has already been used in a large number of
national and
international projects, ncluding the EC-
running FP7
project FIRST-MM, ass well as several
funded FP6 projects GNOSYS and INDIGO, the currently
Figure 4. Add-ons developed for project purposes. (left) Speech
synthesis module (right) HRI interface for robot control through a
touchscreen.
More specifically, this family of add-ons for synthesizing speech
and phrases, simply by typingg in the desired text, (ii) a
includes
threee modules; (i)) an application
virtual emotion module, m whichh provides an
interface for
drawing 2D template faces from standard emotions and
(iii) a GUI interface that allows humans to t control the
robots by typing on o a touch screen.
The second class of add-ons that have been developedd
pertains to locomotion modules. More specifically, ORCA
includes specific controllers that enable mobile robots to
perform localization, obstacle avoidance, and a mapping.
These modules, despite running in their own instance,
interact with ORCA’s server communication system, in
order to read sensor measurements and dispatch control
commands to the robots being simulated (Fig. 5).
Figure 5. Mapping and localization add-ons developed for project
purposes.
Finally, ORCAA is currently being expanded in the FP7
project FIRST-MM, which aims at developing novel
components for mobile m manipulation. In the course of the
project, ORCA is being extended to includee visual object
tracking modules, as well as additional components thatt
allow
for instructing robots to perform guidance, delivery
and transportationn tasks.
IV
. RESOURCE SHARING
One of the strong benefits of ORCA iss its ability to
share resources amongst different simulation
instances. To
cope
with this requirement, ORCA has been
designed to

handle all environment processing through its server
object. Consequently it can
tackle the large computational
costs that are
inherent in complex robotic structuress and
large environments, by sharing and distributing resources
across simulation
instances.
This functionalityy
is
embodied through threee different properties in n the
simulator’s environment: (i) robot
sharing, (ii)
environment sharing, (iii) object sharing. Thesee are
outlined below.
A. Robot sharing
One of the main characteristics of a simulated robot is
that it utilizes resources that are modular, and can be
described by
an I/O convention. Consequently, in most
cases, rendering a simulated robot is a computationally
intensive task
that outputs only a small set s of parameters.
Consider for example the case where a “high degrees
of freedom” manipulator has to be processed within a
large environment. At any
given time, the simulatorr has
the duty to process its kinematic chain, integratee the
appropriate equations, and
update the position of the joints
of the hand
to simulate it. Even though this process
contains a large number of
computations, it is only used to
output a small amount of
information, , such as the end-
with such a robot, it is usually important to have onlyy this
point location
of the hand. Consequently, when interacting
piece of information available. Due to its design, ORCA
can facilitate
processing of
such roboticc structures locally,
and distribute outputs from the simulation on demand,
only when required (Fig. 6).
simulation environments or being transmitted by the
server.
B. Environment sharing
Another important feature of the ORCA
simulator is
its ability to share the processing requirements of large
environments. Such feature is becoming increasingly
important across research projects, and finds applications
in a large number of fields including outdoor robotics,
search and rescue simulations, swarm robots etc.
In these typess of environments, usually
the robot is
located within a small manifold space, which must
process. Upon initialization off an experiment, the serverr
loads a virtual world file whichh contains the definitions of
all objects that will be processed by simulation instances.
These are createdd as physical entities and entered into the
world without processing any of their properties (Fig. 7).
Figure 7. (right) The environment-sharing view of thee server showing
how different robots are being processed using different subsets of an
environment. (left) Rendered with redd is robot 1, green robot 2, while
transparently are rendered the surroundings that are not n processed by
any robot.
As soon as a new simulation instance is i loaded into
the new world, it communicates its location to the server.
The
server responds to the request of thee instance by
transmitting the environment and object properties thatt
are in the vicinityy of the roboticc client (Fig. 8).
Figure 6. The environment-sharing view of thee server showingg how
different robots are being processed using ORCA’s virtual robots. The
simulation instances transmit all required infromation to a server, which
for the given example, reduces the robot’s existence to a spatial x, y, z
vector.
To facilitate this feature, the latest ORCA release
includes an extensive network protocol that contains
messages pertaining to information sharing amongst
robots. Thesee messages are integrated within appropriate
environment parsers, thatt reside on the server andd are
responsible for filtering and transmitting to simulation
instances only the appropriate environment information.
In addition, the latest release uses virtual robots, simple
graphic structures with no physical properties, that can be
used to visualize information coming from other
Figure 8. Local copy of o the simulator that receives onlyy a partial view of
the environment.

As a result, ORCA is able to render r very large
environments, by segmenting
their t processing
requirements
into smaller
subspaces. The shared
properties of an environment can be configured easily
through the server’s environment initialization file, which
allows objects to be loaded having different sharing
properties.
C. Object sharing
Further to the above, an importantt feature thatt was
implemented
to augment the environment sharing feature
is object sharing. ORCA
utilizes the flexibility off the
NDE engine to limit the processing done to single objects.
More specifically, by configuring its environment file,
ORCA allows a developer
to transfer the processing of an
object into a remote simulation instance.
When a simulation instance receives a certain set of
published properties, it has the ability to render them
statically, i.e. without considering the object geometries,
physical properties and mesh information, or loadd the
object in its own right, and only embed the published
properties provided by the server (Fig. 9).
Figure 9. Sharing object properties through simulation instances. The
simulation instance on the left manipulates thee cube while thee right
instance only receives some published properties.
This feature becomes
particularly
important when
sharing environments that are cluttered with many objects.
In this case the server provides the ability to publish
specific object properties, which can then be shared across
simulation instances.
Through this feature, the processing requirements of
very large environments can be distributed across different
simulation instances. Different aspects/objects within an
environment can be setup
to be processed by different
simulation instances, and
then communicated wherever
required by the server.
V.
CONCLUSIONN AND FUTURE
WORK
Simulation is becoming a popularr approach inn the
robotics community, due to its ability to provide a costfree
alternative to actual hardware robotic modeling. Most
simulators have addressedd this need by providing a single
workspace package, able to render competently a robotic
structure. However, one important feature that wass left
unaddressed to date, was the provision of features related
to sharing environments.
Even though popular
middleware solutions, such as ROS, offer the ability to
publish certain features of a robot, these are not integrated
directly into the simulation environment, and a have thus
limited capabilities. ORCA overcomes thiss problem by
integrating its middleware m component directly into the
simulator. As a result, it offers extensive features, such as
environment and object sharingg and distributes processing
to different workstations.
In the future, we plan to extend the functionality of
cross-platform sharing, by introducing additional tools for
this purpose. These will pertain to the development of
simulated
sharing
components,
port sharing and
publishing. In addition we plann to introduce modules thatt
will enable developers to optimize the performance of a
simulated robot byy plugging in the actual robotic hardware
that must be simulated. ORCA will provide several
optimization algorithms, whichh will be used to reduce the
gap between actual and simulated platforms.
ACKNOWLEDGEMENTS
This
work is partially p supported by the European
Commision under contract number FP7-248258 (First-
MMM project).
REFERENCES
[1]
[2]
[3]
[4]
[5]
[6]
[7]
RoSta - http:// /www.robot-standards.org/index.php?id=8
BRICS - http: ://www.best-of-robotics.org/
System – ROS: http://www.ros.org/
Player-Stage project p - http://playerstage.sourceforge.net/
OpenRDK - http://openrdk.sh
sourceforge.net/ /
Robot Operating
Miro - http://miro-middleware.berlios.de/
CUDA
http://www.nvidia.com/object/cuda_home_
_new.html
-
[8] OpenMP - http://openmp.org/wp/
[9] N. Koenig and a A. Howard (2004). Design and use
paradigms for f Gazebo, an open-source multi-robott
simulator. In In IEEE/RSJ Int. Conf. on Intelligent Robots
and Systems, pp. 2149–21544
[10] Echeverria et al. (2011), Modular open robots simulation
engine: MORSE
[11] O. Michel (2004).(
Webots: Professionall mobile robot
simulation. Journal of Advanced Roboticss Systems 1(1):
39–42.
[12] Laue et al. (2004), SimRobot – A general physical robot
simulator andd its application in RoboCup
[13]
[14]
[15]
[16]
Open Dynamics Engine http: ://www.ode.org/
Blender http:/ //www.blender.org/
Bullet http://bulletphysics.org/wordpress/
Newton Gamee Dynamics http://newtondynamics.com/
[17] Canny Johnn Mirtich Brian. (1995)
simulation of rigid bodies
Impuled-basedd
[18] Hecker Chriss Lander Jeff. Product Review of Physicss
Engines, Part One:The Stress Test. Technical report,
2000.
[19] Hecker Chriss Lander Jeff. (2000) Product Review of
Physics Engines, Part Two. Technical report
[20] Axel Seugling and Martin Rolin, (2006), Evaluation of
Physics Engines and Implementation of a Physics Module
in a 3d-Authoring Tool, Master Thesis
[21] Boeing, Andrian and Brunl, Thomas (2010), Evaluation of
real-time physics simulationn systems, ACM
Int. conf. on
Comp. Graphics and Interactive techniques, pp. 281-288
[22] S. Balakirsky et al. (2011). From simulationn to real robots
with predictable results: methods and examples, In:
Madhavan et al. (eds), Performance evaluation e and
benchmarkingg of intelligent systems