Eurobot is a robotics European challenge for the young generation (university and technical schools) which is held annually, with a different challenge in every
edition, and participate around about 200 teams every year.
Each game comprises two teams competing against each other and does not allow draws. This work describes the design, development and building up of an autonomous mobile robot to fulfill this challenge. This paper includes the challenge description, robot design, sensors used, the strategy used and some conclusion. The team that built this robot and participated on Eurobot is made up of 4 industrial electronic undergraduate students from University of Minho

Braga, Paulo

Monteiro, Jorge

Ribeiro, A. Fernando

Silva, Pedro

Silva, Victor

Universidade do Minho: RepositoriUM

    Abstract— Eurobot is a robotics European challenge for the young generation (university and technical schools) which is held annually, with a different challenge in every edition, and participate around about 200 teams every year. Each game comprises two teams competing against each other and does not allow draws. This work describes the design, development and building up of an autonomous mobile robot to fulfill this challenge. This paper includes the challenge description, robot design, sensors used, the strategy used and some conclusion. The team that built this robot and participated on Eurobot is made up of 4 industrial electronic undergraduate students from University of Minho. I. INTRODUCTION UROBOT [1], is above all a scientific and technical meeting which gathers together youngsters which like mobile and autonomous robotics and its typical challenges. After the robot task and respective rules are made public (rules change every year), the teams have only 6 months to think about the strategy to use, to build the robot mechanical structure, to include sensors/actuators and respective hardware, and to pro-gram the strategy software. First, a round robin in different European countries is organized and only the best three teams are able to participate on the final competition. This team developed from scratch a robot named “Prometeu” to participate on this challenge representing the School of Engineering from the University of Minho. These competitions have the important characteristics of allowing students to meet new friends, with fair play during the contests, allowing exchange of technical and scientific information, with a low rate of rivalry, which makes it more beneficial for everyone. II. RULES AND OBJECTIVES No action can damage the field. No robot can destroy intentionally the surface or any other part of the complete field, nor the opponent. A. Game Field The field is made up of:  --A rectangular table made of wood with 300cm by 210cm painted on green.  --Two depart zones on each side of the table with 60cm by 60cm and equally paint of green.  --Four baskets, for balls reception, located on the four corners of the table.  --A wooden fence painted on green with 7cm height and 2.2cm thick which delimit the game field.   The game surface is sectioned with white lines offset 30cm between them, having though 10 lines (3 cm thick) in length and 7 lines (2 cm thick) in width, as described in the following figure.   Localization Beamers supports There are 10 different locations to place external to the robot position sensors by both teams (5 each). Before each game, each team places their sensors (beamers) where they want on these 5 possible places: above each of the corner baskets (on his side), on the two sides of the departure zone and one behind the departure zone. The supports are 50cm high measured from the table surface and have a surface of 8cm by 8cm. Twelve balls are placed on the game field, 8 red and 4 black. The balls are 14cm (+/-5%) diameter. Before each game the balls are placed randomly on any white lines intersection, and maintaining the central symmetry between both sides of the field, except for two red balls, which are always located on each departure zone exit.  Baskets There are four baskets on the field corners, which can take up to 5 balls each. The baskets have a system which allows a team to remove balls one by one, at surface level. The baskets opening at the top is 25 cm high above the surface; these openings are prepared to receive balls which are thrown by the robots from distance. B. Robot Dimensional Restrictions During the game, robots must respect the following restrictions:  --The robot external perimeter of the vertical projection on the surface cannot exceed 130 cm. The robot Development of “Prometeu” autonomous robot for ball handling in Eurobot P. Braga, J. Monteiro, P. Silva, V. Silva and F. Ribeiro, Member, IEEE E  Fig. 1.  Game Field.   shape is free as far as it fulfils this restriction. On the pictures below one can see some examples of this restriction.  --The maximum robot height is 40cm.   --The balls caught by the robot do not account for this dimensional restriction, but cannot exceed the 50 cm height which correspond to the location beamers supports.  --The sensors to place on the supports cannot exceed 8cm by 8cm by 8 cm which correspond to the supports base area. This space can only have devices related with the positioning of the robot.  --The full robot structure has to be one unique piece. In other words, it is not allowed that parts come out and separate from the main structure of the robot.  C. Robot Power Supply All sources of energy are accepted (springs, compressed air, rechargeable batteries or not rechargeable, etc.), except those which depend on chemical reactions, such as combustion or pyro processes. What concerns batteries, only robust and sealed batteries are accepted, in order to avoid acid leaking. D. Control System Teams can choose the control systems of their robots (analogue control, microprocessors, microcontrollers, computers, programmable logic controllers, etc.). These systems have to be integrated inside the robot, without any communication with the exterior during the games (it can only communicate with the localization sensors or beamers). During the game no remote control is allowed, the robots must be completely autonomous. E. Localization Sensors These sensors can only be used to help the robot to know its localization, as well as the localization of his opponent. They cannot be used to obstruct the opponent. Its use is optional. Each team can place one of these beams on top of the opponent robot, but can have a maximum of 5 sensors in the whole field. III. GAME A. Before the competition Before the actual qualifications, robots are carefully checked by a jury, in order to verify if all requests are fulfilled by the robot. Also, the robot is asked to perform a practical case, in order to check if a minimum demand of activity/reliability is achieved, to be able to participate with a minimum of decency. B. Scores  The winner After each game, the referees remove the robots from the baskets areas, to proceed to the valid ball counting, giving the scores according to the following rules:  --One red ball in the opponent basket scores 1 point.  --One black ball in one of the own baskets scores 1 point. It is easy to conclude that a ball in the wrong basket gives a score to the opponent team. The team with the highest score is the winner.  Ranking During the qualifying games, extra points are given as follows:  --4 points for winning  --2 points for a draw  --0 points, should the robot not come out of the departure zone. IV. MINHO TEAM ROBOT DESCRIPTION After analyzing the rules, the team came to the conclusion that the robot should have the maximum volume allowed, 40cm diameter cylindrical shape, with 40 cm height. The cylindrical shape would avoid opponent robots to get tangled with this robot. Before building the robot, a 3 Dimensional virtual prototype was designed to check if the components would fit together. The drawing is of extreme importance, not just because the time to build was critical (no time for mistakes), but also because it gave a perspective of the final machine to be built. The resulting 3D model is pictured be-low.  The robot consists basically of a Personal Computer motherboard with a colour camera connected to, grabs the images and processed them with image processing routines, and controls all the remaining devices. The Motherboard used is an 8500 TVX, with an Intel Pentium MMX microprocessor running at 200MHz, with 8 Mb of RAM, a PCI graphics board, and a frame grabber with a Bt848 chipset. The camera used is a XC731/340 from PHILIPS. The main reason to use a PC to control the robot Fig. 2.  Robot Perimeter Limitations.  Fig. 3. Three-dimensional robot model of the “Prometeu”; front and back.   is its simplicity, since it processes all the resources required. The robot structure can be described in 5 different parts:  1st Part - It is the robot base, where the four wheels drives are coupled. The gearing is made by two DC motors; the transmission is made by metal chains. Also, the batteries which feed the whole robot system (12V, 7Ah) are placed on this bottom part to have as low as possible the centre of mass.  2nd Part – It consists of a three floors tower where most hardware is placed; namely all electronic boards, the computer, the hard disk, the DC-DC converter and the camera. This module fits as a unique piece, which is mechanically an advantage.   3rd Part – It is a balls storing platform, with the localization system for the opponent team. This part has the capacity to store up to three balls of the same colour.       4th Part – It corresponds to the lift which takes the balls from the surface up to the storing area. This system is made up of rubber belts and rotating wheels. The movement is created by two DC motors (one on each side). A third motor produces the opening and closing of the lift entrance. This movement consists of approaching or moving away the two rubber belts, to allow for the ball to enter the receptacle. Once the ball is positioned, the rubber belts compress the ball, and the same belts start moving upwards. The ball is then transported to the upper platform to be stored.  5th Part – It consists of a control panel at the robot back side, which contains fuses, all the computer doors (for keyboard, mouse, VGA screen and composite video), the main power switch and the start button which consists of a string to pull out (it is a demand from the rules). It also contains a fan to cool the robot interior, since that the outside covers make the flowing air is reduced make it hot inside.      Fig. 5.  Computer and other hardware module.  Fig. 4.  “Prometeu” robot base where motors, wheels and batteries are placed.  Fig. 6.  Balls storing platform.  Fig. 7.  Rubber belts and lift.    V. MOTOR DRIVES The team designed and built all electronics devices of this robot. The following picture shows the block diagram of the hardware developed. On this section only the Motor drives board will be described.    Fig. 9.  Motor Drive circuit.   The DC motor drive is implemented through the use of PWM (Pulse Wide Modulation). This method permits to vary the voltage on the motor and consequently its rotation speed. It was necessary a device which could receive the digital commands from the computer and translate that information into the corresponding PWM. Another requirement to take into account is that the computer should send commands to the motor drive only when a change in speed is required. This would allow reducing computer processing, leaving the processor free for other tasks like the image processing. Since the space in the robot was very limited, another requirement for the board was to be of reduced size. Since non programmable digital electronics use normally large spaces, the solution was to choose a small microcontroller for each motor drive, the PIC16F84. Another advantage of this microcontroller is that any changes could be carried out by software. The circuit was designed to include encoders, since a good motor control speed is necessary. The PIC receives 8 bits of data, and one CS bit (Chip Select). From the 8 bits of data, the 7 least significant bits refer to the average voltage that reaches the motor. That value corresponds to the desired percentage and varies from 0 to 100% with a resolution of 1%. The most significant bit indicates the PIC the motor rotation direction required. If that bit values 0 it means the motor will rotate in the normal direction and if that value is 1 the motor should rotate in the opposite direction. It is important to point out that the motor drive does not work immediately after receiving new information from the PC. Since there are two independent motor drives, both should start the instruction at the same time otherwise the robot might get a small undesired movement. Since the computer cannot write on both devices at the same time, each PIC waits for a new order to the other PIC. The computer writes all bits to 1, to the data output bus.    The motors should be able to rotate in both directions and that forces the existence of a complete H bridge. It is also good practice to isolate the command actuating circuit and therefore opto-couplers were used. Two N type and other two P type MOSFETS were used. This differentiation is useful because the maximum voltages on the MOSFET gates are not sufficient to open or close completely all MOSFETS. The bridge proved working well, and for these motors 2Aeach, no need for dissipaters to reduce heat on the MOSFETs. VI. WORKING STRATEGY All strategy is dependent on computer vision and image processing. A colour camera is placed in the centre of the robot underneath the balls storing platform and between the two rubber belts, and it points towards the front side. The robot localization is carried out with the help of an infrared transmitter which is placed on the basket supports and a receiver located in the front area of the robot. With Chip Select Motor Drive 2 Motor Drive 1 Balls lift controller D0..D7 CS2 CS3 CS1 I/O 0..3  Fig. 10.  Motor Drive circuit.  Fig. 8.  “Prometeu” control panel.   this device the localization is easy.               The whole strategy was implemented with software written in C language. It consists of three main areas; a set of computer vision and image processing libraries [2] developed by the team specifically for this purpose; a second layer to deal with the hard-ware (for reading the sensor values and to send values to the actuators); and the main core which consisted on a finite state machine algorithm which controls the robot and gives the sequence of steps to make the robot perform its task with success. The GrafCet consisted of a few steps starting with the red balls search. Once there was no more red balls, a search for black balls would start and would have the same aim. For both colours ball, once a ball was reached, the robot would go towards it and start the picking up process (moving the rubber belts upwards), the ball was then stored in the storing area and the balls counter was incremented. The robot would collect up to three balls and then would move towards the basket using the infrared receiver. Once the basket was reached the robot would turn its back to the basket (rotate approximately 180 degrees), open the balls small back door, and start a shaking movement for three seconds so the balls could be released inside the basket. The black balls search would do exactly the same as the red. The ball choice and its approaching were carried out using colours. A virtual coordinate is assumed which is the centre of the ball, corresponding to the maximum value of that colour. This is the highest value of intensity colour on the histogram. The robot would move towards this coordinate. Since the surface field was mainly green, the lack of this colour was used to avoid obstacles (except for the black and red colours). This way the robot avoided obstacles using a reactive strategy. VII. CONCLUSIONS As first participation in this challenge, “Minho” team got honours classification. New solutions could have been taken which could give better results. The locomotion solution used in this robot is not the best solution since direction change was difficult to achieve and tape on the wheels was used to reduce grip. The space within the robot was very difficult to manage, even though there was space limitation in size and volume. The mechanical devices and hardware could be redesigned so that the boards could use less space. This would help reducing weight and batteries consumption. It is critical in mobile robots to use as less space as possible. The camera field of view also depends on the space available within the robot. The computer vision and image processing proved to be very promising in this type of robots. Within the around about 200 teams only a couple of them were using vision. However, it is very important to know its limitations. Light changes and public around the game fields are critical situations. This competition occurs within a television studio and the light used is very bright which originates vision problems even to the infra red devices. The reflections are to strong making white areas where they do not exist. There is also a lot of noise around which makes the vision processing even harder and more complex, like people around the field, other cameras, publicity cards, other robots, etc… Another important conclusion is that, this work was fully developed by five 4th year degree on industrial electronics students from University of Minho, completely from scratch in only about 3 months: mechanics, electronics and software, with success. This proves that they are able to go to the working market without any frights. This kind of challenges has many advantages like to meet new friends, to create new ideas, to exchange information with other teams, to test in practical terms what the students learn, etc. REFERENCES [1] http://www.eurobot.org/. [2] F. Ribeiro, “Virtual Sensors for Autonomous Mobile Robots through the use of Image Processing Tools”, Revista Robótica, no. 59, pp. 10–17, 2º trimester 2005, ISSN: 0874-9019.  Fig. 11.  Infrared beamer for localization 

Development of Prometeu autonomous robot for ball handling in Eurobot

http://repositorium.sdum.uminho.pt/bitstream/1822/10302/1/Robotica2008-MINHO.pdf

Development of Prometeu autonomous robot for ball handling in Eurobot

Abstract

Similar works

Full text

Available Versions

Universidade do Minho: RepositoriUM