Dynamic avoidance control of soccer playing mini-robots

Dynamic avoidance control of soccer playing mini-robots

by

Joost van der Linden

Dr. A. L. Schoute Dr. M. Poel Dr. Ir. A.F. van der Stappen

Distributed and Embedded Systems Group (DIES) Department of Computer Science University of Twente The Netherlands

December 2005

Abstract The MI20 robotsoccer team, participating in the FIRA Mirosot league, consists of small-sized, wheeled robots that play soccer by bouncing a golf ball. The MI20 robotsoccer system has two methods for performing a motion towards a target position. One is a reactive method that is capable of avoiding collisions, but lacks in consistency with proceeding towards its target. The other is a deliberative method for motion, which is based on planning Scurves. When the path is followed, collisions between controllable robots (i.e. of the own team) are avoided by adjusting the velocity of either of them. This deliberative method is capable of reaching a target within set time constraints, but collisions avoidance is rather limited. Whereas collisions between controllable robots are avoided, collisions with uncontrolled robots are not avoided in any way. This thesis describes a method to forecast collisions between robots at the planning phase. The forecast is based on estimated velocity profiles of the robots on their planned paths. This method can be used to test any two S-curves for collisions, beforehand. The S-curve planning strategy is optimized for avoiding collisions, as follows. In the planning task the shortest collision free S-curve is selected if it exists. Otherwise the shortest curve is selected while the original method for collision avoidance at control level is used. Results of testing within a simulated environment show that the forecast method is able to predict most of the collisions. There is room for improvement by either estimating the trajectories at a higher precision, or making the actual robot trajectory tracking more consistent by using timed feedback control. Test results show that the new planning strategy did not (yet) improve the motion efficiency. The reason for this is, that the collision free S-curve in many cases results in a much longer deviation. The collision forecast may prove more valuable, in future improvements. Other solutions for bilateral collision avoidance of controlled robots may benefit from collision forecast information.

Samenvatting Het MI20 robotvoetbal team, dat deel neemt aan de FIRA Mirosot league, bestaat uit kleine robots op wielen, die voetbal spelen met een golfbal. Het MI20 robotvoetbal systeem bevat twee methodes om een robot naar een bepaalde doellokatie te verplaatsen. Eén daarvan is een reactieve methode die goed in staat is om botsingen met obstakels te vermijden, maar minder consistent is in het rijden richting de doellokatie. Daarnaast is er een deliberatieve (planmatige) methode, die gebaseerd is op het plannen van de zogenaamde S-curves. Tijdens het volgen van een dergelijk pad door meerdere (bestuurbare) robots, zullen botsingen vermeden worden door tijdelijk de snelheid van één van de twee robots aan te passen. Deze planmatige methode van voortbewegen maakt het mogelijk robots binnen een bepaalde tijd een doellokatie te laten bereiken. Het vermijden van botsingen met andere robots is echter vrij beperkt. Botsingen tussen robots binnen het team worden vermeden, alleen wanneer deze zich verplaatsen door middel van geplande motion. Botsingen met robots van het andere team worden helemaal niet vermeden. In deze scriptie wordt een methode beschreven, voor het op planningsniveau voorspellen van botsingen tussen bestuurbare robots. De botsingvoorspelling wordt gebaseerd op een geschatte snelheidsprofiel wat de voertuigen zullen doorlopen, als ze over hun pad rijden. Deze methode maakt het mogelijk twee willekeurige S-curves te testen voordat deze uitgevoerd worden. De S-curve planningsstrategie is geoptimaliseerd om zo veel mogelijk curves te plannen die botsingsvrij zijn. Bij het bepalen van het pad wordt gezocht naar de kortste botsingsvrije curve. Als deze niet bestaat wordt simpelweg de kortste curve gebruikt, en zal de bestaande methode voor botsingsvermijding op control niveau gebruikt worden. Resultaten van testen in een gesimuleerde omgeving tonen aan dat de forecast methode de meeste botsingen kan voorspellen. Het is mogelijk de nauwkeurigheid daarvan te verbeteren, door het schatten van het traject op een meer gedetailleerde manier uit te voeren. Een andere mogelijkheid is dat het werkelijke tijd-ruimte pad meer voorspelbaar wordt uitgevoerd door het toepassen van tijd-teruggekoppelde besturing. Test resultaten tonen aan dat het uitvoeren van verplaatsingen niet efficiënter is geworden met de nieuwe planningsstrategie. De reden hiervoor

IV

is dat botsingsvrije paden in veel gevallen tot veel langere omleidingen resulteren. De waarde van de botsingvoorspellings methode kan beter tot zijn recht komen in eventueel toekomstige uitbreidingen. Bijvoorbeeld een implementatie van wederzijdse botsingsvermijding door robots van het eigen team, kan baat hebben bij de beschikbaarheid van informatie over voorspelde botsingen.

Contents 1 Introduction 1.1 Robot soccer . . . . . . . . 1.2 The MI20 project . . . . . . 1.3 Motion control . . . . . . . 1.3.1 Deliberative motion 1.3.2 Reactive motion . . 1.4 Problem definition . . . . . 1.5 Objective . . . . . . . . . . 1.6 Thesis outline . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

3 3 4 4 4 5 5 6 6

2 The 2.1 2.2 2.3 2.4

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

7 7 8 11 13

MI20 system Hardware setup . . . . . Software structure . . . Motion control in MI20 Simulation . . . . . . . .

. . . .

. . . .

3 Collision avoidance methods 3.1 Reactive collision avoidance . . . . . 3.2 Deliberative planning of collision free 3.2.1 Centralized planning . . . . . 3.2.2 Decoupled planning . . . . . 3.3 Task assignment . . . . . . . . . . . 3.4 Collision avoidance in robot soccer .

. . . . paths . . . . . . . . . . . . . . . .

4 Collision prediction 4.1 Motion trajectory . . . . . . . . . . . . . 4.1.1 Trajectory description . . . . . . 4.1.2 Prediction of a motion trajectory 4.2 Forecast computation . . . . . . . . . . 4.2.1 State space analysis . . . . . . . 4.2.2 Joint trajectory analysis . . . . . 4.2.3 Collision calculation . . . . . . .

. . . . . . .

. . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

15 15 16 17 17 18 19

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

20 20 20 21 24 26 26 28

CONTENTS

5 Development 5.1 Roadplan extension . . 5.2 Forecast module . . . 5.3 Application of forecast 5.3.1 Motion control 5.3.2 Path planning .

VI

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

30 30 30 31 32 32

6 Testing & evaluation 34 6.1 Motion trajectory accuracy . . . . . . . . . . . . . . . . . . . 34 6.2 Forecast accuracy . . . . . . . . . . . . . . . . . . . . . . . . . 38 6.3 Improvement of deliberative motion . . . . . . . . . . . . . . 40 7 Conclusion 43 7.1 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 7.2 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

List of Figures 1.1

General setup of a MiroSot game . . . . . . . . . . . . . . . .

4

2.1 2.2

Simplified overview of system modules . . . . . . . . . . . . . Four S-curves between start pose and end pose . . . . . . . .

9 12

4.1

An S-curve (a), a velocity profile (b), and the route progress in time (c) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The trajectory in CT-space shown with the vehicle’s occupying area in (x,y)space . . . . . . . . . . . . . . . . . . . . . . Three situations for dividing a curve segment in acceleration segments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Two vehicles on their path, and the corresponding configuration state space . . . . . . . . . . . . . . . . . . . . . . . . . . The configuration space of the route positions (sX,sY)) is divided in cells with constant acceleration . . . . . . . . . . . The collision zones that are passed by the joint trajectory can not cause any collisions. . . . . . . . . . . . . . . . . . . . . . Only the cartesian zones that contain the joint trajectory, need to be analysed for collision states. . . . . . . . . . . . . .

4.2 4.3 4.4 4.5 4.6 4.7

6.1 6.2 6.3 6.4 6.5 7.1 7.2

Trajectory estimation accuracy. Created in simulator and Scurve with large radius (30cm) . . . . . . . . . . . . . . . . . Trajectory estimation accuracy. Created in simulator and Scurve with small radius (15cm) . . . . . . . . . . . . . . . . . Trajectory estimation accuracy. Created with actual robots and S-curve with large radius (30cm) . . . . . . . . . . . . . . Trajectory estimation accuracy. Created with actual robots and S-curve with small radius (15cm) . . . . . . . . . . . . . The field is divided in four regions. . . . . . . . . . . . . . . . The class diagram of the forecast module implementation . . Planned and actual S-curve with large radius (30cm). Created in simulator . . . . . . . . . . . . . . . . . . . . . . . . .

22 23 25 26 27 28 29

