Flexible XML-based configuration of physical simulations

Transcription

1 SOFTWARE PRACTICE AND EXPERIENCE Softw. Pract. Exper. 2004; 34: (DOI: /spe.606) Flexible XML-based configuration of physical simulations R. M. Sunderland, R. I. Damper, and R. M. Crowder School of Electronics and Computer Science, University of Southampton, Southampton SO17 1BJ, U.K. SUMMARY The extensible markup language XML can be used to support the integration of several component programming environments to create a flexible physical simulation system. Data exchange via openstandard-based plain text files allows system components to be loosely-coupled, rather than combined into an integrated development environment, so that the most appropriate tools can be used for each component and the system can be extended with minimal disruption. This paper details an example application using this technology to configure a simulation of robotic manipulation. Those parts of the system that require real-time data exchange use simple UNIX socket-based interactions, which are configured using shared XML setup files. The approach provides a reusable template for other, similar projects. Copyright c 2004 John Wiley & Sons, Ltd. KEY WORDS: XML; robotics; simulation of physical systems INTRODUCTION Although originally designed for large-scale electronic publishing, the extensible markup language XML has found a role in supporting the exchange of a wide variety of data on the Web and in other software systems [1]. We describe an illustrative use of XML to integrate several components for the simulation of a robotic manipulator handling various passive objects (e.g. cube, ball). The flexibility of XML means that this approach is equally applicable to other physical simulations where there is a need to describe complex mechanical artifacts incorporating a wide range of actuators, like mobile cranes and walking robots. Such artifacts have two features that lend themselves well to XML descriptions: hierarchical structure and large numbers of parameters. Although it would be possible to describe a manipulator Correspondence to: R. I. Damper, School of Electronics and Computer Science, University of Southampton, Southampton SO17 1BJ, U.K. rid@ecs.soton.ac.uk Published online 15 June 2004 Copyright c 2004 John Wiley & Sons, Ltd. Received 20 June 2003 Revised 21 November 2003 Accepted 16 February 2004

2 1150 R. M. SUNDERLAND, R. I. DAMPER AND R. M. CROWDER as a single list of joints, body parts, sensors and actuators, such a list would have to be augmented by considerable extra information defining how these elements are interconnected. Also, this information would have to be checked and corrected whenever the structure was modified. More generally, robotic simulations require a large number of parameters, which need to be stored in a standardized machine-readable way. XML provides a means by which these data can be hierarchically structured, clearly linked to the objects described, and easily coupled with metadata that add physical units (e.g. millimetres, newtons) and labels where required. In our approach, the XML description includes the complete mechanical structure and its environment, together with the actuators and their parameters, and the tactile sensors that interact with the environment. SYSTEM COMPONENTS In this work, we aim to simulate the accurate, real-time dynamics of physical hardware (e.g. a manipulator), with a requirement for flexible and intelligent control actions. Also, to decrease development time, we want to minimize the amount of bespoke code by exploiting proprietary commercial software. There are two basic ways to achieve these aims. We could either build our application on top of an existing generic simulation engine (like ODE [2] orvortex[3]) or adapt an existing robotic simulation environment (like Gazebo [4], OpenSim [5] ordynamechs[6]) to our purposes. We have chosen the former approach because existing simulation environments are either tailored to tasks other than our intended application of manipulation, such as walking and/or navigation, or are currently under-developed. One exception to this generalization is GraspIt! [7], which is intended for simulating manipulation. However, it requires the specification of a kinematic mathematical model of the system to be simulated, which we prefer to avoid since our philosophy is the biologically-inspired one of learning about the plant from its interaction with the physical world [8,9]. We therefore need a framework that can couple together our application-specific software and the underlying simulation engine with minimal effort. We have chosen Vortex as the simulation engine since it is a very capable package for modelling physical dynamics and collisions between solid objects. Vortex has extensive documentation and is easily integrated with other libraries to create powerful simulation programs. It is supplied with a lightweight OpenGL/DirectX viewer that was more than adequate for this work. Figure 1 shows a block diagram of the overall simulation environment. The commercial packages used Vortex Simulation Libraries [3] and MATLAB [10] are integratedwith a bespoke C++ object hierarchy that mirrors the manipulator structure, with Python [11] used for scripting. MATLAB is the industry standard package for rapid mathematical algorithm prototyping, especially for control applications. Python has been chosen because it facilitates clear readable code through its modular name-spacing and rigid source code layout. It already has well-developed support for XML parsing and generation and so was easy to integrate into the system. SOCKET INTERFACE A separate Vortex-based client was developed that would execute the physical simulation while interacting with a MATLAB-driven controller via a UNIX-socket. MATLAB provides a direct C interface, via late-linked, pre-compiled binary files (so called MEX-files ). These files have access to the MATLAB work space and share its file descriptors. Note that the file descriptor numbers provided

