Embedded Control Systems Design/RoboCup

The Wikibook of Embedded Control Systems Design

Introduction

To illustrate the mentioned terminologies, characteristics and design criteria of an embedded control system, the example of a team of RoboCup robots is presented. This example covers all the aspects that come across when designing an embedded control system.

RoboCup is a competition between 200 robot soccer teams from all over the world, participating in six different leagues. Each robot soccer team consists of six autonomous robots (so no human interaction is allowed). A robot-system requires the close integration of planning, sensing, control and modelling. The robot must also take into account the interactions between itself, its task and its environment. More information of the RoboCup competition can be found at this link: RoboCup

Each team participating in the RoboCup competition has to design a team of soccer robots. Every single soccer robot is an embedded control system and every team can therefore be seen as a system of systems. The aim of this application chapter is to give an overview of the design job that every team has to master.

This example differs from other examples as aviation, etc. by:

• The requirements are not well specified at the start of the project, but are continuously adjusted as shown in next chapter (moving target). This means the design phases are not as well specified and can change with the target.

• There is a dominant hostile environment that is continuously changing and improving. In aviation the environment , like air traffic control or other planes (not in combat), is an ally and cooperates with the actions of the plane.

• There is a different design target: “try to do the best you can in the time you are given and with the human resources you have”. This means the resources can be assumed fixed.

In general, this example can be seen as a prototype of a system of systems on every design-level.

In general, Robotics can be divided into two domains: (in order of increasing complexity) design on system level (1 robot) or design on “system of systems” level (team of robots). Choosing one design procedure above the other, depends on the priorities of the (team of) engineer(s). However, both domains have to be designed, so by starting from "system of systems" level, for instance, working downwards and optimizing the individual robots (by learning from obtained results) is needed.

Requirements analysis

The RoboCup Team Wiki has one year to design a team of autonomous soccer robots. The team organizes a brain storm session with all the members and makes up a list with the skills and/or specifications each of the field soccer robots has to posses in order to serve its purpose and follow the regulations. These skills and specifications are challenges for the designers and written in plain language and not yet (technically) specified.

4-C

The “four C’s”, explained in the main chapter embedded control systems design, are now used to execute a thorough analysis of robotics. The topics below reformulate these four concepts, applied to this subject.

1.computation

Computation can be described as the reaction speed on each possible input. Because computation on “system of system” level depends on that of the system level, a differentiation is redundant. On both levels, the hardware is decentralised. The software is centralised on system level, but decentralised on “system of system” level. This approach results in a faster system and moreover has a smaller chance of failure.

2.configuration

This is the programmation of de robots. The stand-alone code, as well as the cooperation code are implemented in each robot.

3.coordination

A division can be made between the functional coordination and system coordination. Functional coordination defines the tactical intelligence, such as the actions needed for an attack. System coordination on the other hand covers the junction between the different subsystems.

4.communication

Communication creates the links needed to make all the aspects of the coordination possible. The links between de different subsystems of a robot are necessary for the system coordination.

Robustness

For more general information on robustness, see Design Criteria.

Robustness is a very wide concept and has a lot of applications in many areas of this Robocup-example. It can be described as the level of immunity for failure on software level (dealing with communication errors, etc.) or hardware level (equal to collisions, etc.)

It’s very important to make a good balance between robustness in one hand, and efficiency and performance on the other hand.

• The system must be robust enough to handle with moving targets. For example, always foresee a way to implement new rules into the configuration by using an external link to upload new driver or software by wire. The possibility to switch between several management programs or play tactics is a smart thing to do.

• Considering the hardware, client-server communication creates a single-point-of-failure, which seriously decreases the robustness compared to peer-to-peer communication.

• In case of peer-to-peer communication , the consideration can be made to implement a “server” on software level. One randomly chosen robot collects all the inputs necessary for a tactical decision for the entire team and transmits it. In this case there is no direct loss in robustness and more efficiency. However, getting all field-info of the robots in an hostile environment is not evident. Therefore peer-to-peer on every level, this means each robot determines a tactical decision (parallel with the others) with the info he gets and transmits it, can be the better solution at first.

• A minimum of communication will lead to a maximum of robustness. However, a remarkable decrease in efficiency cannot be neglected. Within the world of the Robocup (in contrast to aviation for instance), redundancy isn’t implemented most of the time because of the increasing complexity, the higher cost and so on. With such a kind of “constraint”, you lose robustness to network failures. However, it is still possible to exploit the available resources, by minimizing the communication to the necessary minimum and creating a different kind of robustness. After all, the more autonomous a robot can function, with only the necessary part of communication, the higher the robustness.

• Often the priority lies within performance, instead of the physical state of the robot. Physical damage (a collision for instance) is almost inevitable and the many possible reinforcements against them will cause a complete downfall of the performance. This drawback shows that physical robustness is a must up to a certain level, because don’t forget it’s a game where your team has to perform!

These considerations cannot be framed within one C, but are more likely to be cross-sectional design criterions. It’s obvious that without a certain form of robustness, performance and efficiency can hardly be achieved.

Autonomy is , just like robustness, a design aspect that rises above all others. Because communication is still very sensitive to failure, it is of critical importance that every robot can function autonomously. A certain degree of autonomy for each robot will automatically result in robustness to failure of the team.

Design requirements

Design challenges: play soccer, tactics, communication, energy management

Design constraints: autonomy, safety, size, weight

The design challenges, combined with the design constraints (given by the organization), give shape to the design requirements. Although these constraints are mostly non-quantitative, a number of these design requirements are well specified. Namely these of the client: play football according to the RoboCup rules. Just as in every design environment, the rule is to keep it as simple as possible and mainly focus on the two most important design criteria.

More technical info about the design of these robots can be found in the appendix.

Lessons Learned

Do’s

• Foresee an alternative scenario in case of a communication error of any kind. When a tactical decision has to be made, don’t let a robot wait until he has all possible info, but foresee a certain autonomy so the robot can still make a fast decision without all info.

• Be aware of the trade-off you make by choosing robustness over efficiency and performance or vice versa. It’s impossible to purchase the maximum of both criteria, so chose wisely which criteria has the highest priority before you start.

• Considering the limited design time it is advisable to focus on the team instead of putting all the effort on one robot. Therefore, use the method described in “high level design” and use standard components without adjusting and reprogramming them more than necessary. That way, more valuable time and effort can be spend on the teamplay-aspect. Via experiences on the field, adjustments can be made on system level.

• Foresee a way to implement new rules into the configuration by using an external link to upload new driver or software by wire. The possibility to switch between several management programs or play tactics is a smart thing to do.

Dont’s

• Communication via Client-Server configuration, this creates a single-point-of-failure (as explained earlier).

• Trying to implement that a robot can detect whether another robot deals with a serious failure. This is very hard to do via communication: which signal must be sent and what if its communication system fails? It is only by continuous interpretation of the movement of the other robots or reverse processing that some sort of failure detection is possible.