Embedded Control Systems Design/RoboCup/appendix

< Embedded Control Systems Design < RoboCup

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:

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:

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)


High level functions: SOFTWARE (SW)


Localization system

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

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:

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 itsself 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:


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:

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:


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.


The ball handling device

The ball handling device should perform following tasks:

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:

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
This article is issued from Wikibooks. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.