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

More documents

Recommendations

Info

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.
Page 1: ORCA: A physics based, robotics sim
Page 5 and 6: handle all environment processing t

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

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?