Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Community
Ask the community for help and clear up your study doubts
Discover the best universities in your country according to Docsity users
Free resources
Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors
The reactive approach used in robotic soccer, which is based on the dual dynamics framework and extended with sensor readings. the challenges of coordinating autonomous agents, controlling individual robots, and the structure of the FU Fighters team. The team's robots are designed for the FI80 league, and the document explains their design, including their wheels, motors, and communication system.
What you will learn
Typology: Lecture notes
1 / 25
This page cannot be seen from the preview
Don't miss anything!
Foto: BeeIz
Peter Ackers, Sven Behnke, Bemhard Frötschl, Wolf Lindstrot, Manuel de Melo, Raul Rojas, Andreas Schebesch, Mark Simon, Martin Sprengel, Oliver Tenchio
Technical Report B-12/ July 1999
Freie Universität Berlin Department of Mathematics and Computer Science Takustr. 9,14195 Berlin, Germany
2 FU-Fighters Team
problems in which much research has been done and which are far from having been completely solved. Not long aga computer algebra was regarded also as a subject pertaining to AI. However, once the field became established, computers faster, and the algoeithms bettel', computer algebra metamorphosed into applica- tions and commercial software packages like Mathematica oe Maple, moving out of the AI domain. Al research is confronted with a moving horizon: once a prob- lem has been efficiently solved, it becomes uninteresting for the AI community and we proceed to deal with something different. For example, although work on computer chess continues to date, it is not the field many young researchers want to be, since a computer has already bet the world champion! Robotic soccer is interesting for many different reasons. First of all, it has to deal with coordination of autonomous agents. Each robot is "alone" on the field and has to respond to achanging and almost unpredictable environment. The movement of the opposing team is difficult to compute in advance, so that we need control software capable of reacting to many different circumstances. The actions of the robots in a team, if coordinated, can lead to a higher level of play and ultirnately to victory. Cooedination of autonomous agents is a weil studied problem regarding software agents, but very difficult in the context of robots act- ing in the real world. The second interesting problem in robotic soccer is control of individual robots and the constraints imposed by the game. Each robot has to be able to fmd the correct orientation to stop or shoot the ball, has to find the best path to the ball in a field full of obstacles and has to adapt its "intentions" to the perceived objectives of the own or adversary players. The problem can best be solved using a learning approach, like for example reinforcement learning, in which the pertinent actions of a robot are not coded by hand, but are generated automatically by a system that learns from experience and rewards to map situations to actions without manual intervention. Robotic soccer has also to do with computer vision. The ball has to be found using one or more video cameras and must be tracked continuously during the game. The movement of the other players has to be monitored also. Object track- ing is done finding color marks on the robots but in the future this could be abol- ished, so that only the form of the robots and their motion can serve as a Clle for the vision system. A last interesting problem is how best to balance the computing power in each robot with the external computer power available for processing. Too much proc- essing in the robot can require excessive energy and heavy batteries. No process- ing can overburden the central computer. It is for all these reasons that robotic soccer has become a paradigmatic problem of AI. The application domain is simple and well-understood, a robotic solution is therefore feasible even when only small resources are available. At the same time 'though, robotic soccer points to other more challenging problems and is open ended in its possibilities. Legged robots, for example, require more complex con- trol and power management strategies. Each new robotic championship closes therefore a development period and sets the stakes higher for the next meeting.
The Soul of a New Machine
RoOOCup consists, at the moment of this writing, of four tournaments: the simula- tion league, in which the players and playing field are sirnulated in a computer, the small size league (FI80) of wheeled roOOts with less than 18 cm cross-section, the middle size league (F2000) with wheeled robots of less than 50 cm cross- section and the league o/legged robots, which during RoOOCup 99 will mainly consist of off-the-shelf Sony mechanical toy dogs. Our team qualified for the small size league, in which 19 teams, divided in four groups, participate. The tournament is played like a FIFA World Cup, with group games at the beginning that filter out some teams and sudden-death in the following rounds.
2.1 Thc smalilcague
The playing field for roOOts in the small league is a green table, the size of those used in ping pong matches (1.525 m by 2.74 m), sUITounded by a 10 cm high white wall. Each goal has a width of 50 cm and it is 18 cm deep. The area behind the goalline can be used by the roOOts. One of the walls of the goal area is colored dark blue, the other yellow. The playing ball is an orange golf ball. Fig. 1 shows a view of the playing field from aOOve. The rules of the game are similar to normal soccer (regarding kick-off, penalties, etc.) but there are some special rules re- garding the protected zones around the two goallines, in which the goalie cannot be attacked by the roOOts of the opposing team.
Figure 1: A snapshot of the playing field with the ball at the center
The Soul of a New Machine 5
Fig. 3 shows tlu'ee of our robors in a playing situarion. The color marks on rhe top are used to identify the robors. In rhis image two robors marked with lighr blue. dark blue and red spots. are playing against a single robor marked wirh orher colors.
Figure 3: A playing siruation. The robot 10 the left is about 10 shoa!.
2.1 Small-Size League Constraints
A team consists of at least five robors. This means that the rules allow each team to use less than five robots, but this is not the normal case. Robots can get stuck du ring the game and can be retired during a time off. The maximum diameter of each robot body is restricted to 18 cm, but the toral floor area of the robot must be smaller than 180 cm^2. For robots with local vision the height is restricred to 22.5 cm. Robors using agiobai camera (like ours) are restricted to a maximum height of 15 cm.
2.2 Chassis
The chassis of the robots is made of 4 mm aluminum plate. The shape of the sides of each robot as weil as the bottom is shown in Fig. 4. The perforations and carv- ings provide structural support for other components of the robor.
L I
rt
I I 105,00""" F"'''=~===;iil
e· o
115,00 11Im IS.OOmm 1I.00mm
FU-Fighters Team
1l1.00ITWlli'-_--,_TT
3lI.DOmm
r"_O~-,!'--..JJ
42.llOmm _ 3I,OOrrun -
Figure 4: The sides and botlorn of lhe a1uminum frame
The robot uses soft wheels that provide good traction. The frame is kept together by bars laid from one side to the other.
2.3 The wheels and motors
Each wheel of the robot uses a different motor. This allows the robot to rotate in place or change direction while going forward or backward. Two De-motors from Faulhaber provide a maximum speed of about I mls. The motors have an inte- grated 19: I gear and an impulse generator with 16 ticks per revolution. The maximum number of revolutions per second, without load, is 9700.
Figure 5: Cornponenls of lhe wheel motors
The motors are activated by sending series of pulses with different width. If the motor has to go faster, the width of the pulses is increased. If it has to slow down, the width is decreased. The motor is activated therefore in discrete steps, but since this is done 122 times per second, it appears as if the motor is being controlJed using a slowly continuously varying input.
FU-Fighters Team
The electronics for our robots is based on some off-the-shelf cOl1lponents and a custOI1l motherboard that integrates all the necessary !ogic.
3.1 On-board computer
The he an of the on-board electronics is a controller card built and distributed by Conrad Eleclronic in Germany (calIed C-Contro!). The board is powered with SV and consumes about 5 mA. Fig. 8 shows the components contained in the card, which has a ',4 Euroformal size.
Figure 8: The C-Control unil
The largest chip on the card is a 4 MHz Motorola MC68HC05B 16 controller with 256 Bytes free for objecl code and a built-in 6 Kb operating system. The EEPROM integrated in the contro! card is an 8K by 8 Bit seria! unil. This allows the EEPROM to have a small footprinl. The two buttons on the right allow to start (yellow) or reset (red) the program contained in the EEPROM. The three LEDs provide a reading of the status of the controller: the green LED shows the syn- chronization of the unit with an optional antenna for wireless programming. the yellow LED shows that the processor is ready. while the red LED blinks \Vhen the program is running or a progral1l is being lransfered to the unil. The conneClOrs to the far right and far left provide access to the follo\Ving 1/0 options:
The Soul of a New Machine
· 16 digital JlO ports (SV 11 OmA). · 8 analog inputs. · 2 analog outputs (pulse-width modulation. PWM frequency of 1953 Hz).
9
The ten-pin connector on the top is an RS-232 interface for 1200 - 9600 baud. The controller on the computer is responsible for interpreting the received commands from the central computer and activating the two motors on the unit. as weIl as the third motor. which drives the shooting plate. The two pulse-width modulated outputs are used to control the wheel motors. The impulse generators of the motors are connected to the interrupt inputs. The microcontroller updates an internal counter periodically. In case that the counter fails to be updated. because the user prograrn has crashed or after a sud- den power drop, the whole unit resets itself. This provides a way of recovering from unexpected electrical problems. for example after a hard collision.
3.2. Custom board
A custom board was designed to provide the necessary power to the microcon- troller and to allocate the extra components needed: a dual H-bridge motor driver L298, a beeper, and the radio transceiver SE-2oo. The robots are powered by 8+ Ni-MH rechargeable mignon balteries
r== r-- Dia switch for robot conti uration Iee Iee I
e ## '-I-I . . (^) l 0 0 00 ~'"",' ~"l ;1;- (^) I qE::=J (^0000) I --IJ- I 00 C-Ccnl( cJ ## []J " " " t=J L (^) Microcontroller "" 0lJ~ P: **](1**^ l\~^ rnnnnnn'i ## \ SE-200 r^ =</UUUUUU/^ = **radio transceiver** U ## .n ~ *UJ ~ =~ ## i l~ ~oo ~ ...... ~ (^) Ti ~ ## .. [C]].... ~~ -@o - ## ICTIG~ ''''4 .@. -~ Figure 9: Layout of the custom board The Soul of a New Machine ll The user interface, finally, allows the programmers to get snapshots of the playing field and of most of the behavior, vision and radio link variables. Thi~ is a useful debugging tool in case the actual behavior of the robots differs from the intended one - a common problem in behavior based robotics. 4. Vision and user interface 4.1 The camera The only physical sensor for our control software is a S-VHS camera placed 3 m above the playing field. Its output is an analog video stream in NTSC format. A PC running MS-Windows captures the images using a PCI frame grabber. We obtain RGB images with 640 x 480 pixels at a rate of 30 fps and interpret them to extract the relevant information. Since the ball as weil as the robots are color-coded, we designed our vision soft- ware to find and track multiple colored objects, i.e., the orange ball and the robots marked with colored balls. One of the teams is required to bear a yellow spot on the top, and the other a b!ue one. There is therefore a "yellow" and a "blue" team. 4.2 Ball and robot tracking In order to track the objects we predict their positions in the next frame and then inspect a small window centered around the predicted position. We use an adap- tive saturation threshold and intensity thresholds to separate the objects from the background. Only if an object is not found, the window size is increased and larger portions of the image are investigated. When we find the desired objects, we update our model of the world using the measured parameters, such as posi- tion, color, and size. The decision whether 01' not the object is present is made on the basis of a quality measure that takes ioto account the hue and size distances to the model and also geometrical plausibility. Fig. II shows how the vision software works. There is an update module that continuously analyzes the frames arriving from a frame grabber. It locates and tracks the ball using a "ball model", which consist in some variables which de- scribe color and expected position of the ball. The "team" modules do sornething similar for each robot in each team. There is an individual robot model for each player, that is, a team can consist of entirely different robots. Once located, a ro- bot is tracked continuously during the game. Finally, a translation module trans- forms the positions of the ball and each roOOt, as weil as the position of obstacles, into normalized sensor readings that can be used by the behavior module. This transformation takes into account the actual position of the field within the image, as weil as the distortion caused by the optics of the camera. I Frame grabber 1f **Vision system** Ball module (^) ball V model (tracking) update module Team I Robot I model ### .... Robot2^ model Robot 3 model Robot4 (^) model Robot 5 model ..l Team 2 I translation^ I Jl Sensors: robot positions, ball position, ob- staeles Figure 11: Structure of the vision module **4.3 Visualization ofvariables** FU-Fighters Team In order to be able to program the system and adapt the behavior parameters. it was necessary to write a user interface which could allow the visual inspection of the system dynamics. Several variables can be monitored at once in a single dia- gram, so that the actual function of the system can be compared to the intended one. This is a kind of developing and debugging tool which we found very im- portant for a project in which the actual behavior of the robots "emerges" and is not coded explicitly anywhere. **5. Control software** 5.1 **General approach** FU-Fighters Team The "behavior based'" approach [Brooks 91,ChristaJler 99,PfeiferScheier 98] has proved useful for real time control of mobile robots. In this framework, so called _reactive agents_ do not have a complete internal symbolic model of the world. They act responding to stimuli arriving asynchronously from the environment. Each reactive agent is simple and interacts with others also in a simple way, but complex patterns of behavior emerge from their interaction. This is what Brooks has called "intelligence without reason", i.e. intelligent behavior without a sym- bolic plan. Brooks, specially, has put much emphasis in a hierarchical approach to the prob- lem of intelligence in mobile agents. Taking some cues from the evolutionary process, he proposed his "subsumption architecture" (Fig. 14) in which sensory information activates different behaviors that compete to define the fmal signal to the actuators [Maes and Brooks 90]. In Brooks model, different behaviors can be active simultaneously and together, through excitation and inhibition, they define the final action of the system. The behavior "wander", for example, can make a robot move around **in** a roorn, but the subordinated behavior "avoid obstacles" lets it move without bumping into other objects. ## s " ... E A N (^) " ...^ ,^ C S (^) exp10re - T I I N (^) " **wander**^ ,^ N ## G .,^ avoid obstacles G Figure 14: Brook's subsumption architecture In 1992, the programming language PDL was developed by Steels and Vertom- men for the stimulus driven control of autonomous agents [Steels 92,Steels 94]. This language has been used by several groups working in behavior oriented ro- botics [Schlottmann et al. 97]. It allows the description of parallel processes that react to sensor readings by influencing actuators. Many primitive behaviors, like taxis, are easily formulated in such a framework. On the other hand, it is difficult and computationally expensive to implement more complex behaviors in PDL, specially those that require persistent percepts about the state of the environment, i.e. the handling of different contexts. Consider for example a situation in which we want to position our defensive players preferentially on that region of the field The Soul of a New Machine 15 where the offensive players of the other team mostly attack. It is not feasible to take such adecision based only on a snapshot of sensor readings. The positioning of the defense has to be determined only from time to time, e.g. every minute, on the basis of the average positions of the attacking roOOts during the last time pe- riod. The _Dual Dynamics_ control architecture proposed by Herben Jäger [Jäger 96, Jäger and Christaller 97], describes reactive behaviors using a hierarchy of control processes. Each layer of the system is partitioned into two modules: the activation dynamics that determines at every time step whether or not a behavior tries to influence actuators, and the target dynarnics, that describes strength and direction of that influence. The activation dynamics corresponds to different contexts, leading to different targets. The different levels of the hierarchy correspond to different time scales. Behavior modi at higher levels configure the lower level control loops via activation factors which determine the primitive behavior mo- dus. This can produce qualitatively different reactions if the agent fmds the same stimulus again, but has changed its modus due to stimuli received in the mean- time. 5.2 **The architecture of the** system Our control architecture is based on the _Dual Dynamics_ scheme developed by H. Jäger [Jäger 96, Jäger and Christaller 97]. The roOOts are controlled in c10sed loops that use different time scales and that correspond to behaviors which sit on different levels of the hierarchy. We extended the dual dynarnics approach by introducing a third dynamics, namely the perceptual dynarnics. Sensory data is processed using different tirne resolutions. The position of the ball, for example, can be registered for every frame corning from the carnera. The average position every four frames can be stored in a higher layer. And the average position every sixteen frames in still another layer. Sensory layers contain therefore information which is relevant at different time scales. The predicted ball position, for example, is relevant only if the roOOt has cnough time to reael. The behaviors of the system are activated by different sensory readings at different time scales. level 2 level I **sensors** level 0 Figure 15: Aggregated sensory readings at three levels ofthe hierarchy The Soul of a New Machine (^17) Each physical sensor or actuator can only be connected to one level of the hierar- chy. One can use the typical speed of the change of sensor readings to decide where to connect it. Similarly, the placement of actuators is determined by the time constant they need to 00 effective. Behaviors are placed on the level that is low enough to ensure a timely response to stimuli, but that is high enough to provide the necessary aggregated perceptual information and that contains actuators which are abstract enough to produce the desired reactions. Behaviors are constructed in a bottom up fashion in a way resembling Brook's philosophy for the subsumption architecture: First, the processes that should react quickly to fast changing stimuli are designed. Their critical parameters, e.g. a mode parameter or a target position, are determined. When the fast primitive 00- haviors work reliably with constant parameters, the next level can be added to the system. More complex OOhaviors can now 00 designed for this slower level that influence the environment either directly by moving slow actuators or indirectly by changing the critical parameters of the control loops in the lower level. After adding some layers, fairly complex behaviors can 00 obtained that make decisions using abstract sensors which are based on a long history and that use powerful actuators to influence the environment. In a soccer playing mOOt, basic skills, like movement to a position and ball handling, reside on lower levels, tactic OOhaviors are situated on intermediate layers, while the game strategy is determined on the topmost levels of the hierarchy. 5.3. Update of **the** dynamics The state of the sensors, OOhaviors and actuators is updated using difference equations. Time advances in discrete steps ßto at the lowest level in the contral hierarchy. At the higher levels updates are done less frequently: the time step is a multiple of the time step at level O. Useful choices for the subsampling factor arc 2,4, 8, etc., but they can 00 adjusted as desired. The variables in each layer of the hierarchy are updated using information from the lower or the upper levels. In the case of the sensors, the i-th sensor at level _j_ in the hierarchy is updated at time I using its last value at time I-I, the state of the relevant physical sensors at time I, as weil as the value of the corresponding sen- sors in the lower level. The update mechanism is shown in Fig. 17. level} level (i-I) i-th Sensor (t-I) (^) , i-th Sensor (I) ~ ~ PhysicaJ sensors (1,2,... ,k) Sensors (I) 18 FU-Fighters Team Figure 17: Update of sensors The aclivation factors of OOhaviors depend on the sensor values at the same level of the hierarchy, their previous values and the activation of OOhaviors in the immediate upper level. level _(j+I)_ **activations** _i-th_ aclivalion (I-I) _i-th_ aclivalion _(t)_ level} sensors (1.2 •...• rn) Figure 18: Updale ofbehavior aclivalions A OOhavior situated at a higher level can "use" or activate lower level OOhav- iors. For every "connection" from a OOhavior up in the hierarchy to a OOhavior at a lower level, there is a connection strength that determines the desired change in the activation factor of the OOhavior at the lower level. Ir the upper level OOhavior is not active, the total connection strength is zero. To determine the new activation of the OOhavior at the lower level, the changes arriving from all connections to a lower level OOhavior are accumulated and transformed into the new activation using an adequate function. Each behavior _j_ at each level specifies for each actuator _k_ a target value _Tfk._ However, the more a OOhavior is active, the more it can influence the actuator vaJues. The actual change to the actuators is the difference OOtween the present state and the target value, multiplied by the conneclion strength between the 00- havior and each actuator and the activation factor of the OOhaviof. Several OOhav- iors can update the sarne actuators simultaneously, and in this case the total update is the sum of the individual updates. 5.4. Behaviors The final set of behaviors in our control software has a relatively complex struc- ture, as shown in Fig. 19. There is a team OOhavior that determines when a player is the one in charge of taking the initiative ("my_turn" variable). The highest level OOhaviors (in the middle) distinguish between a player who wants to shoot, one who is defending and one guarding his horne position. The next level of OOhaviors decompose these three OOhaviors in their elementary components: shooting, moving forward, blocking the path to the own goalline, dribbling, going back to the horne position. The behaviors at the lowest level are just moving (forward or backward) and steering. The actuators (third colurnn) are two fast ones at the low-