36 36 37 37 39 48 50

LIST OF FIGURES

7.3 7.4 7.5

Planned and actual S-curve ated in simulator . . . . . . Planned and actual S-curve ated in actual robots. . . . Planned and actual S-curve ated in actual robots. . . .

1

with . . . with . . . with . . .

small radius (15cm). . . . . . . . . . . . . small radius (30cm). . . . . . . . . . . . . small radius (15cm). . . . . . . . . . . . .

Cre. . . . Cre. . . . Cre. . . .

51 51 52

Preface This thesis describes the results of my graduation at the MI20 team. I spent about fifteen months on my work, while only six months were prescribed for my curriculum. I think this indicates mostly, that I enjoyed working on my subject. The preparations for the German Open championship in Paderborn were exciting, just as the ones for the European championship at the University of Twente. It is unfortunate that we could not score more goal during these games. But being defeated by the best team as well as the second worse team, gives quite an impulse to inspiration for working on the system. I owe much gratitude to the following people. The (former) members of the MI20 team, Sido Grond, Charles Petit, Maarten Buth, Paul de Groot and especially Roelof Heddema for creating a useful simulator, that has robots that can move with constant acceleration. Also many thank goes to my supervisors, Albert Schoute and Mannes Poel, for their support, guidance and patience.

Chapter 1

Introduction Robotsoccer is the game were teams of autonomous robots play soccer competitions. Various leagues1 exist with robots that are different in size, locomotion, complexity and rules. A robotsoccer system is developed at the University of Twente to compete in a category of small wheeled robots. Part of this system, that is responsible for handling the motion of robots, suffers from problems with respect to collision avoiding capabilities. The main subject of this thesis is the improvement of motion planning and control by introducing methods for prediction and avoidance of collisions.

1.1

Robot soccer

Our project is focused on the MiroSot (Micro-Robot World Cup Soccer Tournament) category. The MiroSot is competition category with robots that have a size of at most 7.5cm in length, width and height. This size limits the sensor capabilities and processing power of the robots, so that an external controlling computer is required. Currently we participate in two MiroSot leagues, namely the Mirosot Medium and Large league. The difference lies in the amount of robots and the field size. The middle league uses five robots on a field of 220cm x 180cm, whereas the large league uses seven robots on a field of 280cm x 220cm. The usual setup of a MiroSot game is shown in figure 1.1. A camera is mounted above the playing field and captures images of the robots. Each robot has a colored patch on the top side that make it identifiable for the central computer as an opponent or a member of the own team. The central computer receives the camera images and determines appropriate commands for the team robots to handle the game play. The commands are sent to the robots by means of radio communication. 1

See http://www.fira.net or http://www.robocup.org for an overview

1.2 The MI20 project

4

Figure 1.1: General setup of a MiroSot game

1.2

The MI20 project

The robotsoccer project started in 2002 at the University of Twente as a cooperation between the research groups Distributed and Embedded Systems (DIES) and Human Media Interaction (HMI). The goal was to develop a robot soccer system to compete in the MiroSot league. At the same time this robot soccer system is used as a test bed to experiment with different kinds of techniques. The robot soccer software system that was developed is referred to as the MI20 system. Several master students have worked on the MI20 system, to test theories, improve the MI20 software, and not least of all to graduate in the process. Also my project was setup with these goals in mind.

1.3

Motion control

In the area of robotics, two approaches exist for handling motion, with both their advantages and disadvantages. Both approaches are used in motion control of the MI20 system.

1.3.1

Deliberative motion

Deliberative motion usually involves the generation of an explicit plan that describes how to reach a target location. After such a plan is created, it is memorized and executed. This approach has the problem that the planning phase can be computationally intensive. Also in highly dynamic environments constant replanning is needed, which makes this approach not

1.4 Problem definition

5

always feasible for these circumstances. An advantage of planned motion is that it may be much more consistent and able to realize long term goals. When motion trajectories are known in advance, coordination is much better possible in multi robot systems.

1.3.2

Reactive motion

In a reactive approach the motion is not planned ahead in time. At each moment of execution the motion commands are directly derived from the current state and sensor input. This makes this approach very fast and useful for obstacle avoidance on the short term in dynamic environments. Reactive motion avoids the problem of keeping an environment model up to date. A well known phrase to characterize this: ”The world is its own best model”. This aspect can however also cause problems: sensory data may be incorrectly interpreted. Another disadvantage is that avoiding collisions will result in a less consist progress toward the goal position. The reactive method that is implemented for MI20, showed that reactive collision avoidance is quite successful, but the ability to reach a target in time is worse compared to deliberative motion.

1.4

Problem definition

The methods for achieving motion that are described above, both have their advantages and disadvantages. The focus of improving motion control is mostly on the method of deliberative motion. In robot soccer it is beneficial to be able to move a robot towards a position within a specified time limit. Using a deliberative method will ensure that the time of arrival can be estimated in advance, which is required for shooting a moving ball. This is only possible, when the deliberative method is also able to produce collision free motion. The existing deliberative method has the following problems: • The planning of S-curves does not take obstacles, other than the field boundaries, into account. • The method for path coordination of team robots, that temporarily lower robot velocity to avoid collisions works well for vehicles performing a deliberative motion. This does not work with team robot that perform a different task, or are stationary • At the control level, path tracking is performed without consideration of the local environment (clogged up areas, field edges, a team mate standing still)

1.5 Objective

1.5

6

Objective

The research topic of this thesis is the improvement of collision avoidance at the planning phase. We are interested in a method to predict collisions between robots of the own team, when planning paths. We attempt to reach this by estimating trajectories of the vehicles and, testing these for intersections. Aspects that are of interest: • At what accuracy can collisions be predicted? • Can the s-curve planning benefit from collision predictions? This is researched as follows. A method for testing two given trajectories is developed in a simulated ideal environment. Next an attempt is made to predict a trajectory of a robot, by estimating a velocity profile and combining this with the planned curve. Two estimated trajectories are used in the developed collision test. The forecast results are tested for accuracy.

1.6

Thesis outline

In the following chapter the current state of the MI20 system is explained with specific attention to motion control. In chapter 3 more background is provided on methods available to avoid collisions, which are divided in collision free planning and reactive collision avoidance. The method employed in this thesis for predicting collisions in the planning phase is discussed in chapter 4. The development of a collision forecast module and its integration in the MI20 system is discussed in chapter 5. The accuracy of the collision forecasts and the result from the collision free curve selection is discussed in chapter 6. Finally my conclusions are given about the success of reaching the objectives.

Chapter 2

The MI20 system 2.1

Hardware setup

As stated earlier, the Mirosot games are played using a camera above the field that is connected to a central computer. After processing of the images, and determining the desired motion the central computer sends wheel velocities to the robots using radio communication. Below we list some essential details of the hardware components to understand the way the MI20 system is working. Camera A Sony digital camera is used that uses the ieee1394 (Firewire) interface. It produces thirty color frames per second. Communication Communication between the computer and the robots is done using Radiometrix BIM Transceiver Modules. Robots of the same team use the same transmission frequency. The frequencies used are 418MHz and 433MHz. The sending radiometrix module is connected to the RS232 interface of the computer. Data packages are broadcasted to all the team robots. Each of these packages contains the wheel velocities for all the robots. Central computer The robots are controlled by one or more PC’s that run a Linux operating system. The software structure, that is explained in the following section allows to distribute parts of the control software among different computers, in a transparent way [22]. With the current system a single computer is sufficient.

2.2 Software structure

8

Robots The robots used have differential drive1 locomotion. This allows the robots to turn on their place, which makes them very fast maneuverable. The robots of the MI20 team are bought from the University of Dortmund, where they were designed and built for their robotsoccer team. Each robot has an identifying number, assigned with three dip switches. The robot has an onboard controller that receives and analyses data packages that are transmitted with radio communication. The same data package is broadcasted to each robot, and contains wheel velocities for each robot. The controller of the robot determines which part of the data package is to be read, using its id number. The controlling computer continuously sends the desired wheel velocities to each robot. The robots onboard controller, attempts to drive the wheels to the received velocities using a PID control loop. Color patches In Mirosot each robot is required to have a color patch at the top side, that contains either a yellow or a blue region, dependent on the team that the robot belongs to. This so called ”team color” must cover at least thirty percent of the top side. The remaining part may be designed freely. These color requirements are needed to identify robot positions on the camera images, and to be able to distinguish the robots from both teams. Some teams use more colors on their color patches or use different unique patterns to allow identification of individual robots from a single camera image. The MI20 team has chosen to use identical color patches for all robots. One half of the color patch being the team color, the other half being always green. This two-color scheme makes the color patch identification easier, but robot identification from single camera images is not possible. As a consequence robots have to be tracked in subsequent images to distinguish them consistently.

