Embedded Control Systems Design/RoboCup/appendix

High level design

Figure 1: A graphical overview of the different subsystems and their cooperation.

RoboCup Team Wiki decides to divide the design process in following subsystems:

Localization system: localization of the position of the robot itself, the ball, the team robots, the robots of the opponent, the borders of the soccer field, the teammate goal and the opponent goal.
Soccer skills system: move (“run”), intercept, dribble, kick, pass.
Battery autonomy system: provides the soccer robot with the energy to be competitive during a full game.
Communication system: talk to each other to deliver an assist, a pass …
Strategy system: “when the others are attacking, I stay as a defender” …

Each subsystem becomes the responsibility of a group of people, mostly specialist. The “strategy system” for example is awarded to the “strategy team”, a group of software engineers. It can be seen that some subsystems are overlapping different groups: a good pass needs good skills but also good communication and localization … It is clear that a good cooperation of the different groups is a must. A graphical overview of the different subsystems and their cooperation is given in Figure 1.

There can arise a situation likes following: “Soccer Robot Wiki 1” is in possession of the ball and is located near the teammate goal. The strategy system of this robot decides it is best, considering the position of the robot and the long distance to the goal of the opponent, to give a pass to another team soccer robot. The localization system of this robot search a team player to pass the ball to but notices that all his team players are located rather backwards on the own field half. Accordingly the strategy system of “Soccer Robot Wiki 1” commands the communication system to send a message to the team robot that is the closest to the goal of the opponent telling that he should go deep. From this moment, “Soccer Robot Wiki 1” waits until an answer. “Soccer Robot Wiki 2”, who receives this message by his communication system, transmits this message to his strategy system. The strategy system commands the soccer skill system to go deep. After being close enough to the goal to score, but also in a position reachable for “Soccer Robot Wiki 1” (a combination of the work of the localization system and the strategy system), “Soccer Robot Wiki 2” sends a message back to “Soccer Robot Wiki 1” that he is ready to receive the pass. The communication system of “Soccer Robot Wiki 1” receives this message and delivers this to his strategy system which commands the soccer skill system to pass. In meanwhile, “Soccer Robot Wiki 2” has to sent a message to all the other team robots (except “Soccer Robot Wiki 1”) that he is going for the ball. This is done to prevent the situation where all the robots go for the ball and the teammate goal is undefended. The battery autonomy system is an overlapping system that makes sure that all the other systems have enough energy to work properly and this during the full game. Keep in mind, this is a very complex cycle with just one pass as output … More information about the strategy behind this kind of decisions can be found in next chapter.

