View Original PDF

5DPO'2011: Team Description Paper

T. P. Nascimento, M. A. Pinto, H. M. Sobreira, F. Guedes, A. Castro, P. Malheiros, A. Pinto, H. P. Alves, M. Ferreira, P. Costa, P. G. Costa, A. Souza, L. Almeida, L. P. Reis, A. P. Moreira

FEUP - INESC Porto, University of Porto, 4200-465 Porto, PORTUGAL

Abstract This paper describes the 5DPO middle-size robotics soccer team for the purpose of qualification to RoboCup'2011. During the last year, improvements have been made in the electronics, mechanics and software control to bring up to the world competition level the robots that used to compete in Portuguese Robotic Open.

1 Introduction

5DPO is the RoboCup middle-size league soccer team of the University of Porto, Portugal. This project involves people working on several areas contributing for development of the mechanical structure of the robot [3], its hardware architectures and controllers, as well as the software development in areas such as image analysis and processing [6] and [7], real-time path planning [4], modeling [5] and control [1] and [2].

The development of the team started in 1998 competing in the small-size league of robotic soccer. In 2001, the first middle-size team was created when it was 3rd place in the German Open. In 2006 the 5DPO team was 1st place in the small-size league. In 2009 and 2010 it received 2nd place in the Portuguese Open Soccer Competition with the middle-size league.

This paper describes the current development stage o the team and is organized as follows: Section 2 describes the general architecture of the robots focusing on communications, electronic and hardware aspects and mechanical construction. Section 3 presents the current version of the vision system. Section 4 addresses the control system and its levels. Section 5 describes the coach application and, finally, Section 6 concludes the paper.

2 General Architecture of the Robots

The general architecture of the 5DPO robot is basically based in a multi-agent system. Each agent is placed in a main processing unit (a laptop), which is responsible for the high-level coordination. This main processing unit handles

external communication with other robots, intermediated by a Coach, and has a vision system directly attached to it. This unit receives also a low bandwidth sensing information and sends actuating commands to control the robot attitude by means of a distributed low-level system (Fig. 1).

The low level sensing/actuating systems follows a distributed model where most of elementary functions (closed-loop PID control of the actuators) are encapsulated in small microcontroller based nodes interconnected by a motherboard and interconnected by a RS485 electric specification. For this purpose, a

real-time Modbus based protocol, called FlashBus, was created to communicate the main processing unit with the microcontroller based nodes.

Fig. 1. The General Architecture.
Fig. 1. The General Architecture.
Fig. 2. The 5DPO robot.
Fig. 2. The 5DPO robot.

2.1 Mechanical Structure

The 5DPO robot has the same physical structure then 2009 [3]. The new 5DPO robot can be seen in Fig. 2. Nevertheless some considerable changes were made. The first visible modification was in the reconstruction of the omnidirectional camera support. The previous support was a set of many structures which increased the positioning error. This structure is only three vertical rigid supports and a one piece head in iron perfectly welded. The head is 3mm thick and perfectly aligned.

Another big improvement was the galvanization bath done in the metal structure of all robots. This bath makes the structure more rigid and less susceptible to scraches and mechanical shocks.

The following big change was the introduction of a motor alignment structure. This part aligns the three motors both vertically and horizontally, avoiding misalignment during vibration. Then, the last modification that was made changed the robot kicking. As it can be seen in Fig. 3, the new kicking device puts the kicker coil fixed with a elastic returning device. Another improvement was the introduction of a roller device that is responsible to drag the ball and a kicking status device, thrown by a solenoid actuator. This kicking status device changes the throwing kick to straight kick. Finally, a sensor used to detect the ball when it is placed in front of the robot was also inserted. This sensor can also be seen in the figure.

Fig. 3. The Kicking Device.
Fig. 3. The Kicking Device.

2.2 Electrical Diagram

As it can be seen in Fig. 4, a new electronic hardware was created. These boards substituted the old ones used in Portuguese Open 2010. This hardware is composed by a motherboard and five boards. There are three boards to control the DC motors and read theirs encoders, one board to the kicking device ad one board to read the compass, the sensor of presence of the ball, the encoders of the roller motor and to control the roller motor and the solenoid actuator.

The motherboard acts as substitute of the power wires and the communication chain used before. This new board uses communication based in the ModBus protocol and uses both electric specification RS485 or RS232. These boards made the new electronic hardware more robust to be applied in an environment that contains much physic vibration and uses both high and low voltages.

Fig. 4. Electronic Boards.
Fig. 4. Electronic Boards.

3 Vision System

The vision software is called HAL (Hardware Abstraction Layer), which is an application that used to receive the sensor signals and communicates with the actuators, and then with the mDec (software of control of the real robots) by UDP protocol. The HAL interface can be seen in Fig. 5.

One of the biggest changes in the HAL software was the cut of the communication with the actuators and odometry sensors, which is now a job of the Dec program. The only function of this software is to treat the images captured by the camera and send the features to the Dec software to be processed. The features are field lines, ball and obstacles.

Fig. 5. The HAL Software.
Fig. 5. The HAL Software.

4 Coordination and Control Systems