3 FLEXIBLE XML-BASED CONFIGURATION OF PHYSICAL SIMULATIONS 1151 Figure 1. The simulation environment combines several different software components. within MATLAB do not map directly to those of the operating system (Linux here) and so care must be taken when sharing descriptors between MEX-files and standard MATLAB M-files. Each MEX-file is loaded, run and then removed from memory, so any state information required must be loaded from the MATLAB workspace and then stored before termination. The link provided by the socket contains a stop byte followed by a block of floating point values (either actuator or transducer signals). Although this implementation detail limits the communication options available, it has the advantage of ensuring that the controller is only presented with information that it could reasonably gain from a real robot. The test configuration file provides the option to label each actuator and transducer. It also includes a Patch Box (Figure 1), which contains a list of input and output labels. After loading a test configuration, the simulation environment scans through the Patch Box, looking for matches between the labels specified there and those in the rest of the file. It then presents and receives the information in the order given in the Patch Box, and forwards it appropriately, giving the test designer complete control over those inputs/outputs transmitted via the socket and their order. It also allows the other end (MATLAB in our case) to configure itself appropriately. SIMULATION CONFIGURATION FILES Traditional robotics simulation and control has largely been based on Denavit Hartenberg descriptions [12]. These are highly compact and quite flexible. However, they are not a description of a real robot, in that they do not contain information about motor specification, physical link shape and

4 1152 R. M. SUNDERLAND, R. I. DAMPER AND R. M. CROWDER <TEST> <SCENE> <FLOOR /> <OBJECT /> </SCENE> <MANIPULATOR> <PATCHBOX> <INPUT>M0</INPUT> <INPUT>M1</INPUT> <OUTPUT>SLIP1</OUTPUT> <OUTPUT>SLIP2</OUTPUT> </PATCHBOX> <ARM> <POSITION /> <QUATERNION /> <BOX /> <LINKCHAIN> <LINK/>... <LINK/> </LINKCHAIN> </ARM> <HAND> <SPHERE/> <POSITION/> <JOINT label="wrist" /> <LINKCHAIN label="finger1"> <LINK/>... </LINKCHAIN> <LINKCHAIN label="finger2">\\ <LINK label="phlange2.1"/>... </LINKCHAIN> </HAND> </MANIPULATOR> <NOTES/> </TEST> Figure 2. The structure of a configuration file for a robot. Several details have been omitted for clarity. dynamics, and sensor placement. They also have a very limited structure: basically a list of joint-link pairs, with four parameters a piece. This description has several properties that facilitate mathematical analysis, but since we are doing fully-featured physical simulation, these properties are not especially useful in this work. A MATLAB toolbox [13] is already available that handles joint-link based simulations directly. However, it does not perform collision detection and is therefore unsuitable for the simulation of manipulators. It was used when proving the mathematics behind some of the simulation

5 FLEXIBLE XML-BASED CONFIGURATION OF PHYSICAL SIMULATIONS 1153 <LINK label="phlange2.1"> <POSITION z="50.0" x="30" /> <QUATERNION angle="180" ux="0" uy="0" uz="1"/> <BOX length="50" width="10" depth="10" density="0.1" /> <JOINT linear="true" axis="x" label="j7"> <UPPERLIMIT damping="5000" stiffness="1000" range="0" /> <LOWERLIMIT damping="5000" stiffness="1000" range="-35" /> <MOTOR maxforce="0.01">m7</motor> </JOINT> <SENSOR logged="true" gain="1.0" label="slip2" size="10" type="slip"> <POSITION x="5" y="0" z="20"/> </SENSOR> </LINK> Figure 3. Link phalange2.1 described as a joint-link pair whose details were omitted from the configuration file shown in Figure 2. transformations. A more versatile alternative is provided by Vortex itself, which provides a way to load and store simulation objects directly from XML files. However, Vortex s XML files do not allow any structuring or labelling information (e.g. joint names like wrist ) to be stored and made available to other system components, like MATLAB. The simulation presented in this paper is based on a family of C++ objects. At configuration time, these objects parse an XML file using libxml2 and store the results in standard template library container classes. By using libxml2, we reduce coding and debugging time and will benefit from future releases. At the same time, XML allows us to exploit standard tools to write, modify and verify the simulation description files, which can be used easily by all stages of the system. There may come a point where the simulation requires large amounts of binary data (height fields or vertex meshes), in which case external files should be referenced rather than included directly in much the same way as an image in HTML. The robot and its environment are fully described in a configuration file. Figure 2 shows the structure of this file with details omitted for clarity. The SCENE element contains all the parts of the system that are not part of the robot being tested, including the objects than are to be manipulated. The MANIPULATOR contains three sections: PATCHBOX, ARM and HAND. As noted earlier, the Patch Box defines the order in which the manipulator s inputs and outputs are communicated over the UNIX sockets. In this case, two motors and slip sensors are included. The manipulator s ARM and HAND are defined as a sequence of links: a LINKCHAIN. The origin of the MANIPULATOR is defined by the BOX element, and the HAND by SPHERE, where BOX and SPHERE are pre-defined Vortex primitives. Figure 3 details the XML information for phalange2.1 of the robot s hand. A phalange is a bone of the finger and, in this work, we use phalange2.1 to denote link 1 of finger 2. Each LINK contains information of the link s structure, actuator and sensors. The POSITION and QUATERNION elements define the rest position and orientation of the link, in the coordinate frame of the previous link. BOX defines the link s geometry. The link s mass and polar moment of inertia are calculated by the Vortex libraries based on metadata. The JOINT entry specifies the axis and range of movement

