A Simulation Environment for Robot Motion Planning A. Ettlin, P. B¨ uchler University of Applied Sciences of Central Switzerland CH-6048 Horw, Switzerland {aettlin, pbuechler}@hta.fhz.ch Tel.: +41 41 349 33 61 Fax: +41 41 349 39 59 Abstract We introduce Ibex, a real-time capable physics simulation framework. Ibex is ideally suited to simulate mechatronic systems as well as environments in which robot motion planning algorithms can be developed and tested. The entire control loop encountered in robotics can be simulated. This includes the simulation of robot sensors and actuators. The current implementation includes a rigid-body simulation which encompasses not only kinematic but also dynamics effects. It performs collision detection and resolution in real-time or faster for typical setups. The completely modular design of Ibex means the framework is easily configurable and extensible. Additional physics simulation modules covering phenomena such as electromagnetic forces can be integrated transparently. These modules can interact with existing entities to build an overall system. Ibex can communicate with external hardware through I/O interfaces, thus allowing hardware-in-theloop simulations. We present example Ibex applications from both industrial and mobile robotics. We also describe why Ibex is a real asset for robot motion planning and how we intend to apply it in this field.
1
Introduction
We have designed and implemented a comprehensive simulation framework for mechatronic environments. For typical macroscopic robotics applications, objects in the world are simulated as rigid body geometries. The simulation includes not only kinematic aspects but also full rigid-body dynamics. Collision detection and resolution is performed between the bodies. Joints can be specified to link objects and constrain the degrees of freedom of the objects’ relative motion. With
H. Bleuler Swiss Federal Institute of Technology, Lausanne (EPFL) CH-1015 Lausanne, Switzerland
[email protected]
the computational power of a standard PC the simulation can be run in real-time or even faster for typical setups. We have provided abstractions for simulating both sensors and actuators which can be implemented to emulate the specific behaviour of their real-world counterparts. Ibex includes an interface to external hardware devices that can be connected to perform hardware-in-the-loop (HIL) simulations. The modular design of the software package allows a tailored composition of the simulation application program. The extension of Ibex is thus also a comparatively simple task. New functionality, including additional physics modules, such as electromagnetic field simulations, can be added to extend the scope of the framework.
2
Motivation
The advantages of using a simulation framework like Ibex for robot motion planning are manifold: • Within the limitations of the system, any arbitrary world can be created. The effort of testing robot behaviour in a real world is considerably higher than running the equivalent experiments in a simulated environment. • The initial conditions of our deterministic simulation can be accurately recreated, thus ensuring a consistent environmental behaviour. Especially when testing motion planning algorithms or comparing various such approaches this is a significant advantage. • The training phase of behavioural algorithms based on learning techniques can be considerably shortened with a faster-than real-time simulation.
• Large numbers of automatically generated randomised test cases can help discover and overcome design weaknesses. • Deploying insufficiently tested control algorithms on real hardware can cause important damage if errors occur. The use of a simulation environment can significantly reduce such risks if used during early testing. Naturally, no simulation environment can ever replace the real world for comprehensive testing, but a balanced combination of simulated experiments and experiments in the real world increases efficiency by combining the advantages of both approaches.
3 3.1
Architecture Overview
The Ibex framework is designed to be completely modular. Adhering to good software engineering practice we have strived to achieve a high degree of cohesion within modules combined with a low level of intermodular coupling. Following this structural guideline we have defined the abstract functionality of the software modules which compose the overall system. Since every implementation of the abstractions offers the specified functionality, an Ibex-based application is designed in terms of functionality and not any specific technology. While fulfilling the same functionality, the implementations of one module abstraction still differ in some of their characteristics. When assembling an application in terms of implementation modules, the most appropriate ones can be selected. It is also possible to include multiple implementations of the same logical functionality and leave the choice of which one to use to the user, at run-time. Figure 1 shows a high level overview of the Ibex software architecture. In the diagram the lowest layer represents the simulation application which uses the Ibex framework. This part is the only application specific program code. The contents of the simulation (geometries, scene setups, artwork where desired) are naturally also application specific, everything else is provided by the Ibex framework. In Figure 1 the boxes shaded dark gray represent the parts outside Ibex. The application program interacts with the Ibex API which provides an interface to the entire functionality of the framework and can be regarded as a form of middleware.
Figure 1: High-level architectural overview of Ibex.
3.2
System
We call the sum of all entities being simulated a system. In particular, the system contains all subsystems. Central simulation management tasks are performed on the system in our framework.
3.3
Subsystem
In Ibex, a subsystem encapsulates one particular unit of simulation. Each subsystem abstraction provides a well-defined interface to the functionality it represents. For example a rigid-body dynamics module abstraction provides a functionality interface, which is complied with by all specific implementations thereof, e.g. the NovodeX rigid body dynamics module introduced in section 4.1. In a simple case, only one subsystem is created for each simulation. If more than one subsystem is used, Ibex provides a mechanism we call Links for intersubsystem communication. A link specifies an interface in terms of objects and object properties which are synchronised for both connected subsystems. Possible reasons for creating multiple subsystems are listed below: • Functionality: If more than one type of simulation is required, multiple subsystems can be created that comprise all phenomena to be simulated. One example is a situation where a rigidbody dynamics simulation (first subsystem) is complemented by an electromagnetic field simulation (second subsystem). • Dimensionality: Numerical simulations tend to
provide satisfactory results only within some orders of magnitude of a critical unit. For example a rigid-body dynamics simulation only is accurate for objects of similar size and mass, the degree of similarity required depending on the particular implementation. In such a case, multiple subsystems of the same type at different dimensions can be created to simulate the overall setup. • Parallelisation: Another reason for splitting up a simulation is load-balancing. In situations where subsections of the entire setup are relatively independent, i.e. the bandwidth requirements for intercommunication can be met, a better overall performance can be achieved by parallelising the simulation in such a high-level manner.
3.4
Observers
Observers provide functionality to inspect the contents of a simulation. At present we distinguish two major types of observer: graphical and textual. A graphical observer is based on a 3D graphics engine that visualises the simulation at run-time. It is ideally suited to give a simulation user an overview of the simulation state. A wide selection of visual effects can be used to provide additional information or enhance the appeal of a visualisation. The Ibex 3D graphics observer abstraction includes the functionality to represent previous states of objects as traces and visualise the exact contact points and normals when collisions occur. However, text-based observers are better suited for close inspection of simulation details. Textual observers have full access to all simulation data which can be displayed in a spreadsheet-style data grid and exported for further analysis with external tools like MATLAB. The modular architecture of Ibex makes it a relatively simple task to create remote observers which run on another computer than the actual simulation. Ibex applications with a distributed architecture using a dedicated simulation server can also easily be designed.
3.5
Sensors and Actuators
Sensors and actuators are abstractions logically contained within a subsystem. They specify a generic interface which can be implemented to simulate a wide range of mechatronic sensors and actuators. For simulating many kinds of range-finding sensors, ray-casting techniques can be applied to the geometries in a rigid-body simulation.
In the case of actuators, the low-level controller is also included in the functionality. For example, an electric motor might take a given input current and translate it to a torque applied to the scene by means of some characteristic curve. The properties of a sensor or actuator are specified in their implementation.
4
Implementation
In this section the implementations of our rigid-body dynamics simulation and one of the 3D graphics observers are briefly discussed. The entire framework is programmed in C++.
4.1
NovodeX Rigid Body Dynamics
For rigid body dynamics simulation we use the NovodeX simulation libraries [10]. These libraries provide state-of-the-art performance in their category. NovodeX provides linear-time behaviour with the number of simulated objects for rigid-body dynamics, collision detection and collision resolution. Collision shapes include any combination of primitives (spheres, boxes and capsules - a cylinder with two hemispheres attached to the ends) and arbitrary triangulated mesh shapes. A number of predefined joint types are available as well as a customisable generic joint where limits on degrees-of-freedom and motion ranges can be specified.
4.2
Irrlicht 3D Graphics Observer
The graphical observer based on Irrlicht [6] was the first one included in our framework and relies exclusively on open-source software. While still in development this graphics engine provides a number of computer graphics techniques like texturing, transparency and dynamic lighting which allow clear and intuitive visualisations of a simulation. The graphics engine is platform-independent and runs with either Direct3D, OpenGL or a native software renderer. A major benefit is the well-designed interface and the ease of use of Irrlicht. Figures 5 and 6 are screen-shots taken from the Irrlicht graphics observer.
5
Examples
We present two example applications of Ibex in robotics. The first one is the simulation of an industrial pick-and-place robot with a parallel-kinematic
structure. The second one is a small technology demonstration in the form of a fictitious tracked vehicle.
5.1
Industrial Robotics
In cooperation with the Swiss Center for Electronics and Microtechnology (CSEM) we have developed a simulator for the MicroDelta robot developed at CSEM [2]. The MicroDelta is a small and fast highprecision Delta robot [1]. It has a parallel-kinematic structure with three translational degrees of freedom. The structure consists of a closed loop mechanism with three chains of two links each. The chains are attached to a static frame parallel to the working surface. Each of the chains has a revolute joint at the “shoulder” position, actuated by an electric motor fixed to the static frame. The ends (“hands”) of the arms are joined at a travelling plate where tools like a gripper can be attached. A structure consisting of two parallel rods connects the “elbow” and “hand” of each arm. At each end, the parallel rods are attached to an axis parallel to the “shoulder” joint by a revolute joint. This structure ensures that the toolhead always remains parallel to the working surface. Figure 2 shows the MicroDelta robot. A visualisation of the MicroDelta robot as displayed in an Ibex graphical observer during a simulation can be seen in Figure 3. The setup of joints at the toolhead is depicted in Figure 4.
Figure 2: A prototype of the real MicroDelta robot. For the project we have connected the control algorithms which are used with the real MicroDelta to the Ibex simulation. The external controller communicates with our framework at a frequency of 2 kHz. The control software typically runs on the same computer as the simulation but we have also experimented with setups where a TCP/IP connection is used for communication between the two entities.
Figure 3: Ibex graphical observer displaying a MicroDelta robot being simulated.
Figure 4: MicroDelta tool-tip structure in the simulation showing the construction of joints. The notion of an external control unit can easily be extended to that of a hardware-in-the-loop simulation (HILS). In the typical control loop encountered in robotics, a control unit consisting of computer hardware running the high-level control algorithms receives data gathered by sensors from the environment in which the robot operates. Based on this data, the motion-planning logic issues commands to the lowlevel controllers, which in turn control the actuators. The forces generated by the actuators lead to changes in the configuration of the robot and its environment. These changes are perceived by the sensors, thus closing the loop. In a HIL simulation, the mechanical robot hardware, its environment, as well as the sensors and actuators are all simulated in real-time. The control algorithms running on their native hardware are connected to the simulation and communicate with it as if it were the real environment. This setup allows to test the control algorithms in a far more versatile and complete way than in the real world.
5.2
Mobile Robotics
To demonstrate the rigid-body dynamics, collision detection and collision resolution capabilities of our framework, we have implemented a simulation which contains a tracked vehicle operating in rough terrain. The vehicle includes four powered wheels per side. They transmit the propulsive power to a track consisting of fifty rigid track elements connected by revolute joints. A wire-mesh representation of one of the tracks during a simulation can be seen in Figure 5.
Figure 5: Track of a fictitious vehicle simulated in Ibex. The underground is modelled as a polygonal approximation of a rough terrain. The entire vehicle moving on the terrain is depicted in Figure 6.
6
Future Work
We intend to expand our activities in the robot motion planning domain by researching algorithms which benefit from the Ibex simulation framework. On the one hand, we plan to use Ibex for simulating the worlds in which our planning algorithms operate. On the other hand, our intention is to extend existing motion planning algorithms and develop new ones based on existing approaches which consider following aspects: • Rigid-body dynamics: While all but the most basic motion planning algorithms take into account the kinematics of the robot and its surroundings, kinodynamic motion planning [3] is not yet as widespread. The problem has been tackled e.g. by [9], [8]. We also intend to include dynamic effects at a level of interactions between rigid-body objects in the environment, not merely limits of the controlled robot’s hardware. • Planning under uncertainty: In the real world, uncertainties significantly influence robot motion planning [5]. Uncertainties arise among other things from sensor errors, unknown factors in the robot hardware, path-following errors or insufficient initial data about the environment. In the potentially perfect world of a simulation they must be taken into account accordingly. A simulation can prove to be ideal in this respect since full control over the uncertainties can be obtained and its effects on the planning algorithms studied. • Continuous static obstacle definitions: Many motion planning approaches assume a binary definition of free space and static obstacles. It is often not possible to achieve a mapping from potentially uncertain environment data to such a discrete static obstacle representation [5]. Having a full rigid body dynamics simulation at our disposal we intend to use a continuous static obstacle definition to produce more robust motion planning algorithms.
Figure 6: Tracked vehicle operating on polygonal terrain approximation. Importantly, different physical material properties can be assigned to each polygon face of the terrain. This allows to precisely model local dynamic interactions with the underground. The same technique can be extended to all polygon-based objects in the simulated scene.
• Dynamic obstacles: Apart from the static obstacles mentioned above we plan to include dynamic obstacles in our integrated motion planner, as in e.g. [7]. Since the motion of objects not controlled by the planning algorithms cannot be accurately predicted, a probabilistic approach is intended for estimating future configurations of dynamic obstacles. • Configurable performance criteria: Depending on the circumstances and the task at hand, a differ-
ent motion plan can be considered optimal. We intend to support multiple performance criteria as proposed in [4].
7
Conclusion
Great advantages can be achieved in robot motion planning by making use of a real-time capable simulation environment like Ibex. Real-time performance means that the complete control loop encountered in robotics can be simulated as hardware-in-the-loop simulation. This makes more systematic and complete testing possible compared to testing in the real world. The Ibex framework is capable of running faster than real-time depending on the complexity of the scene and the available computing power. The NovodeX rigid-body dynamics module implementation displays a linear behaviour with increasing number of objects in the scene. This makes faster than real-time operation possible, even for relatively complex scenes. For behavioural algorithms which require a training phase, the amount of time required for learning can thus be significantly reduced. We intend to take full advantage of the Ibex simulation framework to develop motion planning algorithms which take into account kinodynamic effects, uncertainties in the data used to take decisions, a continuous obstacle formalism and dynamic obstacles. Additionally we plan to support configurable criteria as basis for the performance optimisation of the motion plan. To tackle these issues, we are convinced to have a well suited basis with the Ibex framework. We hope to be able to provide valuable contributions to the field of robot motion planning with it in the near future.
References [1] Reymond Clavel. Delta, a fast robot with parallel geometry. In Proceedings of the 18th International Symposium on Industrial Robots, pages 91–100, 1988. [2] A. Codourey, A. Steinecker, B. Sprenger, M. Honegger, M. Thurner, A.-C. Pliska, U. Gubler, and C. Bosshard. A flexible desktop robotic system and dedicated tools for delicate tasks in microassembly. Technical report, CSEM, MechRob Special Session, 2004. [3] Bruce Randall Donald, Patrick G. Xavier, John F. Canny, and John H. Reif. Kinodynamic motion planning. ACM, 40(5):1048–1066, 1993. [4] Y. Guo, L. E. Parker, D. L. Jung, and Z. Dong. Performance-based rough terrain navigation for nonholonomic mobile robots. In The 29th Annual Conference of the IEEE Industrial Electronics Society (IECON’03), page 2811, November 2003. [5] Karl Iagnemma, Frank G´enot, and Steven Dubowsky. Rapid physics-based rough-terrain rover planning with sensor and control uncertainty. In IEEE International Conference on Robotics and Automation, volume 3, pages 2286– 2291. IEEE Robotics and Automation Society, May 1999. [6] Irrlicht. http://irrlicht.sourceforge.net/. [7] B. Jensen, R. Philippsen, and R. Siegwart. Motion detection and path planning in dynamic environments. In Workshop Proceedings Reasoning with Uncertainty in Robotics, International Joint Conference on Artificial Intelligence IJCAI’03, 2003. [8] Marin Kobilarov and Gaurav S. Sukhatme. Time optimal path planning on outdoor terrain for mobile robots under dynamic constraints. unpublished research paper from the USC Center for Robotics and Embedded Systems lab, 2004. [9] S. M. LaValle and J. J. Kuffner. Randomized kinodynamic planning. In Proceedings IEEE International Conference on Robotics and Automation, pages 473–479, 1999. [10] NovodeX. http://www.novodex.com/.