2.2

Software structure

The current MI20 software has been designed according to a modular setup with a multi-agent architecture. The functionality needed to control robots has been divided in modules each with its own distinct and clear responsibility. Interfaces were thought out to allow transparent communication between modules. The system makes use of a data sharing framework [22] that was designed for application in the MI20 system. 1

See [7] for details on differential drive


9

Figure 2.1: Simplified overview of system modules In figure 2.1 a simplified overview is shown of the MI20 system structure containing the most important modules and their interconnection. Here follows an explanation of each module. Vision The vision module processes camera images. Every 30th of a second the camera produces a color image of the playing field. Each frame is filtered using color segmentation for the color of the ball and the color patches of the robots. The colored sections in the camera image are then mapped to field coordinates, using a projective mapping obtained by camera calibration. In


10

this way the position and orientation of the team robots are known. The characteristics of the opponent color patches are not known in advance. It contains either a blue or a yellow region (dependent on the color chosen for the team). By recognizing a single color region, the position of opponent robots can be estimated, but not the orientation. The vision system delivers as analysis result a data structure, that contains the position of the ball and the opponent robots, and position with orientation measurements of the team robots. These values are relative to the field coordinate frame. Details can be found in [12] and [19]. State estimator The state estimator has the task to provide a consistent and up-to-date representation of motion state of all objects. Measurements of ball and vehicle positions and orientations are subject to measurement noise. In order to acquire a more stabilized representation an extended kalman filter is used. Also the derivative of the orientation and position is calculated, which is the linear and angular velocity. As mentioned, the MI20 team robots have similar patches. After recognition their states are known, but not yet their identities. A robots identity is determined based on its previous location and the predicted position from its last measured velocity and/or control input. For this to work, initially the identities need to be set manually, or in an automated routine referred to as the Identify skill. When using this routine, each robot in turn will receive a command to change its orientation. The order in which the robot orientations on the camera images change determines which robot listens to which identifier. In the case of own team robot measurements, the way they are controlled is known, so the control input of the robot is used in the state estimation. Details can be found in [12] and [19]. Player and Coach The Player module functions as agent that controls a single robot. It is divided in two parts, that communicate through a shared data structure. One part is responsible for making decisions on the behaviour of the robot. The other part does the motion control decisions concerning the selection of the strategic plans to execute and the assignment of roles for each player are coordinated using an intermediate agent called the Coach which is also implemented as a separate module. When each player is assigned a role and has a plan for the actions that it has to take, the decision layer communicates this to the motion control layer of the player process. The motion control layer provides a set of skills that can be executed by the robot. Some example skills are:

2.3 Motion control in MI20

11

• Move to position with orientation • Move behind ball and shoot towards goal • Shoot ball in any direction • Spin on the place • Stand between ball and goal The decision layer uses these skills to complete its assigned task. The shared data structure consists of a skill queue. Commands from the decision layer are put on this queue. Multiple commands can be put on the queue, and will be executed in sequence. The motion control executes a command until either the goal conditions are fulfilled or the command is removed from the queue by the decision thread. The motion control thread is stateless. All state information is contained in the skill queue, which provides a transparent service to the decision thread. User Interface The user interface process is the supervising process of the system. Here the game state is controlled. When the system pauses or closes, a corresponding signal is sent to the other processes, which will respond accordingly (pausing or shutting down). The user interface provides the user with valuable feedback. The world data is constantly drawn on a screen with current control information. RF communication This modules receives the wheel velocities for each robot from the player processes. Theses values are wrapped in a single package that is broadcasted to all the robots, using radio communication. Each robot retrieves the velocities from the package, that are addressed with the robots id number.

2.3

Motion control in MI20

Two different implementations exist in the MI20 system for moving towards a target on the field. These methods are developed independently and can be selected alternatively by the decision layer using a different command. One of these methods is a reactive method, while the other is deliberative (see section 1.3).

2.3 Motion control in MI20

12

Reactive approach A reactive approach was developed that makes use of the Vector Field Histogram (VFH)[5]. Motion is planned in the form of a target position (goal-motion). This method produces steering commands that follow a hypothetical vector field that is target dependent. This field is influenced by repulsive forces from obstacles such as robots, the field boundaries and if necessary the ball. The goal position and direction has an attractive influence on the vector field. The robot that is controlled with this method eventually reaches its destination in the desired orientation. This method of motion proved successful in avoiding obstacles, but lacks in deliberative control. Due to the obstacle avoidance, the robots tends to hesitate in proceeding towards their target. Deliberative approach Motion planning in MI20 is focused on the dynamic aspect of the environment. In robotsoccer the robots move constantly around the field. Situations occur where robots are standing still due to hardware problems or obstruction by others. In such cases, these robots could be considered as static obstacles, and corresponding planning strategies could be employed. It is chosen to use a simpler and faster method, that does not take static objects into account. This is the S-curve planning algorithm [26]. An S-curve is a type of curve that describes a path that would bring a vehicles from its current pose (position and orientation) to its goal pose. The S-curve is a Dubins2 curve. The first and last segments have the purpose of changing the orientation required for the start and end pose respectively. The middle segment is a straight curve for passing the distance as fast as possible. S-curves are meant for driving in a fluent motion, and reaching a target location with a desired velocity and orientation, to allow shooting actions. Figure 2.2 show the four S-curves that allow a vehicle to travel from a start location to a goal location.

Figure 2.2: Four S-curves between start pose and end pose Note that there exist four S-curves between two poses, while there are six Dubins curves (see [6]). The two Dubins curves that are not used, are the 2

A Dubins curve consists of straight line segments and arcs of maximum curvature

2.4 Simulation

13

combinations of three arc segments. These combinations can be used when a vehicle needs to maneuver to a different orientation very close to the original pose. There is no need for that because differential drive vehicles like our robots can simply turn on the place and drive to the desired location. The vehicle will travel towards its target by following the S-curve. Three kinds of path trackers have been implemented, namely a PID tracker, a pure pursuit (follow the carrot) tracker and a vector pursuit tracker. Avoidance of dynamic obstacles during the planning is not taken into account. During path tracking collisions between team robots are avoided by slowing down either of them.

2.4

Simulation

Instead of playing with actual robots on the playing field, a simulator can be used for development purposes. The camera, robots, ball and radio communication are replaced with a software simulation of their function. When certain parts of MI20 need to be tested, it can be very convenient to assume certain physical aspects of a robotsoccer game to be ’ideal’. In the real world, for example the position and orientation of robots and the ball on the field are subject to measurement noise. Also there will be a delay in sending a command to a robot, and noticing the result of the command on the camera images. By using simulation the effect of different disturbing factors can be judged at will. The behaviour of the robots onboard controller is also an aspect that needs to be simulated, since the velocity sent, and the actual velocity will differ. In the simulator the response on the sent wheel velocities should comes close to the response of actual robots. Next the interaction between robots, ball and field boundaries need to be simulated. Finally the measurement of new robot positions and orientations need to be done. For our system two simulators are available, one of which is the FIRA simulator. This simulator is actually part of the SimuroSot League. This simulator has the ability to use 3rd party DLL’s that contains strategy routines. These routines are capable of applying forces to the wheels of the robots, and are provided with positional data of the robots on the field. A DLL is made to allow the MI20 system to communicate with this simulator. This simulator has the disadvantage that it runs for only five minutes, and stops whenever a goal is made. This makes it suitable for practicing robotsoccer matches in an ideal environment, but not for testing of basic functionality. A different simulator is developed by R. Heddema of the MI20 team to allow testing of various aspects of the software, while having full control on the amount of measurement noise, and delay in measurements. The robots behaviour is simplified. When the robot receives a reference speed,

2.4 Simulation

14

it attempts to reach this speed using a constant acceleration, while keeping the curvature during the acceleration phase intact. In the physical model of the environment (robots, ball, field) collisions, friction and inertia are aspects that are ignored. Also the measurement of position and orientation is assumed to be absolutely accurate.

Chapter 3

Collision avoidance methods In order to avoid collisions for moving vehicles, collision avoidance must be an integral part of motion control. There can be no strict separation between avoiding a collision and driving a vehicle. Improving the collision avoiding ability means introducing new methods of motion. Generally speaking collision avoidance can be integrated at different levels: in the motion controller, the planning system, and the task scheduler.

3.1

Reactive collision avoidance