We would like to draw your attention to the fact that it is not possible to modify a paper in any way, once it has been published. This applies to both the printed book and the online version of the publication. Every detail, including the order of the names of the authors, should be checked before the paper is sent to the Volume Editors.

4.1 The Dec Software

This is the decision software of each robot. Here are implemented the Roles, Tasks and Actions layers. Through the command received from the Coach, the robot assumes a specific Role, and then executes the proper Task and Action programmed for that function (Role). The Dec environment can be seen in Fig. 6.

In the Dec software it is processed all the information from the sensors (odometry, features received from the vision software, compass, etc.), it is observed which Role is given by the Coach. This Role implies in a series of tasks to be done (path generation, trajectory tracking controlling , obstacle avoidance, kicking strength, etc.).

Roles These are the designed functions for each player. These functions are set in each play. The functions that each player gets are given by the Coach software in agreement with a set of conditions, such as: its physical characteristics, its position in the field, etc. As roles examples there are: forward, defense, keeper, etc.

Tasks Tasks are jobs that each player must execute, depending on its function. The act of passing the ball to a team mate or to execute an adversary player blocking are good examples of tasks.

Actions These are the actions that make possible the executing of each player tasks. The Actions are responsible for the trajectory tracking control, trajectory generation, obstacle detection, kicking strength, etc.

Fig. 6. The Dec Software.
Fig. 6. The Dec Software.

5 The Coach

The Coach is a particular application from the Dec software executed by opening a menu option in the Dec software. The Coach application can be seen in Fig. 7. This application makes the management of the 5DPO team. All robots communicate with this application by wireless. Also, the Coach receives the commands from the Refereebox.

It is in the Coach that is located the state machine. This state machine, by the instructions of the Refereebox, activates the plays that the team must execute. In this software, the Tactics and Setplays layers are implemented. The Coach sends broadcast messages to al robots with the Roles that each one should assume. In

that same way it receives information from the robots with the position of the robot and the ball.

Even the Coach being an application of the Dec program, this has its own IP address. This application has all the main tactics of the team and of each robot. As it can be seen in the previous figure, the color status is green when the robot is active and its Dec is communicating with the Coach, and it changes to red when the robot is inactive and its Dec is not communicating with the Coach. It is important for the coach to know how many robots are active and ready to play so the chosen tactic will work. Finally, in the Coach map is shown the position of each robot in de field and the ball. Also, among each robot is defined which is its role and tactics.

Fig. 7. Coach Application.
Fig. 7. Coach Application.

6 Conclusions

This paper described the current development stage of the 5DPO robots. Since the last participation in the Portuguese Robotic Open, in March 2010, several major improvements have been carried out, namely: the improvement of the mechanical structure; a new electronic hardware development; a new communication protocol called FlashBus; an improvement in vision system, in particular the use of higher resolution images and the cut of communication with the hardware; the input of a roller, a sensor to detect the ball and a kicking mode option; modifications on data transmission between the Coach and the Dec software; improvement in the dynamic trajectory planning algorithm; and finally, changes in the existing roles and tactics.

References

  1. Nascimento, T. P., Conceio, A. G. S., Moreira, A. P.: Omnidirectional Mobile Robots Multivariable Trajectory Tracking Control: a robustness analysis. In: 9th Portuguese Conference on Automatic Control, Controlo 2010, pp 63–68, 8-10 September, 2010, Coimbra, Portugal
  2. Ferreira, J. R. A., Moreira, A. P.: Non-Linear Model Predictive Controller for Trajectory of an Omni-Directional Robot Using a Simplified Model. In: 9th Portuguese Conference on Automatic Control, Controlo 2010, pp 57–62, 8-10 September, 2010, Coimbra, Portugal
  3. Conceio, A. G. S., Costa, P., Moreira, A. P.: Design of a mobile robot for RoboCup Middle Size League. In: LARS 2009 - 6th Latin American Robotics Symposium (LARS), Oct. 29–30, 2009, Valparaso, Chile
  4. Costa, P., Costa, P. G., Moreira, A. P.: Real-time path planning using a modified A* algorithm. In: ROBOTICA 2009 - 9th Conference on Mobile Robots and Competitions, pp.141–146, 7th May, 2009, Castelo Branco, Portugal
  5. Oliveira, H. P., Sousa, A. J., Moreira, A. P., Costa, P. G.: Omnidirectional Mobile Robots Multivariable Trajectory Tracking Control: a robustness analysis. CON-TEMPORARY ROBOTICS - Challenges and Solutions, A D Rodi(Ed.), ISBN: 978-953-307-038-4, Publisher: INTECH, Publishing date: December 2009
  6. Gonalves, J., Lima, J., Costa, P.: Real-time localization of an omnidirectional mobile robot resorting to odometry and global vision data fusion: an EKF approach. IEEE International Symposium on ndustrial Electronics, Cambridge, July 2008
  7. Gonalves, J., Lima, J., Costa, P.: Real-time tracking of an omnidirectional robot - An Extended Kalman Filter approach and global vision data fusion: an EKF approach. In: International Conference on Informatics in Control, Automation and Robotics, Funchal, May 2008.
  8. National Center for Biotechnology Information, http://www.ncbi.nlm.nih.gov