6 1154 R. M. SUNDERLAND, R. I. DAMPER AND R. M. CROWDER 5 4 Ball height (m) Time Step Phases: 1 Lowering Grasping Tilting Raising Releasing Slip Sensor (Normalised) Time Step Figure 4. Pick-up and release cycle from the example simulation of an pick-and-place robot fitted with a parallel motion jaw: height of ball in metres (top) and normalized jaw slip sensor reading (bottom). permitted between this link and the previous link, with the option of storing motor parameters. In this case the joint rotary actuator is identified as M7, with a range of +0 to 35. Each link can optionally have SENSOR elements, with their position defined in the axis-frame of the link. Link phalange2.1 is fitted with a slip sensor. SCRIPTING For our purposes, it is essential that the system can run multiple tests unattended, which leads to three requirements. First, a range of pre-processing tools should allow for the generation of valid and variable XML test descriptions. Second, a further set of post-processing tools should be able to take the results logged by each simulation run and extract useful metrics from them. Third, a final set of tools should be able to orchestrate both of these to create a series of simulations. So that the input files can be easily and automatically modified and the output can be properly interpreted, Python scripting was chosen for the reasons given earlier. The physical simulation is used (with the output disabled) to parse the robot XML files when processing is required. Hence, the same input parsing code is reused, reducing the maintenance time.

7 FLEXIBLE XML-BASED CONFIGURATION OF PHYSICAL SIMULATIONS 1155 EXAMPLE SIMULATION The simulation environment described above was developed as part of our research into the control of dexterous robotic end effectors in unstructured environments [8,9]. As part of this work, we use slip and force sensors to control gripper dynamics. To demonstrate the performance of the software environment, we simulated a pick-and-place robot manipulating a solid ball through a five stage process of lowering the manipulator, grasping the ball, tilting the wrist, raising the manipulator and releasing the ball. This simulation used a proportional joint-position controller implemented in MATLAB. Subsequently, a Python script extracted comma-separated-variable files from the XML output log. These files were imported into MATLAB and used to generate the results in Figure 4,which clearly show the ball slipping relative to the gripper as the manipulator moves. As expected, the slip is a function of the robot s orientation and acceleration, together with the gripper s contact forces. CONCLUSION This paper has reported the development of a simulation environment that can be configured with simple XML files. The use of a loosely coupled architecture allows us to explore various control options, without modifying the physical simulation. It is currently being used extensively to support our research on biologically-inspired robotic manipulation. This approach is equally applicable to more general control simulations that require high-fidelity physical modelling. REFERENCES 1. Bray T, Paoli J, Sperberg-McQueen CM. Extensible Markup Language (XML) 1.0 Recommendation, W3C, February [June 2003]. 2. Open Dynamics Engine. [June 2003]. 3. CMlabs. Vortex Simulation Libraries. Version [June 2003]. 4. Gazebo. Outdoor multiple robot simulator. [June 2003]. 5. OpenSim. 3d simulator for autonomous robots. [June 2003]. 6. DynaMechs. Multibody dynamic simulation library. [June 2003]. 7. Miller AT. GraspIt!: A versatile simulator for robotic grasping. PhD Thesis, Department of Computer Science, Columbia University, June Domínguez-López JA, Damper RI, Crowder RM, Harris CJ. Optimal object grasping using fuzzy logic. Proceedings International Conference on Robotics, Vision, Information and Signal Processing, Penang, Malaysia. IEEE, 2003; Domínguez-López JA, Damper RI, Crowder RM, Harris CJ. Adaptive neurofuzzy control of a robotic gripper with on-line machine learning. Robotics and Autonomous Systems, submitted. 10. The MathWorks. Technical Computing. [June 2003]. 11. Python Documentation. [June 2003]. 12. Denavit J, Hartenberg RS. A kinematic notation for lower-pair machanisms based on matrices. Applied Mechanics 1955; 77: Corke PI. A robotics toolbox for MATLAB. IEEE Robotics and Automation Magazine 1996; 3(1):24 32.