At the control level, reactive methods can be used for dynamic collision avoidance. In these methods, the local environment state is used to produce motion commands that steer towards the goal while avoiding obstacles. Each method contains the following two aspects: A way of analysing and interpreting environmental data, and a motion strategy to use this information to generate motion commands[17]. In collision avoidance methods these aspects can exist as different steps in an algorithm, but it is also possible that they are integrated in one single calculation. Here follows a short overview of different ways of approaching the problem, that have been used in existing methods. Potential field methods In these methods the environment is modeled as a potential field. The motion of the vehicle is made as if the vehicle was a particle moving through the field. Obstacles apply a repulsive force on the particle while the target location has an attractive force. The sum of all forces determine the direction and the velocity. Variations on this theme exists like the Virtual Force Field(VFF) and the Vector Field Histogram(VHF).

3.2 Deliberative planning of collision free paths

16

Curvature Velocity Methods In these methods the field of solutions (velocities) is analysed [23][9]. The polar velocity representation contains a linear(tangential) velocity and a radial velocity. A polar velocity field contains all different combinations of linear and angular velocities. For any moment in time the admissible velocities of such a field are considered. These velocities still allow the vehicle to do an emergency stop after the time interval. Finding a solution velocity is done by considering three aspects: The vehicle must progress to the target. The vehicle must be safe from obstacles. The vehicle must not decrease speed unnecessary. A useful method must fulfil all three aspects to some extent. This method assumes that the velocity is constant during some time interval. This simplification has less influence when the time interval is relatively short. The Dynamic Window Approach [9] employs the same idea as the Curvature Velocity Method[23], but also takes dynamics into account. A vehicle that drives at a certain linear and angular velocity, can not change its velocity to any other value instantly, due to object inertia. Velocities close to the current velocity can be reached in a shorter time. Solutions are sought in a so called ”dynamic window” around the current velocity in curvature velocity space. Elastic Bands Elastic bands is not really a pure reactive collision avoidance methods. It is meant to bridge the gap between deliberative motion planning and reactive control. The planned path is deformed in a smooth way (similar to elastic bands) to avoid collisions in a changing environment. [18] Motor Schema Motor schema is way of letting different behaviours (schema’s) work in parallel. Each behaviour produces a velocity vector, that has an influence on the resulting velocity vector. The combination of all velocity vectors determines the resulting motion command[1].

3.2

Deliberative planning of collision free paths

The problem of collision free planning of multiple robots is thoroughly described in [13],[15] and [11]. The methods of planning can be divided in centralized planning approaches and decoupled planning approaches.

3.2 Deliberative planning of collision free paths

3.2.1

17

Centralized planning

In centralized planning the problem of planning paths for multiple robots in the same workspace, is considered as planning a path for a single articulated robot. Each robot can move independently through the same space and thus a composite configuration space describes the free states for each robot. Performing centralized planning consists of finding a collision free trajectory for each robot within the composite configuration space. Approaches for finding solutions in configuration spaces can be classified as Roadmap, Cell decomposition and Potential field methods (see [13] for details). Dependent on the method used to find a solution, the optimal solution can be found if it exists. The disadvantage is that searching through a composite configuration space is computationally intensive, and time complexity increases exponentially with the dimension (i.e. number of robots)][13].

3.2.2

Decoupled planning

The decoupled approach to planning reduces the time complexity for finding a solution, which makes it a more practical in applications. Instead of searching for a solution to the entire problem, it is divided into smaller problems, that can be solved independently in less time. This comes at the cost of losing completeness and optimality. A decoupled approach may not find a solution, even if it exists. In decoupled planning, two approaches exist, namely path coordination and prioritized planning [13]. Path coordination With path coordination (also known as path/velocity decomposition), each robot plans its geometric path, independently of the others. This can be done using path planning methods for single robots in environments of static obstacles (roadmap, cell decomposition, potential fields. see[13]). After this step, the velocities of the robots on their paths are coordinated, to avoid collisions. When two vehicles are about to collide, either of them adjust its velocity to prevent the collision. In this way the original problem is decoupled into two steps: first the planning a path for each vehicle, and second the setting and adjusting of the velocities of the vehicles along their paths. Although this method is very efficient with respect to processing time, the resulting trajectories can be quite inefficient, since avoidance in time is used, while avoidance in space is ignored. Prioritized planning Prioritized planning is originally proposed in [8]. This method can be used for both mobile robots and articulated robots. In prioritized planning the

3.3 Task assignment

18

problem of planning for n multiple moving objects in the same workspace, is reduced to planning the trajectory of a single vehicle, where x (smaller than n) trajectories are already known. In this way, each trajectory is planned in sequence. The first trajectory only takes static objects into account. The last trajectory takes into account all previously planned trajectories. Prioritized planning consists of two problems. Determining an efficient priority order, and planning a collision free trajectory in the presence of x other trajectories. The priority order can be made randomly, or a method for efficient ordering can be used (as presented in [25]). To find a collision free trajectory, a configuration time space can be constructed with the static obstacles and the existing trajectories. This space can be analysed for example with a cell decomposition method. Although this method is more suitable for applications with time-constraints than a centralized approach, there are situations where no solution is found even though it exist. The trajectory of an object with higher priority can result in a lower priority vehicle not being able to plan a trajectory. In such cases the trajectory of the higher priority vehicle needs to be revised, in order to find a solution for all vehicles. This can be done by for example using backtracking. This obviously comes at the cost of more processing time.

3.3

Task assignment

For multi robot systems that consist of homogeneous robots (like robotsoccer) robots are interchangeable. A task that is assigned to one robot can also be performed by another. For these systems it is desirable to achieve the most efficient assignments of tasks among the team members. When this assignment is made it may be the most optimal for that moment, however during the course of time better assignments are possible. Changing roles of robots allows to keep the assignment most efficient. Aspects that need to be considered is whether the team is controlled centrally or has a distributed control where each member functions more or less independently. In some cases, not every robot can communicate with all other robots and information sharing by means of rendezvous is required. Robot meet at specific locations to interchange information. Task switching in these cases can have a major influence on overall system performance. Predicted of collisions for planned trajectories of robots, can be useful information to provide to the layer of task assignment of the multi robot system. When different tasks are evaluated, collision information for possible trajectories can give a better value estimate of a task. When a collision can be prevented by task assignment the decision system can decide to do so, else the collision avoidance is handled by the lower levels of planning or control. In [16] a system is described that implements role switching in a multi agent environment.

3.4 Collision avoidance in robot soccer

3.4

19

Collision avoidance in robot soccer

In this chapter several methods are explained to avoid collisions. In robot soccer a collision results in inefficient task execution. The goal is to improve the task execution, and in this way the game, scoring opportunities, results, etc. Avoiding collisions is only a way to reach this. Collisions should not be avoided at all costs. It is obvious that efficiency should be not sacrificed to avoid collisions. To illustrate: if we would reduce the velocity of the robot, reactive collision avoidance method will be more successful. There is in that case, however no improvement in playing robot soccer. Path planning in robot soccer As explained earlier, the MI20 system makes use of a method based on path coordination (See 3.2.2). The robots receive commands in the form of a target pose. An S-curve is planned to reach the target pose from their current pose, which is done for each robot independently. During the tracking phase all robots are going to coordinate their path traversal by adjusting their velocities. The prioritized planning method has a good potential for use in a robotsoccer system. Whenever a robots attempts to plan a trajectory it accepts the previous planned trajectories as known dynamic obstacles. In robotsoccer a robot can receive a new motion command at any time. This gives a natural ordering in the planning of paths. Reactive control A smart combination of path navigation, and reactive collision avoidance, may result in a method that is better able to avoid robots. In the case of controllable robots, bilateral avoidance is possible. Any of the earlier described method may be useful, as long as it is possible to execute without too much computational overhead.

Chapter 4

Collision prediction This chapter presents a method to predict collisions by means of forecast. A forecast is made on the basis of the predicted motion trajectories of two vehicles. The first section describes the motion trajectory of a vehicle, and how it is estimated. The following section deals with a forecast computation with two such trajectories.

4.1

Motion trajectory

A motion trajectory describes a vehicles path through space and time. It can be described as a function that gives the position on the vehicles geometric path at every instant. In this way it contains the path, as well as the velocity of the vehicle. Trajectories are used with motion planning in dynamic environments as explained in section 3.2. In this area trajectories are often generated or represented in Configuration Time space (CT-space), to determine collisions.

4.1.1

Trajectory description

In the MI20 system paths are planned with S-curves, as explained in section 2.3. These curves are described piecewise in segments of constant curvature. Each segment is determined by a start pose (position and orientation), curvature and segment length. In this way the complete curve is described as a sequence of < pose, R, len > tuples with R being the curvature radius. The time aspect of a motion trajectory is described in the form of a velocity profile of the vehicle along the path. In robotsoccer, vehicle’s accelerations can not be assumed to happen instant. Therefore acceleration should be taken into account in the velocity profile. It is chosen to describe the velocity profile piecewise in terms of constant acceleration. The trajectory is formed by the combination of the geometric path and the velocity profile. It is described piecewise in segments of constant cur-

