ÜberSim: High-Fidelity Multi-Robot Simulation for Robot Soccer

Transcription

1 ÜberSim: High-Fidelity Multi-Robot Simulation for Robot Soccer Content Areas: common sense reasoning, knowledge representation Abstract High fidelity simulation can be a powerful tool for speeding up the robot control development cycle. For RoboCup robot soccer, a dynamic adversarial game where robot teams play soccer against one another, this is especially true. Developing control software for a robot soccer team is a difficult task, one that gains substantially from simulation. As yet, however, there are no publicly available simulators that are realistic or configurable enough to be of real use to a robot soccer team. In this paper, we describe ÜberSim, a new simulation engine built around a high-fidelity physics simulation engine that attempts to address this lack for the small size league, a division within RoboCup. The goal of ÜberSim is to provide a simulation engine that is extensible, re-configurable, and realistic enough to support easy transfer of robot control software directly from simulation to reality with a minimum of fuss. Here, we describe the implementation of ÜberSim for the small-size league, the design choices made and their reasoning. 1 Introduction Robot soccer is an international initiative developed to push the state-of-the-art in autonomous, multi-robot intelligence through autonomous robot teams playing games of soccer against one another. To develop a successful team, a wide range of challenges must be overcome. In particular, the adversarial nature of the task creates significant levels of uncertainty that must be dealt with by these control systems, while its fast-paced nature pushes robot control techniques to their limits and beyond. Without a doubt, developing robot soccer control systems is a difficult task, but it is a task that can and does benefit from the use of good simulation engines. Many teams (e.g.???) have made good use of simulators to enable them to greatly speed up their software development process. Developing software directly on robots is often a tedious and difficult process. Limited communications bandwidth often limits one s ability to gain insightful information during the debugging process. Likewise, robot experiments are limited in duration due to the need to regularly change batteries. None of these difficulties arise in simulation, where indeed the presence of the robots, which are often a contentious resource, is not even required. A simulator is useful if it speeds up development. Hence, a useful simulator is one that facilitates the transfer of simulation developed control to the real system with a minimum of fuss. The key here lies in capturing the important environment dynamics at reasonable computation speeds. Robot soccer, due to its fast pace, places greater requirements on accurate dynamics than does many other multi-robot research domains. Unfortunately, most freely available multi-robot simulators use lowfidelity dynamics models and rarely consider collisions making them unsuitable for this task. As a result researchers often develop custom simulators to fill this void. This development, however, is non-trivial and more than likely a low reward to cost venture. Moreover, if the simulator is not extensible it will most likely require substantial modifications as the robot hardware changes, which it often does from year to year. To address this issue, we have attempted to address this issue by developing a high-fidelity simulation engine, called ÜberSim. ÜberSim is extensible, reconfigurable, and publicly available under the Open Source LGPL license at [UberSim]. Specifically, Über- Sim has been developed for the small size league (SSL), a division of RoboCup robot soccer where robots are restricted in size and teams are allowed to use overhead cameras for global perception and off-field processing [Kitano et al., 98]. In this paper, we describe the development of ÜberSim, the design choices made, and the resulting system. The following section overviews the robot soccer, and the SSL with an eye to specifying the requirements for the simulator. Section 3 describes the details of the ÜberSim implementation. Section 4 presents some empirical evaluations to validate its performance, with Section 5 describing some related approaches. Finally, section 6 concludes the paper.

