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