4.1 Motion trajectory

21

vature and acceleration. Each segment is determined by a start pose (position and orientation), start velocity, curvature acceleration and segment length. In this way the complete trajectory is described as a sequence of < pose, R, len, a > tuples. Figure 4.2 shows the resulting trajectory of combining the velocity profile and the S-curve from figure 4.1.1. The route progress graph is acquired from integration of the velocity profile. The trajectory graph is made as follows. The (route length, pose)-relation can be derived from the S-curve. Next the (route progress, time)-function and the (route length, pose)-function are combined in a (pose, time)-function. Figure 4.2 shows the (pose, time)function where each instant the space is shown that is occupied by the robot. The change of acceleration in time can be described in a more accurate way. In the case of so called clothoids it is described as a linear function. This would give an even finer precision in describing the velocity aspect of the trajectory. We expect that this refinement of accuracy will not result in a much more realistic description of the trajectory. That is because other aspects like errors in camera measurement, communication delay, and loss in gear transmission influence the actual trajectory.

4.1.2

Prediction of a motion trajectory

The robots motion needs to be represented in terms of a trajectory description as specified. We assume that the robot will follow its path without deviation. The position of the vehicle at any give time, however, is something that needs to be predicted by estimation. A realistic prediction requires understanding of the aspects of the velocity control of the robots motion. In that way, the motion behaviour of a vehicle can be specified sufficiently accurate. Velocity control The velocity of a robot is controlled through a cooperation of two systems. The MI20 system determines and sends the desired velocity to the robot. The robots onboard controller attempts to reach this velocity through proportional, integral and differential control. In this cooperation the acceleration is handled by the robot, while the deceleration is handled by the MI20 system. The MI20 system immediately sends the maximum velocity, when needed. The sent velocity is anticipatory decreased by the MI20 system when the robot approaches the end of the path(segment). Each curve segment has an assigned linear velocity that is often also the maximum controllable velocity. The path tracker always takes this as the linear velocity to be sent to the robot, unless deceleration is required, for


22

(a) An example S-curve

(b) A velocity profile of a vehicle driving on this curve

(c) The (route progress,time)-graph

Figure 4.1: An S-curve (a), a velocity profile (b), and the route progress in time (c)


23

Figure 4.2: The trajectory in CT-space shown with the vehicle’s occupying area in (x,y)space

4.2 Forecast computation

24

example before reaching the end of the curve. In that case the velocity is decreased linearly with the distance to this position. The velocity profile is estimated as follows: An acceleration phase in the actual velocity course of the robot is described as a single section of acceleration. Also the deceleration phase is estimated as a single section of acceleration. The proper acceleration and deceleration values are found through trial and error, by comparing measured route progress - graphs with estimated ones. The sequence and length of acceleration segments that make the velocity profile are calculated from the velocity assigned to each curve segment. Calculation of a velocity profile The velocities assigned to each curve segment can not be reached in many cases, because often the segment is shorter than the distance needed to reach this velocity. To calculate the velocity profile the reachable velocities must be used. For each transition of segments, the velocity is determined. This is initially the minimum of the velocities of both segments. This minimum is decreased to a lower velocity, if in the next segment more deceleration is required than possible, to prevent unsafe situations. The transition velocities are used to divide curve segments in segments of acceleration There are actually three possible ways of setting acceleration transitions (see figure 4.3). In the case that either the start or the end velocity of a segment, equals the maximum velocity of that segment, one acceleration segment is not needed. • The end velocity can just be reached by full acceleration from the start. This segment is corresponds to one segment of acceleration. • Acceleration is allowed, but the maximum velocity can not be reached. Deceleration is done to make sure the end velocity is reached. This segment can be divided in two different acceleration segments. • The section is large enough to accelerate to the maximum velocity, drive with constant speed , and decelerate to the end velocity. This segment is divided in three acceleration segments. In the case the start and/or the end velocity are equal to the maximum velocity, two or three of the parts are combined in one.

4.2

Forecast computation

A forecast is made by determining the intersections of two estimated trajectories. This section describes an algorithm to determine the intersection using the trajectories introduced in the previous section. This algorithm


25

Figure 4.3: Three situations for dividing a curve segment in acceleration segments uses the trajectory of two vehicles including their two dimensional shapes, and calculates the time and position of the first intersection. The algorithm consists of two parts. One part is consists of a geometric analysis for collision states in configuration space (s1, s2) (the cartesian product of the route length of each path). The method used for this is


26

a part of the Roadplan simulation tool [20]. The other part consists of the calculation of the joint trajectory through the same configuration space.

4.2.1

State space analysis

This analysis determines the collision states in the configuration space of the vehicles’ positions. Figure 4.4 shows two vehicles that are in collision. The length of the route section that both vehicles have traversed is shown as a position in the configuration space. The white sections in figure 4.4(b) show the states where both vehicles have collided. The orange and magenta lines in 4.4(b) correspond to the vehicle positions on their routes in 4.4(a) (screenshot taken from Roadplan). The configuration state space of the vehicles’ positions is analysed using a quadtree method. It divides 2D configuration state space in areas of no-collision, full-collision, and partial collision. Areas of partial collision are subsequently divided further. This analysis can be performed on the entire configuration space, or a smaller region of interest. Analysis continues until the collision states of the target space are identified at the desired granularity. This method is described more thoroughly in [20].

(a) Collision of two vehicles in space (b) Collision of two vehicles in state space

Figure 4.4: Two vehicles on their path, and the corresponding configuration state space

4.2.2

Joint trajectory analysis

The trajectory of both vehicles result in the configuration state ( both vehicles positions) to follow a course through the configuration space. This course is referred to as the joint trajectory.


27

The velocity profiles of both vehicles are used to determine the joint trajectory through the same configuration space as employed in the state space analysis. The configuration space is divided by the velocity profiles in a grid where in each cell both vehicles have a constant acceleration (see figure 4.5). The joint trajectory within a single cell is now explained.

Figure 4.5: The configuration space of the route positions (sX,sY)) is divided in cells with constant acceleration The state of a single vehicle consists of the position on its path (route coordinate) and a velocity. Equations 4.1 and 4.2 describe the vehicle state at time t on a section of constant acceleration. Inversely, the time that a vehicle reaches position s can be calculated with equation 4.3. The inverse consist only of the positive root, because increasing the distance (st − s0 ) should always result to an increase in time.

s(t) = 0.5at2 + v0 t + s0

(4.1)

v(t) = at + v0

(4.2)

t(s) = (−v0 +

q

v0 2 + 2a(s − s0 ))/a

(4.3)

A joint state is the state of both vehicles at the same time. In that way it is a vector that contains the position and velocity of both vehicles. To determine the joint state the position of one vehicle can be expressed in terms of the other (see equation 4.4). The initial joint state is set by the initial position and velocity of each vehicle. The course of the joint trajectory through a cell of the path segmentation grid as shown in figure 4.5 depends on the acceleration of both vehicles in that cell. The entire joint trajectory can be


28

calculated by continuously calculating the joint state at the end of the a cell, and using the joint state in the next cell. sx (sy ) = 0.5ax t(sy )2 + vx,0 t(sy ) + sx,0

4.2.3

(4.4)

Collision calculation

A collision is found, when an intersection occurs between a joint trajectory and an collision zone in configuration space. Since the joint trajectory calculation and state space analysis are more or less independent, there are different ways to use them to find such an intersection. One method consists of finding all collision zones and comparing them with the trajectory. At first all collision zones are marked as collision candidate. While the trajectory analysis proceeds, it becomes clear that certain zones are unreachable with the joint trajectory and can are filtered out. This method finishes when all existing collision zones are unreachable, or when a first collision is found. The advantage of this method is the joint trajectory does not need to be calculated, when no collision zones exist. Also, in some cases the joint trajectory is only partially required. This depends on the amount of collision zones, and their position in configuration space. A disadvantage is that the collision zones of the entire configuration space need to be determined prior to this method. This can be a computationally intensive task for complex paths with multiple intersections.

Figure 4.6: The collision zones that are passed by the joint trajectory can not cause any collisions.

Another method is to determine the joint trajectory first, and limit the


29

state space analysis to the cells that are traversed by this joint trajectory. Each element of the trajectory, which is a rectangular region of state space, gives the area of interest for the state space analysis. The benefit of this method is that less areas need to be analysed for collision states. The drawback is, that the entire trajectory and its corresponding state space needs to be calculated.