2 2 Overview In this section we briefly overview robot soccer and the small size league (SSL) with a view to defining the requirements for the ÜberSim simulator. 2.1 Robot Soccer RoboCup robot soccer [Kitano et al., 98] is an adversarial multi-robot research domain where autonomous teams of robots compete against one another in a game of soccer. The domain has a broad range of leagues, however, in the context of this paper our focus is on the small size league (SSL). A SSL game consists of two teams of five robots playing soccer with an orange golf ball on a 2.8m x 2.3m carpeted field, surrounded by short angled walls. Figure??? shows a picture of a game. Each robot is restricted in size, shape, and its use of ball manipulation devices. Robots must fit within an 18cm x 15cm cylinder and must not enclose the ball by more than 1cm. Ball manipulation devices are restricted, but many teams use dribbling and kicking mechanisms. A dribbler is a rubberized bar that rotates against the ball causing it to spin backwards against the robot thereby aiding manipulation, while a kicker is a linear or rotational actuator driving a metal bar. Given these restrictions, there is still much diversity in robot bases ranging in size and shape, speed and acceleration capabilities, ball manipulation mechanisms, through to the number of wheels, their type, and physical arrangement. Teams include differentially driven robots (diffbots), omni-directional robots (omnibots) and even four wheeled omni-directional robots. The SSL is further characterized by the allowance of off-field computers for processing and overhead cameras for global vision perception purposes. In this common case, the team as a whole is autonomous rather than each individual robot. Figure 1 shows the common system set up where global vision and control is processed off field and low-level velocity commands are sent to the individual robots with their own local servo control loops. Using this set up, many teams produce robot systems that are capable of high speed motions, approaching 2m/s, with ball speeds of 2m/s and even up to 5m/s! With such fast moving objects, accurate control is of paramount importance and this places many constraints on the accuracy of the simulation engine. 2.2 ÜberSim Requirements To be a useful SSL simulator, ÜberSim must provide identical software interfaces control software as well as simulating the physics of the robots and ball moving through the world. For SSL, or indeed any robot system, three interfaces are required: Perception, action, and a control interface for controlling the set up and execution of the simulation. The unique use of global vision and off field processing in the SSL creates a natural level to provide the perception and action interfaces. All teams that use global perception first process vision to produce estimates of where each object is on the field, potentially their orientation and velocities. Indeed, one of the current ideas within the league is to move to a unified vision server that produces this pose information for the teams to process. Likewise, at the opposite end of the spectrum, many teams make use of low-level control algorithms running on the robots proper to essentially create a remote controlled vehicle where velocity (or perhaps position) commands are sent to control it (see Figure???). These two facts conspire to make the output of the vision processing module and the input to the radio module the ideal location to simulate the interfaces to the real world. Overhead camera Figure 1. A typical small-size robot soccer game set up. The exact parameterization of each interface is dependent upon the system in question. In general, however, it will be a fairly simple remapping of the parameters (or ignoring some) and is therefore ignored for the remainder of this work. Small-Size System wireless <x,y,, conf> x 30Hz ~100ms latency <v x, v y, > x 30Hz ÜberSim Off field PC Figure 2. Perception and Action interfaces for ÜberSim. ÜberSim must also simulate the dynamical properties of each interface. Indeed, for the SSL where One of the keys to developing good SSL control systems is to account for the system latency and limited frame rate. Typical latencies are on the order of 100ms, which has substantial impact on a robot moving at 1 to 2m/s over such a small field. Consequently, the simulation engine must incorporate a latency mechanism in order for control performance to be similar between simulation and reality. Unless specialized hardware is used, frame rates are limited to 25, 30, 50, or 60Hz depending upon the type of camera used and whether the full interlaced frame rate is used or not. As with latency, accurately simulating this limited frame rate is critical to ensuring the transferability of software from simulation to reality.