Figure 2: An overview of the different teams of RoboCup Team Wiki with the corresponding number of members(#).

To garantuee the above mentioned cooperation between the different teams, an integration manager is appointed. The integration manager is a generalist with a broad technical knowledge, able to “see the total picture” and make one coherent system from different components. Every team also needs a public relations (PR) manager to promote the team and make the necesarry arrangements to compete in the different tournaments. An overview of the different teams of RoboCup Team Wiki with the corresponding number of members (#) is given in Figure 2.

Although RoboCup Team Wiki has come up with a rather complete list of requirements, as shown in previous chapter, there are still some design criteria they need to take in account. The different teams of RoboCup Team Wiki made up following design criteria:

Focused functionality: The RoboCup Team Wiki project is optimized for autonomously playing soccer.
Energy consumption: The soccer robot runs on batteries and needs a battery autonomy of a full game, so it is important that the energy consumption is low.
Shocks and vibrations: The soccer robots must survive dynamic loads (being hit by another soccer robot or by the ball).
EMC: Every team has a wireless communication network connecting all the soccer robots of one specific team. Every team uses the same ether for this wireless communication which can generate EMC problems.
Space constraints: The size of the soccer robot is bounded by regulations of the competition.
Safety: the soccer robots should be predictable after a failure instead being uncontrollable (there are spectators!) by implementing some degree of redundancy and/or failure modes.
Communication: The RoboCup Team Wiki has to communicate with each other to function as a team (instead of 6 single individuals).
Dependability by redundancy: as already mentioned before, there is a strong need of redundancy (hardware and software).
Robustness: Each soccer robot will be exposed to shocks and vibrations.
Regulations: RoboCup Team Wiki is bounded by regulations.
User interface: RoboCup Team Wiki uses a system, implemented on the team computer, to log and save the communications and following actions of their soccer robots (see chapter 6 “The competition” for more information on such a system: the MDP2Logger system of the CoPS Stuttgart team). It is preferable that this system has a good and clear user interface.
Maintenance: The soccer robots should be constructed in such a way that maintenance is possible during the competition (servicing).
Cost: There are a lot of hidden costs because the team members work for free. The components of the soccer robots , travel costs, promotional materials … are not for free though and should not exceed the given budget.
Producibility: To allow sudden changes and servicing during the tournament, easy producibility is preferable.
Life time: To keep the cost under control it is important that the soccer robots (their components) have a long life time. It is preferable to reuse as many components as possible every new design-year to prevent restarting from scratch every year and lower the cost. Subsequently, the components have to survive a sufficient long time, so life time is also a design criteria to keep in mind.
Intelligence: The soccer robots should posses a form of intelligence necesarry to act autonomously.

	Team of RoboCup robots	People Mover	Vending machine
Safety	low	very high	low
Maintenance	very low	very high	low
Flexibility/ adjustability in design	high	low	low
Autonomous functionality/ Intelligence	high	low	low

The four last mentioned design criteria have a relatively low importance for RoboCup Team Wiki, but for the People Move Company on the other hand they are very important. To illustrate the clear difference in design constraints, Table 1 presents design criteria and the corresponding rate of importance for different embedded control systems (or system of systems).

At this stage, the company that builds the peoplemover is trying to translate their design criteria into requirements that can be added to their product requirements. Vague requirements as life time, energy consumption, cost … will be expressed numerically. This step does not apply to RoboCup Team Wiki because criteria such as performance are engineered according to the rule “try to make the team of soccer robots as performant as possible on the time given”.

Detailed design

Until this stage of the design process, the Soccer Robot can be seen as a “black box”. The only things that mattered up to this moment were “what the soccer robot should be able to do”. The designers have specified how the soccer robot should respond to certain inputs. The soccer robot, for instance, should perform soccer skills (output) after having received signals from his visualization system (input). How these inputs get changed into mentioned outputs was unanswered, until now …

Architecture

Each robot of RoboCup Team Wiki is a combination of hardware components and software programs. The line between hardware and software is often very thin, so it is up to the designer to decide which functions will be implemented in software and which in hardware. An example is a controller, which can be implemented in software just as in hardware components. Mostly the low level functions are implemented in hardware and the high level functions on the other hand are implemented in software. RoboCup Team Wiki makes following classification:

Low level functions: HARDWARE (HW)

Soccer skills: move, kick, pass, ball control and handling
Localization: sensors
Battery autonomy

High level functions: SOFTWARE (SW)

Localization: processing
Strategy
Communication

Localization system

As mentioned before, each soccer robot should be able to (based on the distinguishing in colours) recognize the position of:

Itself
Team soccer robots
Soccer robots from the opponent
The borders of the field
The teammate goal
The opponent goal
The ball

The localization system is, as already mentioned before, a combination of hardware and software. The hardware components are sensors, necessary to actually “see” (cf. human eyes). To process the signals of these sensors, there is the need for CPU power (cf. human brains).

Hardware

The sensors used for the localization system can be of different types:

Vision: omnidirectional vision camera
Odometry: rotary encoder on each wheel
Laser
Accelerometers
GPS
Electronic compass
Radar
Sonar
Infrared distance measurement

Mark there is always the need for a vision system able to distinguish colors: an omnidirectional vision camera. Most teams use a rather simple single view vision camera and equip it with an omnivision mirror, which also generates a 3D (color) image of the environment. This image is the input for the image processing software (see next chapter).

The vision system can be assisted by one (or more) of above mentioned systems. A robot only equipped with an odometry system for instance, is not able to determine its start position, which is needed because the odometry system works relatively. When the start position is retrieved with another system, the odometry system will be able to determine the robot position, the teammate goal, the opponent goal and the borders of the field at any time. The system however is not able to recognize the (position of the) ball or other players. The system can be helpful to act as a back up system or assist the vision camera (sensor fusion). An electronic compass can be added to determine the orientation of the field. A laser is able to recognize other object and estimate the distance to this object. A little GPS network can be built and used by the soccer robot to locate itself and a radar or sonar can be used to locate other objects. To estimate the distance to an object, an infrared distance measurement system can be used.

RoboCup Team Wiki decides to equip its soccer robots with an omnivision system, consisting of one camera and an omnivision mirror, an electronic compass and an odometry system.

Software

Each of the above mentioned hardware components requires software to process its data. RoboCup Team Wiki uses image processing software to assist the omnidirectional vision system. The image processing software should continuously calculate the position, speed and direction of the robot. It should also determine the position of the teammate goal, the borders of the field,the opponent goal and the position, speed and direction of the other soccer robots and the ball. To find these objects and track them to retrieve their speed and direction, the robot should be able to distinguish and recognize the different colours each of these objects have. To make sure the soccer robot recognizes the wanted object, a shape recognition feature can also be added.

RoboCup Team Wiki choses to use colour recognition and shape recognition to find above mentioned objects. The borders of the field are retrieved by“white-line detection”, as shown in Figure ... To locate the own position a Monte Carlo Localization method is used based on the distance to the field lines. An automatic colour calibration algorithm is also integrated.

For different reasons, the possibility exists that the soccer robot suddenly loses the position of an object. When the ball is moving to fast for instance or when a recognized soccer robot disappears behind another one. A position predicting algorithm is used to predict the position of the missing object, based on the information of the last recorded position. The vision system is also responsible for determining which path the robot should take to go to the wanted location. The path is not very often a straight line between the current position of the robot and the destination location, because other robots might block the way. The software calculating the optimal way to the destination location is imbedded in the “Strategy system”, as shown further in this text.

Soccer skills system

The soccer skills system can be subdivided in following different systems:

Platform
Motion device
Kicking/Passing device
Ball handling device

The platform

As a start, there is the need for a platform to build the three last mentioned devices on. The platform of the robot (also called frame or chassis) has to be strong, but also light. After all, a lighter robot is faster and more flexible. RoboCup Team Wiki uses a CAD software program to develop a platform. A lot of effort is taken to make sure the platform is designed in such a way that all the other components can be mounted easily and fast. It is also preferable to place the several modules at a relative low position in the robot, which lowers the center of gravity. A relative low center of gravity prevents the soccer robot from falling over too easily.

The motion device

The above mentioned platform will be equipped with a number of wheels to create motion. The teams use three or four omni-direction wheels driven by a same number of DC motors (and servo amplifiers). Shock absorbers can be installed on each wheel so make sure that the robot can move smoothly. A maximum speed of 2 m/s can be reached (TKU team for MSL).

The motion control system

The strategy system calculates the path the robot has to follow to reach its destination without hitting other objects. This open-loop control system is not reliable due to (different) frictional forces of the wheels, slip … while moving around. For all these reasons it is necessary to use a controller with a feedback to feed the different DC motors with the correct control signals in order to move correctly through the desired path.

The kicking device

Each soccer robot has to be equipped with a kicking device to perform following actions:

A straight, flat shot (on goal)
A ground pass
A lob pass/shot

Especially the last two actions should be adjustable in kick power and thus the force/speed of the ball. The kick power of the ground pass or lob pass for example depends on the distance to the other robot. Another advantage of an adjustable shot is to vary the power of a lob shot on goal on the distance of the robot to the goal.

There is a number of possible kicking device configurations:

Electromechanical solenoid: A metallic plunger (iron core) is moved via a magnetic field generated by a current flowing through a coil. The plunger is connected to a “metallic leg” to pass/kick the ball. The solenoid is powered by a capacitor (350 V, 4.7 mF – TechUnited) which is charged using the main batteries. The time the capacitor discharges over the coil can be adjusted, which makes it possible to vary the end speed of the solenoid and subsequently the launch speed of the ball. To be able to perform a ground pass/shot but also a lob pass/shot the teams create inventive constructions. The metallic leg for example can be composed out of an inner leg and an outer leg. The inner leg produces a straight, flat pass/shot. Activating the inner and the outer leg (which have a curved, foot-like shape) creates a lob pass/shot. Another possibility to perform different passes/shots is the usage of different pistons. This configuration is able to perform several types of shots by planning which piston is activated and when. Even a diagonal ground pass is possible with this device, namely by activating one of the side pistons and the central piston. A straight pass/shot is possible by activating both side pistons simultaneously. To perform a lob pass/shot there is still the need for an adjustment as shown in the first system.

The advantages of an electromechanical solenoid kicking device are the high response speed, the easy control and the possibility for kick power adjustment (different currents generate different powers of shooting). The high current and the high weight are the main disadvantages.

Pneumatic kicking device: pressed air is stored in a reservoir and can be controlled by an electric valve.
Fluidic muscle kicking device.
Spring kicking device: a spring is charged, subsequently locked and released when needed.

The ball handling device

The ball handling device should perform following tasks:

Prevent the ball form dropping during dribbling, turning, and slowing down.
Make the position of the ball with respect to the robot adjustable (special kicks)
Make it possible to drive backwards while still possessing the ball

During all moves, the ball should keep rolling.

Different constructions can be (and have been) invented for accomplishing above mentioned tasks. The mechanism designed by TechUnited for example consists of two levers with a wheel attached to the end. DC motors are used to actuate these wheels and the velocities of these wheels are measured by tachometers. The levers can rotate around fixed points of the robot while two potentiometers measure the angles of the levers. By rotating the wheels on the end of the levers inward the ball is pulled into the levers of the robot. A rotation of the wheels while the soccer robot is moving around keeps the ball rolling. It is also possible to predefine a preferred distance from the ball to the front of the robot, which corresponds to certain preferred angles of the two levers. If the levers are bending forward or backward a position error is introduced. These positions errors are controlled towards zero by adjusting the velocities of the wheels and hereby guaranteeing the preferred position of the ball relative to the robot.

Battery autonomy system

Each robot is equipped with a battery (pack) to produce enough power for all the modules on board. The TechUnited team for example uses two Makita 24 V, 3.3 Ah batteries. The power of the TKU team for MSL is supplied by rechargeable batteries of 1.3 V to produce 12V after the series-parallel connection. In times where robots are continuously becoming faster and more powerful, there is the constant need for high-energetic and efficient batteries. It is also preferable that the batteries are light and small for obvious reasons.

Communication system

To allow the soccer robots to work together in a team there is the need for a reliable and fast communication network to share information. Communication is in a distributed multi agent system one of the most important components of the system. There are different possible designs of the communication network:

Server – client: Each client (soccer robot) transmits all the collected data (position of the robot itself, ball, goal, team players, opponents …) to a central server. The server, implemented with the strategy system, combines these data and sends the appropriate commands back to the different clients. Note that the individual soccer robots are not equipped with a full strategy system (they only have a path optimizing function) and just need to follow commands.
Client – client (P2P): Each client transmits all the collected data to every other robot (by wireless LAN for example). Subsequently the strategy system, implemented on every client, calculates for every client the appropriate action to do. A simple FiFo principle can be used by which every robot handles the messages received from every other team robot in order of reception. To improve the speed and reliability of the communication network an event based communication architecture can be used. Hereby the receiver instantly gets the message when collected without any delay (real time ability).

The communication between different modules of the soccer robot can for example be done by Ethernet, USB and FireWire (IEEE1394).

Strategy system

The strategy system of the RoboCup team is mostly based on a role pattern (attacker, defender, dribble-robot, ball-passer …). In the beginning all robots are equal and during the game the robots individually select their own role based on prescribed conditions. This selection is controlled by the strategy system. Being in possession of the ball and close to the goal of the opponent for example is a condition for becoming “attacker”. The conditions are checked for all role patterns and the pattern which is the best in the given situation is selected. Roles are always changed in a manner that there are no sudden changes in roles (a role never changes from attacker to defender). Mostly the attacker is the dominator and decides which robot must cooperate and how to do this. Subsequently the attacker/dominator commands all the other robots to defend the teammate goal.

The strategy system is also responsible for determining the optimal path (with obstacle avoidance ) to the destination. TKU team for MSL of RoboCup for example uses a Fuzzy Controller to analyze the best way of obstacle avoidance.

Embedded Control Systems Design