Figure 4.7: Only the cartesian zones that contain the joint trajectory, need to be analysed for collision states.

Of both methods the latter is the most economical with collision zone analysis, which is more computationally intensive than joint trajectory analysis. However, in some cases the first method can determine very quickly that no collision zones exist, which ensures that the joint trajectory is not needed.

Chapter 5

Development The development of the method of forecast is divided in two parts. At first the computation of the collision points is thought out and implemented as an extension to Roadplan. Next the core routines of Roadplan are used within a software module that is newly introduced in the MI20 system. The application of the forecast module is done in a new planning strategy. This strategy is made to test the use of the collision forecast.

5.1

Roadplan extension

Roadplan is a simulation tool that allows to describe routes that are build up from segments of constant curvature. Multiple routes can be combined to form nets. Automatic Guided Vehicles (AGV’s) can be defined in shape as a rectangular and/or circular form. These agv’s can be placed on routes, and in such way used in the simulation. Each vehicle has a constant velocity that can be changed manually. Roadplan contains a method to analyse two routes for collision states as described in 4.2.1. This is an ideal environment to develop the forecast algorithm. It is required however to introduce the concept of speed, as the existing algorithms are used for static road analysis that is independent of speed. An extension to Roadplan is made that makes it possible to specify a velocity profile for an AGV. The velocity profile can be described as a list of accelerations, one for each segment, or as a list of velocities at the transition points between segments.

5.2

Forecast module

The idea behind the introduction of forecast is that collision information would be made available. In the modular design, as described in section 2 the player modules would benefit from it the most, since they own the responsibility of path planning, and tracking. In the description of the MI20

5.3 Application of forecast

31

system, the decisions are also part of the player modules. It is not unthinkable that the coach module will be responsible for decision making.

The method of communication with the forecast module, is based on a client/server relation. A forecast request is made, the request is fulfilled, and the result will be sent back as a response. The forecast module keeps track of existing trajectories of all players and the time that they started. Each player process has its own path planner and makes a forecast requests for the path it wants to use. The forecast module estimates a trajectory for the path it received. This trajectory is tested against the existing trajectories. The collision result are subsequently sent back to the player process. Therefore the forecast module has for each player process a communication line to the forecast module. Besides a forecast request, the players should also provide the current path that they are following. The forecast module has the responsibility to test a request with the current set of paths. The internal structure of the forecast module is made, by defining a set of responsibilities and using them to create a class diagram. The following responsibilities are identified: 1. Creation and handling of communications 2. Selecting requests, forwarding it for handling it, and returning the result 3. Providing transparent access to Roadplan routines 4. Description of a trajectory. 5. Keeping track of all existing trajectories and performing collision tests for candidate trajectories. 6. Creating a trajectory from a given Path by estimation of the velocity profile. These responsibilities are used to create a class diagram and an implementation. An overview of the created classes is listed in Appendix A.

5.3

Application of forecast

The forecast of collisions between planned trajectories can be used at different aspects of robot soccer control. In motion planning, a trajectory can be tested whether it is collision free or not. Motion control can make use collision information to control bilateral avoidance between vehicles.


5.3.1

32

Motion control

At the level of motion control information is available on the planned collisions. The paths are known that have a collision. The angle at which the vehicles will drive towards each other, and also their relative position at the moment contact. This makes it possible to determine the bilateral deviation to avoid this collision. Provided that the forecast is accurate enough to give this information with certainty. Details on how to achieve this are left unknown for the time being.

5.3.2

Path planning

The existing path planning method evaluates four S-curves that connects a start pose and a target pose. The S-curve that has the shortest length is used. Using a forecast on the estimated trajectories of these paths gives more information on the efficiency of them. The motion trajectory, if it is accurate enough, can provide the time to completion of the path. S-curve selection that was based on the length of paths can be based on the finish time instead. A different planning strategy is possible by testing paths for collisions. The forecast results provides information will tell which paths may result in a collision, and at what time that would occur approximately. Selecting collision free curves instead of the shortest ones, result in the avoidance at control level not being necessary at every motion execution, which makes the resulting trajectories more consistent with the planned ones. Collision free paths do not always exist however. The following options can be done to deal with this situation: • It can be decided to plan the curve with the latest collision, expecting that the forecasted collision will not occur. • An alternative is to reconsider the decision of driving towards this target. Clearly a direct path towards the target is not feasibly. Planning around the collision may be an option. • The original planning method: the curve with shortest length can performed. New planning strategy An new planning strategy is made that uses the forecast module to test for collisions on the S-curves prior to selecting them. In each planning phase, the four possible S-curves are generated, and sorted to path length. At first the shortest curve is tested. If the curve is collision free it is selected, else the second shortest curve is tested. This process is repeated for each of the


33

four curves, until either a collision free curve is found and selected, or all curves are predicted to cause a collision, in which case the shortest is curve is used. This planning strategy is devised to test whether the planning of curves can be optimized to allow more efficient execution of motion. The existing method of collision avoidance that decreases the velocity of the robots temporarily, is necessary in less motion action. In the long run this would result in a higher overall velocity, which may prove more efficient when selecting curves with a not optimal length. This efficiency is subject to testing

Chapter 6

Testing & evaluation A method for predicting collisions has been implemented in the form of a forecast module. The calculations were tested prior in the Roadplan simulation tool. To evaluate the forecast, the following aspects are of interest. How accurate is the prediction of a motion trajectory? What is the certainty of a collision forecast? What is the improvement of the deliberative motion skill of the MI20 system?

6.1

Motion trajectory accuracy

The method for collision forecast is based on the motion trajectories of the vehicles that are evaluated a priori. In the MI20 system, trajectory based feedback control is not (yet) implemented, and estimation of trajectories is used instead, as explained in 4.1. The accuracy of a collision forecast depends partly on the accuracy of a motion trajectory. To view the quality of the trajectory estimation, a route position-time graph of an robot is made, moving across the field and this is compared to the trajectory estimate. Test method The route position-time graph from the actual trajectory is acquired as follows. A single robot is placed on the playing field. The MI20 system is calibrated and ready. The robot is given a deliberative motion command. A motion trajectory is derived from the planned S-curve and the estimated velocity profile of the robot. The route position-time graph from the estimated trajectory can be acquired fairly easy using the simulation function of Roadplan, or the Ctrajectory class. Next the planned S-curve path is tracked with the vector pursuit tracker. During the path tracking the trajectory progress is stored, as time - route position values. The time is stored using the system clock. The route

6.1 Motion trajectory accuracy

35

position is determined, using the position measurements of the MI20 system. It is set as the point closest to the current position of the robot centre on the reference path. This process is repeated for different curves. The positional deviation of the robot from the reference path is not exceptional, so that the trajectory error is fairly representative for other estimated trajectories. The trajectory error is also measured for the MI20 system when using the simulator. To test if in the simulator the vehicle behaves in a similar fashion during path tracking, the trajectories from the simulator are compared with the ones from real robots. Results In the graphs listed below the trajectory accuracies are shown. The planned S-curves and the tracked ones are shown in figures 7.2, 7.3, 7.4 and 7.5 in Appendix B. The difference in route position at the same moment in time is considered as the trajectory error, while the path deviation is not considered. When comparing the figures 6.1 and 6.3 with respectively 6.2 and 6.4 it becomes clear that the accuracy is better with S-curve with a large radius. The reason for this, can be that the vehicle has one acceleration and one deceleration phase, because it can travel at full speed the entire trajectory. The figures created with the simulator show a better accuracy, than with real robots, as can be expected from an ideal environment. The difference is however considered acceptable. Evaluation As shown in the created graphs, the trajectory estimate has the largest error at the deceleration stages. This can be explained as follows. The deceleration when the robot slows down is not constant but decreases in time, to have control on reaching the desired velocity at the end of the track. This deceleration is assumed to be constant at the trajectory estimate. The time of arrival of the actual trajectory is significant longer. Using the trajectories for determining the feasibility of a path can only be done when this error is taken into account. It is possible that it has a rather small influence on the forecast accuracy, because the deceleration error increases at the end of the trajectory, where velocity is much lower compared to the maximum velocity. At the end phase of the trajectory, the position will not change significant so that it may not make a difference between collision or no collision in most of the case. This needs to be tested however.


36

Figure 6.1: Trajectory estimation accuracy. Created in simulator and Scurve with large radius (30cm)

Figure 6.2: Trajectory estimation accuracy. Created in simulator and Scurve with small radius (15cm)


37

Figure 6.3: Trajectory estimation accuracy. Created with actual robots and S-curve with large radius (30cm)

Figure 6.4: Trajectory estimation accuracy. Created with actual robots and S-curve with small radius (15cm)