3 3 ÜBERSIM IMPLEMENTATION We now describe the specifics of the ÜberSim implementation for the SSL beginning with an overview of the ÜberSim approach. Throughout we emphasize the need to produce accurate but fast simulations and the need for extensible and easily reconfigurable simulation. 3.1 Simulator Overview With ÜberSim, we take a distinctly different to most robot simulation engines. Rather than developing our own custom rigid body dynamics and collision software, which is the approach used by most researchers, we have taken the approach of using a publicly available Open Source Software (OSS) library. Our motivation for this approach is simple. A mature OSS library with a community of users can be considered proven software, relatively bug free, and both functional and capable. Additionally, if the project is supported, new functionality will get added while existing bugs will get fixed. The alternative, of developing custom software, is a nontrivial task as evidenced by the surprisingly few OSS rigid body simulation libraries available. Of the mature OSS libraries, of which there are few, the Open Dynamics Engine (ODE) [ODE] meets the requirements and has a community of users that continues to grow in size. We describe further the relevant details of the simulator in the following sections. To achieve extensibility, we have devised object class structure combined with text-based configuration files. For creating a new robot, or some other object type, one defines the constructor to create and fill in the data structures that define the robot and a handle_event method to translate robot commands into force or speed settings for the robot s actuators. The simulator supports text-based configuration files for generically setting robot defined vector-based parameters thereby providing easy reconfiguration of robot parameters for a given robot class. Collision Manager ODE Dynamics, Collisions, Graphics Field Ball Diff Robot Scene Graph Figure 2. ÜberSim system components. Omni Robot Main Controller IFace Vision Radio Control Figure?? shows the major ÜberSim components. The primary data structure is the scene graph (SG), actually it is a tree but we use its more commonly accepted name. The SG maintains the position, dynamics, and collision information for all the physical objects in the environment. The collision manager interacts between ODE and the SG to implement collision detection routines and update the appropriate data structures. The Interface module provides the socket interface to the user software (or visualization tools). Finally, the main controller runs the show. In the following sections we describe these modules in greater detail. 3.2 Open Dynamics Engine The physics engine is the key to making ÜberSim useful in terms of high performance robot control. To be suitable, the physics engine must provide accurate rigid body dynamics, a suitable range of joint types, a suitable range of actuators, elastic contact collisions between rigid body objects, finite static and dynamic friction between touching surfaces and the transition between friction modes. As mentioned above, there are few OSS rigid body simulation engines that meet these criteria. Although there a number of free body simulators, most of these are intended for fast pseudo realistic simulation for computer games. Although visually realistic, accurate collision dynamics and finite friction limits are often ignored. For the task at hand, we need both accuracy and sufficient speed to operate on a standard PC in real time or faster. For ÜberSim we chose the Open Dynamics Engine (ODE) (version was used for this paper). ODE is a free rigid body simulator, developed by Russell Smith, and is available at [ODE]. It has been used in a number of other projects (see the site for details), is reasonably documented, and has reached a maturity level ensuring that the code is stable and useable. ODE provides support for rigid body motion with non-zero mass and rotational inertia, and non-uniform mass distributions. The simulator uses Euler integration with a settable simulation step size. Euler integration is accurate, fast, and relatively stable. To aid in simulation stability, a restitution force is allowed which forces wayward joints back into position. This is required as integration errors invariably accumulate. For a simulation such as ÜberSim, trading a little accuracy for long-term stability is necessary feature. For a number of simple object types (rectangular prisms, spheres and cylinders), ODE provides collision detection primitives. Most importantly, ODE simulates both static and dynamic friction for contacting surfaces with bounded stiction limits. Further, the frictional forces can be directionally dependent, which is critical for omni-directional wheels where the wheels free roll in one direction and have traction in the other. A number of joint types and actuator types are supported. Although the list of types is small, they cover the full range of joints and actuators found in robot soccer including the more complex Sony AIBO and humanoid robots. As a bonus feature, ODE includes OpenGL routines to render the 3D simulated environment thereby providing support for useful visualization tools. Put together, ODE meets our requirements for the simulation engine. Its main limitation stems from its collision detection package, which only provides a small set of primitive object shapes rather than a general polygon soup. Within ODE, objects consist of rigid bodies, geometries, and joints. Rigid bodies are the dynamical objects (with mass etc) and are used in the integration process. In