6.2 Forecast accuracy

6.2

38

Forecast accuracy

In order to provide an useful forecast, the error of the motion trajectory should be acceptable. Section 6.1 considered the prediction errors of a single trajectory. The accuracy of a forecast depends on the error of the joint trajectory, and the round off error of the quadtree analysis of collision states of the paths. An indication of the accuracy can be made by determining how often the collision forecast gives a right prediction. Here is of interest, whether the forecast was wrong in the cases where a collision was predicted or the joint trajectory was supposed to be collision free. To do this, the collision forecast is made for two planned paths, followed by the tracking of the paths, and testing for actual contact between the vehicles. Test setup This test is performed using the simulator. Collisions are not modeled within the simulator. This has the advantage that the test can proceed after a collision without the need to place the robots at new start positions. The original S-curve planning is used, where the selected curve is sent to the forecast module, to produce a collision forecast. Next the robots drive along the planned curves, while a collision detection is executed. To detect collisions the distance of robot to the other robot is monitored. The shape of the robot is simplified to a circle fitting around it. If the distance between two robot is smaller than twice the radius, the robots are in contact. Two robots are used for testing. Motion commands are executed to a random position within a preset region (see figure 6.5). The playing field is divided in four quadrants. Each robot drives from a position in one quadrant to a random position in the opposite quadrant. In this way, all kind of combinations of crossing paths will be included, while most of the paths will have an intersection. The regions do not connect, so that the initial or end position of the two paths will not coincide. Results At first the forecast quality was tested by performing synchronized motion. Both robots execute a motion command. When both are finished, they can proceed to the next motion command. This is done to make the testing easier with the MI20 system (an implementation detail). In table 6.1 it can be seen that about 40 percent of the predicted collisions does not happen when the motion is executed. This may be caused by the fact that the motion trajectories are not accurate at the deceleration phase, as is shown in the figures in section 6.1. It can also be caused by the tracking error that is shown in the figures 7.2, 7.3 in Appendix B. In practice the

6.2 Forecast accuracy

39

Figure 6.5: The field is divided in four regions.

Successfully predicted collisions Successfully predicted collision safety Failed predicted collisions Failed predicted collision safety

number 72 193 46 21

percentage 61% 90% 39% 10%

Table 6.1: Results of Forecast accuracy fault rate of collision forecasts can be worse, since the motion trajectories from real robot are less accurately estimated as explained in section 6.1. When vehicles pass each other very close, it can not always be predicted in advance, due to non-determinism imposed by the real world. In such cases it is desirable to choose the safe solution. About 10 percent of the predictions of collision safety are not correct. This can be caused also by inaccurate trajectories. But also the method for collision detection, can be a reason, since it uses a simplification of the vehicle shape. This method will result in more collisions being detection than actually occur. The influence of this inaccurate collision test on the fault rate of predicted collision safety, remains untested for the time being. Since these cases (10 percent) cause unsafe situations, avoidance of these situations is desirable. It is possible to use safety margins on collision zones to make sure that more collisions are predicted, although this will increase the number of false predicted collisions. It depends on where the forecast is used for. If the forecast is meant to optimize planning, it can be undesirable to reject efficient paths for a collision that would not occur. If it is used as a service to the control layer, that makes use of reactive avoidance methods, it will not cause too much difficulties, when trajectories turn out to be collision

6.3 Improvement of deliberative motion

40

free. More thorough testing is needed to get a better indication on forecast accuracy.

6.3

Improvement of deliberative motion

The intention to improve motion planning, was to increase the motion efficiency by avoiding collisions. We are interested in whether planning a different (collision free) S-curve will ensure a faster execution of the motion task, in comparison to using the shortest S-curve and avoiding collisions by slowing down along the track. In some cases the shortest collision free S-curve will be much longer than the shortest S-curve. We wish to know whether the overall efficiency will be higher using the new planning method. Using a strategy that selects collision free S-curves and not always the shortest S-curve will result in a larger average path length. On the other hand, the refrain of a velocity decrease to avoid collisions results in a higher average velocity in the long run. The question is whether the higher velocity will outweigh the larger path length. This becomes clear by observing the average time needed to execute a motion command. Test setup To evaluate efficiency in the long run, many tests are to be done. Performing these tests with actual robots is burdensome if not impossible. The batteries of Mi20 Robots have a limited capacity, and will not last a long time. Also robots can get stuck against each other when collision avoidance fails. Or robots may touch the field edges, so that they can not resume path tracking. Transmission errors can cause the robot not the respond. All these problem require human interference to be able to proceed with testing. This will also influence the test results. To avoid these problems only simulation is used. The same setup is used as in the forecast accuracy tests. Two vehicles perform continuously motion commands, to random positions on one of the four quadrants of the field. In one case the S-curve planning selects the shortest collision free S-curve, if it exists. Otherwise the shortest S-curve is selected. In both cases the existing obstacle avoidance method is enabled during path tracking. In the case where collision forecast is not used, only the shortest S-curves are selected, and collision avoidance is continuously enabled. The average time per motion command is a statistic that we like to compare for both cases. Besides counting the number of motion commands executed and the amount of time passed, also the total distance is registered. This will help us find out how much influence the collision-free S-curve selection has on the average velocity and the average distance per motion action.


41

Results The tests of both systems are done with two and three robots. When more robots are used, the robots decelerate more often due to the original collision avoidance. The forecast strategy should ensure that more often the paths are collision free, and deceleration is not necessary. In the tables 6.2 and 6.3 can be seen that the average velocity of the vehicles in the case of the new S-curve selection strategy is slightly higher compared to the average velocity of measured with the original strategy. It is also clear that the average path length is significantly larger, when the new planning strategy is used. Also from the average time per command, it becomes clear that the system with the new strategy can not outperform the original system in these circumstances. The performance of the original collision avoidance decreases considerably when more robots have intersecting paths. A performance comparison of both planning strategies could be made in a five or seven robot setup. In these situation, the new S-curve selection may prove more efficient than the original. The fact that the original S-curve planning is more efficient, can be explained as follows. Selecting an alternative collision-free S-curve results in a large deviation to prevent a collision, because the four S-curves are not comparable alternatives. One S-curve is clearly the most efficient. Employing the collision forecast in a path planning system, that selects from comparable alternative paths could show that collision forecast is able to result in improvements to motion execution.

Number of motions completed Total traversed distance Total time for path traversal Average velocity Average path length Average time of path traversal

Original system 120 181.91 m 361.7 s 0.503 m/s 1.516 m 3.01 s

System with forecast 123 213.64 m 406.50 s 0.526 m/s 1.737 m 3.30 s

Table 6.2: Motion efficiency results from tests with two robots. Results are taken from one robot in each test. In the system with forecast, that is the robot that changes its path to avoid the other robot.


Number of motions completed Total traversed distance Total time for path traversal Average velocity Average path length Average time of path traversal

Original system 120 199.19 m 410.3 s 0.485 m/s 1.660 m 3.42 s

42

System with forecast 124 218.95 m 430.64 s 0.508 m/s 1.766 m 3.47 s

Table 6.3: Motion efficiency results from tests with three robots

Chapter 7

Conclusion The objective of this project was to improve the MI20 motion handling by predicting and avoiding collisions. A method for predicting collisions has been developed and implemented, of which the accuracy is satisfactory. Collisions at the planning level are partly avoided by a different strategy on the S-curve selection. The improvement of motion with respect to speed of execution is not reached with this method. The collision forecast can benefit the system, because the existing collision avoidance resolves only the situation where deviation in time is possible. Also the collision forecast information could benefit other collision avoidance methods.

7.1

Results

The test results of the velocity forecast shows that it is possible to test an S-curve for collisions using trajectory estimation. Improvements on the estimation are possible, especially on the sections of deceleration, which can be described with a higher precision. An estimate on the accuracy of the forecast, can make it possible to use a safety margin on collision areas, to produce forecasts that are ”collision safe” (in other words: to prevent undetected collisions, without an increase in accuracy). There is no improvement visible when using the new planning strategy. The alternative collision-free S-curves result in a large deviation in space, with respect to the shortest S-curve, while the existing collision avoidance that decelerates the vehicle only causes a small deviation. The collision forecast can prove more useful when alternative curves of comparable length are used.

7.2

Future work

The improvement of collision avoidance in the robotsoccer system has been applied to the planning of the deliberative motion, and uses controllable

7.2 Future work

44

robots only. Collisions will not (yet) be avoided with opponent robots. Also Collisions between robots from our own team still may occur in case these can not be coped with effectively during the planning phase. A method for curve planning that evaluates more alternative curves, gives more possibilities to avoid collisions during planning. Searching open areas in (CT-) space for waypoints may be an approach. I think that at the control level, a smart combination of reactive collision avoidance and tracking of deliberative paths may improve the motion of the MI20 system considerably [2][10]. Avoidance of field boundaries and stationary robots should be possible at least. Also, in the MI20 system, motion control may be improved by timebased trajectory tracking. In that case a forecast would not be based on estimated trajectories, but rather on planned trajectories. This may result in improved predictability of trajectories at planning level with respect to executed trajectories.

Bibliography [1] R. C. Arkin. Motor schema based navigation for a mobile robot: An approach to programming by behavior. In S. S. Iyengar and A. Elfes, editors, Autonomous Mobile Robots: Control, Planning, and Architecture (Vol. 2), pages 162–169. IEEE Computer Society Press, Los Alamitos, CA, 1991. [2] R.C. Arkin and D.C. Mackenzie. Planning to behave: A hybrid deliberative/reactive robot control architecture for mobile manipulation, 1994. [3] D.J. Balkcom and M.T. Mason. Time optimal trajectories for bounded velocity differential drive vehicles. International Journal of Robotic Research, 21(3):199–218, 2002. [4] R.M. de Groot. Dynamic traffic control of free-navigating automatic guided vehicles. Master’s thesis, University of Twente, 1997. [5] W.D.J. Dierssen. Motion planning in a robot soccer system. Master’s thesis, University of Twente, 2003. [6] L.E. Dubins. On curves of minimal length with a constraint on average curvature, and with prescribed initial and terminal positions and tangents. American Journal of Mathematics, 79(3):497–516, 1957. [7] G. Dudek and M. Jenkin. Computational principles of mobile robotics. Cambridge University Press, 2000. [8] M. Erdmann and T. Lozano-Perez. On multiple moving objects. Technical report, Massachusetts Institute of Technology, Cambridge, MA, USA, 1986. [9] D. Fox, W. Burgard, and S. Thrun. The dynamic window approach to collision avoidance. IEEE Robotics & Automation Magazine, 4(1), March 1997. [10] E. Gat. On Three-Layer Architectures. AAAI Press, 1997. In D. Kortenkamp, R. P. Bonnasso, and R. Murphy, editors, Artificial Intelligence and Mobile Robots.

BIBLIOGRAPHY

46

[11] Y.K. Hwang and N. Ahuja. Gross motion planning. a survey. ACM Computing Surveys, 24(3):219–291, 1992. [12] N.S. Kooij. The development of a vision system for robotic soccer. Master’s thesis, University of Twente, 2003. [13] J.C. Latombe. Robot Motion Planning. Kluwer Academic Publishers, 1991. [14] J.P. Laumond. Robot Motion Planning and Control. Springer-Verlag New York, Inc., Secaucus, NJ, USA, 1998. [15] S.M. LaValle. Planning Algorithms. Cambridge University Press (also available at http://msl.cs.uiuc.edu/ planning/), To be published in 2006. [16] E. Martinson and R.C. Arkin. Learning to role-switch in multi-robot systems. In ICRA, pages 2727–2734, 2003. [17] J. Minguez and L. Montano. Nearness diagram navigation (nd): A new real time collision avoidance approach for holonomic and no holonomic mobile robots, 2000. [18] S. Quinlan and O. Khatib. Elastic bands: Connecting path planning and control. In Proceedings of IEEE Int. Conference on Robotics and Automation, pages 802–807, 1993. [19] E.M. Schepers. Improving the vision of a robot soccer system. Master’s thesis, University of Twente, 2004. [20] A. L. Schoute. RoadPlan manual version 3.1. Technical report TRCTIlT-02-28, Centre for Telematics and Information Technology, Univ. of Twente, The Netherlands, July 2002. [21] A.L. Schoute. Time-optimal collision avoidance of automatically guided vehicles. Eurocast 2005, 10th International Workshop on Computer Aided Systems Theory, 2005. [22] R. Seesink, W. Dierssen, N. Kooij, A. L. Schoute, M. Poel, E. Schepers, and T. Verschoor. Fast data sharing within a distributed multithreaded control framework for robot teams. In J. F. Broenink, H. W. Roebbers, J. P. E. Sunter, P. H. Welch, and D. C. Wood, editors, Communicating Process Architectures 2005 (WoTUG-28), volume Concurrent Systems Engineering Series 63, pages 147–154, Eindhoven, The Netherlands, Sep 2005. IOS Press, Amsterdam. [23] R. Simmons. The curvature-velocity method for local obstacle avoidance. In Proceedings of the International Conference on Robotics and Automation (ICRA), pages 3375–3382, 1996.

BIBLIOGRAPHY

47

[24] B. Triggs. Motion planning for nonholonomic vehicles: An introduction. Survey paper presented at Seminar on Computer Vision and Robotics, Newton Institute of Mathematical Sciences, Cambridge, England, June 1993. [25] J.P. van den Berg and M.H. Overmars. Prioritized motion planning for multiple robots. In IROS, pages 2217–2222, 2005. [26] T. Verschoor. Dynamic motion planning of soccer playing mini-robots. Master’s thesis, University of Twente, 2004.

Appendix A

Figure 7.1: The class diagram of the forecast module implementation The forecast module is build up from the classes listed below. • forecast main initiates the communication with other processes, starts the forecast thread, and closes all threads when a corresponding signal is received from the main process. • Cforecast thread uses the communication lines with the player processes. It receives a Tforecast request structure from each process, and sends

BIBLIOGRAPHY

49

a Tforecast result back to the requesting process. When the forecast thread receives a requests then it is handled using the Cctspace object. • Cctspace is responsible for the administration of Configuration time space. It keeps track of the trajectories of each player. When a forecast request comes in, the new trajectory is calculated and tested with the other trajectories. Cctspace keep track of the current time. When a new trajectory is added the start time is stored. Testing against an existing trajectory, means that the current position of a vehicle belonging to that trajectory is to be determined. This is done with the difference between the current time and the start time of that trajectory. • Ctrajectory is responsible for the trajectory of a robot. Internally the trajectory is stored as a list of TSection structure with each a constant acceleration. A start velocity is also stored in this class. Methods are available to get the field position or path length or velocity at a specific time. • Cvelocity profile is responsible for creating a Ctrajectory from a given TPath structure. Here the estimation is done of the velocity profile of a robot. • Croadplan if provides transparent access to the Roadplan core routines. This is the place where the roadplan C code is linked.

Appendix B Planned and resulting S-curves from the accuracy tests that are shown in figures 6.1, 6.2, 6.3 and 6.4.

Figure 7.2: Planned and actual S-curve with large radius (30cm). Created in simulator

BIBLIOGRAPHY

51

Figure 7.3: Planned and actual S-curve with small radius (15cm). Created in simulator

Figure 7.4: Planned and actual S-curve with small radius (30cm). Created in actual robots.

BIBLIOGRAPHY

52

Figure 7.5: Planned and actual S-curve with small radius (15cm). Created in actual robots.

Dynamic avoidance control of soccer playing mini-robots

Dynamic avoidance control of soccer playing mini-robots

Suggest Documents

Dynamic avoidance control of soccer playing mini-robots

Hierarchical Reactive Control for Soccer Playing

Playing Soccer with Legged Robots

Hierarchical Reactive Control for Soccer Playing ... - Semantic Scholar

Feedback Control for a Small-Size Soccer Playing ... - DEI UniPd

Soccer Boots and Playing Surfaces

Multi-Cue Localization for Soccer Playing

Playing with dynamic sound - CiteSeerX

Design of a Team of Soccer Playing Robots - CiteSeerX

Evidence of Cognitive Dysfunction after Soccer Playing with Ball ...

Evidence of Cognitive Dysfunction after Soccer Playing with ... - PLOS

Analysis of work-rate in soccer according to playing positions

Unifying Strategies of Obstacle Avoidance and Shooting for Soccer ...

Reinforcing the Driving Quality of Soccer Playing Robots by ... - Idsia

Designing a Team of Soccer-Playing Humanoid ... - Semantic Scholar

the challenge of motion planning for soccer playing humanoid robots

Detection, Prediction, and Avoidance of Dynamic ... - CiteSeerX

COOPERATIVE AVOIDANCE CONTROL FOR MULTIAGENT ...

A Lego-Based Soccer-Playing Robot Competition for Teaching Design

A Monocular Vision System for Playing Soccer in ... - ais.uni-bonn.de

Adaptive Vision for Playing Table Soccer - uni-freiburg

Variety Wins: Soccer-Playing Robots and Infant ... - NYU Psychology

CS Freiburg: Coordinating Robots for Successful Soccer Playing

micro-robots playing soccer games: a real ... - Semantic Scholar