4 contrast, geometries and joints are not dynamical objects. Geometries are used to determine when and where collisions occur and what resultant forces are transferred to the connected rigid bodies. Joints are special geometries used to specify how two connected rigid bodies can move in relation to one another. Joints can also be powered, which provides the primary mechanism for controlling how the connected body behaves. 3.3 Scene Graph The main data structure used in ÜberSim is the Scene Graph (SG). The SG maintains all the information required by ODE to carry out integration steps, and all the information necessary to perform collision detection. The SG is actually a tree, although we use its more common name, that stores each object type in a hierarchical relationship. Figure 3 shows a simple SG. The SG uses the same object types identified by ODE: rigid bodies, geometries, joints, and contact surfaces. Geometries consist of one of the primitive shapes supported by ODE namely rectangular prisms, spheres, cylinders. Likewise, joints map directly to the available joint types found in ODE. root sphere ball rigid shell Robot1 wheel wheel Robot2 cylinder Figure 3. A simple scene graph. Rigid bodies are boxes, nodes are ovals, and hexagons are geometries. In addition to encapsulating all the physical parameters required by ÜberSim, it significantly simplifies the interaction between ÜberSim and ODE. In short, with the exception of the collision manager, all other modules interact with the simulation by manipulating or reading the SG data structure. We discuss this in further detail in section 3.6 for the main control loop. 3.4 Collision Detection ODE provides only primitive collision handling support. The Collision Manager (CM) interacts with ODE and the SG to detect and handle collisions. Collision detection, even for the primitive objects supported by ODE, is known to be processor intensive. We can avoid much wasted computation by recognizing that most objects in the environment are not colliding with one another. Further, the hierarchical nature of the SG enables us to make a significant improvement by using hierarchical bounding boxes, or in this case bounding spheres. This approach, which is common in collision detection packages (e.g. [Reggianni, 02]. Each node within the SG contains a bounding sphere that encapsulates the geometries at that node and all of its children. Very fast collision detection can then be performed between each bounding sphere within the SG. Collision detection can be performed by walking through the tree considering each node and checking for bounding sphere overlaps between the node and all nodes that have not been checked and are not a child or ancestor of the current node. Further optimizations are possible by realizing that if two nodes do not overlap, then none of their children overlap and so do not need to be compared. Once potential collisions have been winnowed, the more expensive ODE collision detection operations are applied. For any contacting surfaces, ODE generates the appropriate restoring forces. Depending upon the surfaces in question, these restoration forces may include friction components the parameters of which are stored in the SG as surface properties. 3.5 Object Classes Each object type in the environment is encapsulated into a class and has an associated text-based configuration file defining its parameter values. RigidBodyEntity is the base object and it encapsulates the notion of a rigid body with geometry providing base methods for adding objects to the scene graph, accessing its position, and for handling manipulation commands from ÜberSim. All other objects, the field, ball, and robot classes, are derived from RigidBodyEntity and therefore inherit its basic capabilities. As a result, each more complex object need only define a constructor to create its relevant SG objects, and a handle-event method to respond to ÜberSim generated events. The range of events include position events used to manually move objects around, command events generated when robot control programs send commands to a robot and query events that respond with the object position, orientation, and velocity in the world. The latter is used by ÜberSim to generate its perceptual output to the controlling software. The field and ball, which are trivial, are derived from the RibidBodyEntity class. Both classes have a constructor for creating the necessary geometries and contact surfaces and adding them to the SG. The parameters for these values are derived from the text-based configuration files. These text-based files are much like script files and allow assignment of a known parameter name to a vector list of values, which may be Boolean, strings, integers, or floats. The ball object additionally has a single rigid body object to define its mass and rotational inertia. No handle-event is required for the field (as it never moves), while the ball must only handles position events. One of the core challenges in the ÜberSim concept is the problem of how to enable new robot configurations to be easily added and/or parameters changed. In terms of robot hardware and capabilities, RoboCup is a very dynamic domain. Robots are often completely rebuilt from one year to the next. Hardware innovations may result in completely new drive configurations, new complex ball

5 manipulation devices, and at the very least substantial changes in the parameters that describe the physical characteristics of a robot. For the ÜberSim concept to be useful to a team, or to be capable of providing a simulation environment for comparing two teams, there must be mechanisms to add new robot types easily. Moreover, given the argued need for simulation accuracy, there must be a mechanism to easily adapt robot parameters to closely match those of the physical robot. To achieve this goal, ÜberSim uses multiple robot objects where each object encapsulates a particular robot type. Each robot class is derived from the usual Rigid- BodyEntity class giving it the base abilities for manipulation. Each robot object encapsulates a parameterized robot configuration, where the parameters describe the physical characteristics of a robot. In the current implementation of ÜberSim, two robot objects are defined: OmniRobot and DiffRobot. Each robot type, with appropriate parameters, can represent nearly all the robots found in small-size RoboCup competitions. The two types are distinguishable based on the drive configuration where the DiffRobot uses two wheels, while the Omni- Robot uses three specialized omni wheels. Each robot has an optional dribbler and kicker mechanism. The robot types define a generic differential or omni directional robot base with a kicker and dribbler (if selected). The particular parameters that define the dimensions and positioning of each part, the physical properties of the major robot components (mass, inertia etc.) and their contact parameters are read from human readable/editable ASCII text configuration files. 3.6 Putting it all together The main controller loop consists of taking the SG at the beginning of each simulation step and generating a list of rigid bodies. This list is sent to ODE to integrate ahead one time step. The SG is then updated with results of the integration. Collision detection, discussed next, is then performed and the appropriate actions taken. The main controller then extracts from the SG the positions of the objects in the world via the object classes, discussed below, and generates the appropriate perceptual output to the robot control software. Any commands sent by the control software are transformed appropriately and sent to the joint objects in the SG to be taken into account during the next simulation step. 4 RESULTS & DISCUSSION ÜberSim is able to simulate two teams of 5 robots and the golf ball playing soccer. With two simulation steps per frame of vision, running on a 1GHz Pentium processor, the simulator is able to execute at full frame rate (30Hz output, 60Hz simulation steps) using around 60% of the processor for the two full teams. To examine the performance of the system, we have compared the trajectories generated by ÜberSim for a robot performing a set pattern and performing acceleration tests. The robots were controlled using our CMDragons software [CMDragons]. The set pattern is a fixed sequence of target points fed into the navigation/motion control system where the target speed at the destination is set to zero. For details on the navigation and motion control see [Bruce et al., 02]. Figure 4 shows the acceleration tests at 2 m.s -2 for a differential drive robot in simulation and reality. The trials were repeated 5 times. Note that there will be some variation in the observed trajectory as the real system has noise and natural variation in the robot parameters. Figure 5 shows trajectory comparisons for a differential drive driving in a figure 8 at around 0.8 m.s -1 for a simulated robot versus a real one. In terms of running a team, simulation accuracy is appears visually reasonable, however, it is difficult to perform experiments analyzing how accurate simulation collisions are to the real thing and this remains an area of future work. Speed m/s Figure 4. Acceleration comparison for a simulated Diff Robot (. ) versus a real robot ( + ) repeated 5 times Linear Acceleration Test Time (s) Figure 5. Trajectory comparison for simulator (line) and real robot (. ) performing a set figure 8 shape. 5 RELATED WORK A plethora of robot simulators have been created to support robot research. Although some are available publicly, most are not. Most simulators do not model robot dynamics at any detailed way and are intended for generic robot research. Prime examples of this approach are

6 Player/Stage [Vaughan, 00] and TeamBots [Balch, 98]. Both Player/Stage and TeamBots is a distributed multirobot simulator and can simulate large numbers of different robots interacting in complex environments with a variety of sensors. Both simulators have limited, or no, dynamics simulation capabilities. Although TeamBots has been used to simulate games of robot soccer, the simulator again uses low-fidelity dynamics approximations and its collision detection abilities are limited. The Robot Soccer Server [Noda et al., 98], which is the official simulator for the RoboCup simulator robot soccer league, provides a simulation environment dedicated to investigating the high-level control issues for a team of distributed soccer agents. In contrast to TeamBots and Player/Stage, the Soccer Server simulates each agent as a high-level abstract robot/human and does not address robot-like motion in any way. Similarly, it lacks any meaningful collision detection capabilities. Within the robot soccer community, many develop customized simulation software. In general though, these simulators meet the minimum requirements for the task at hand and must often be rewritten as robot hardware changes. Finally, these simulators are almost never made publicly available or their details published. There are some exceptions, however. M-ROSE [Buck et al. 02] is a novel simulation engine that uses a neural network (NN) to learn the forward dynamics model using backpropagation. The forward model is trained from real robot data, and is used in its to simulate the dynamics of the robot by predicting its next state based on the current state and velocity command. This technique is quite novel and captures the robot dynamics without the need for parameterization. The drawback relates to collision dynamics, which must be implemented by hand. Indeed, the authors only implement ball-robot collision detection. It is unclear how robot-robot collision detection could be integrated in any reliable fashion to the NN. 6 CONCLUSIONS In this paper we described the development of a new Open Source, high fidelity simulation engine for robot soccer, in particular for the small size league. Our goal has been to develop an extensible simulation engine that is accurate, fast, as well as being easily reconfigured for parameter changes. To achieve these goals we have incorporated a capable Open Source physics simulation core with extensible robot classes and text based configuration files. We demonstrated the validity of our approach by applying ÜberSim to simulate our own small size team, the CMDragons small size team participants at RoboCup The empirical evidence convinces us that ÜberSim is both capable and that the concept has great potential, which we hope to harness in our future work. ACKNOWLEDGMENTS The authors would like to thank Prof. Manuela Veloso and Michael Bowling for the help and support for the development of the research described in this paper. This research was sponsored by Grants No. DABT and F The views and conclusions contained in this document are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the funding agencies. REFERENCES [Balch, 98] Balch, T. JavaSoccer. RoboCup-97: Robot Soccer World Cup I, Springer-Verlag, [Bruce & Veloso, 03] Bruce, J., & Veloso, M. Fast and accurate vision-based pattern detection and identification. In Proceedings of the 2003 IEEE International Conference on Robotics and Automation (ICRA 03), 2003, under submission. [Bruce et al., 02] Bruce, J., Bowling, M., Browning, B., & Veloso, M. Multi-robot team response to a multi-robot opponent team. In Proceedings of IEEE/RSJ International Conference on Robotics and Autonomous Systems, workshop on Collaborative Robots, [Buck et al., 02] Buck, S., Beetz, M., & Schmitt, T. M- ROSE: A multi robot simulation environment for learning cooperative behavior. In H. Asama, T. Arai, T. Fukuda, and T. Hasegawa (eds.): Distributed Autonomous Robotic Systems 5, Springer, [Kitano et al., 98] Kitano, H., Asada, M., Kuniyoshi, Y., Noda, I., Osawa, E., & Matsubara, H., RoboCup: A Challenge Problem for AI and Robotics. RoboCup-97: Robot Soccer World Cup I, Nagoya, L.N. on A.I., Springer Verlag, 1998, [Noda et al., 98] Noda, I., Matsubara, H., Hiraki, K. & Frank, I. Soccer Server: A tool for research on multiagent systems. Applied Artificial Intelligence, 12: , [ODE] [Reggiani et al., 02] Reggiani, M., Mazzoli, M., Caselli, S. An experimental evaluation of collision detection packages for robot motion planning. In Proceedings of the 2002 IEEE/RSJ International Conference on Intelligent Robots and Systems, (IROS 2002), [ÜberSim] [Vaughan, 00] Vaughan, R. Stage: a multiple robot simulator. Technical Report IRIS , Institute for Robotics and Intelligent Systems, School of Engineering, University of Southern California, 2000.