HoRoISEC: HOCKEY WITH ROBOTS MICAEL S. COUCEIRO, CARLOS M. FIGUEIREDO, J. MIGUEL LUZ, DANIEL D. BASTOS NUNO F. PAIVA, RICARDO P. FARIA, C LEBRES, J. CARVALHO AND N. M. FONSECA FERREIRA
Institute of Engineering of Coimbra, PORTUGAL1
Abstract: This work presents a development of robotics team of hockey. This team is controlled in real time over the Internet. This paper describes the physical structure, the electronic system and the implemented algorithms. Keywords: Hockey, Robot, RF Communications, Internet Communications, Delphi Programming. 1. Introduction In 1970 a group of researchers created the first interactive online game [1]. Nowadays, online games are the main focus of all games developers. This kind of games provides multi-user gaming that encouraged players to compete against one another. This project consists in the evolution of online gaming giving the possibility of controlling and monitorizate a hockey robot in real time through the internet. The idea of robot playing soccer/football game was first mentioned in a paper entitled „On Seeing Robots‟, in 1992. Since 1997 it is possible to compete against other teams in contests like RoboCup [2]. The only catch is the need to construct or simulate a team of autonomous robots controlled with PID or Fuzzy Logic [3]. For regular user this is not an option but they can still watch the games. The comparison between other projects like soccer robots and ours is not simple because the whole goal is different. We want to give to the user the chance of controlling a robot like playing an online game competing against other users. Why hockey? In roller hockey, Portugal is the country with most world titles with 15 World Championships and 20 European Championships. In order to honor that we built a group of hockey robots so they can, someday, follow the steps of our country hockey players. In figure 1 we can see the whole team of robot players. The paper is organized as follow. Section two provides an overview of the physical structure. The reference to electronic system as actuators and schematics is referenced in section three. In section four we describe the whole communication system. Section five refers to video monitorization. The webpage presentation is made in section six. An overview of the implemented software is made in section seven. Finally, section eight brings some rules to follow in hockey games.
Figure 1 – HoRoISEC Team 2. Physical Structure 2.1. Overall Size Each robot player has approximately 25 centimeters tall, measured from the bottom of the drive wheels to the top of the head without the antenna and 30 centimeters with it. The widest points are from wheel to wheel measuring approximately 20 centimeters. Figure 2 shows a robot player made in AutoCAD. All the 3D physical structure is made in real scale.
Figure 2 – Robot player made in AutoCAD 2.2. Weight The overall weight of the structure is a primary concern to ensure a long battery life. The power source for all electronics and actuators are carried on-board and no external power may be used. The entire robot weighs approximately 1.12 kilograms.
2.3. Drive System The robot has two wheels, each one connected with the intermediate of two gears and one racing belt to a separate electric DC motor as can be seen in Figure 3. The steering is accomplished by adjusting the power and direction of the motors separately. The speed and direction of each wheel are controlled individually. This setup gives an easy control of the robots movements and, at the same time, is efficient and easy to implement. The robot has a high turning radius and the top speed is only dependent on the maximum output of the motors.
The four black crosses shown in Figure 5 correspond to the initial position of the four robots. They need to be placed on those positions when game starts and after every goal. 3. Electronic Systems An important aspect on the hockey robots is the perspective of evolution. With this in mind, it was developed a structure that can be upgraded both in software and hardware levels. This was made thinking ahead for new developments and future research. 3.1. Electric Actuators
Figure 3 – Drive System (Top and Bottom views) 2.4. Hockey Stick Contrarily to other hockey robots built with a static stick [4] each robot as a controlled stick to drive the ball in front of him. The control is made by a servo motor (Figure 4) so the player can easily shoot or just beat against everything that moves. The ball can be reached by the stick in a maximum front range of 10 centimeters.
Each robot will have three servo motors (Figure 6). One will be in charge of controlling the stick; the others two will be hacked [5] without removing the potentiometer so they can be used as common DC motors. The speed and direction of those motors will be controlled by a PWM wave. Regulating the internal potentiometer to a duty cycle corresponding to 90º, it will be possible to change direction and speed increasing or decreasing the duty cycle having as reference the one corresponding to 90º. The power consumption of those motors may differ depending on the movement that is made, the strength made by the stick, etc. Even so, in the worst case, it would originate a current consumption of approximately 600mA.
Figure 6 – HITEC Servo HS-311 Figure 4 – Drive System (Top and Bottom) 2.5. Hockey Field The hockey field is made of a resistant canvas that can be molded thanks to this texture. Field dimensions are 2.40x1.38 m with molded lateral limits of 3 cm.
Figure 5 – Hockey Field
3.2. Electronic Boards In the electronic board‟s elaboration we decide to subdivide the main board in four boards (Figure 7), each one entrust with a specific job: power supply, control, motors‟ connection and communication. One of the advantages, is to be able to detect malfunctions easily. Another advantage is to plug sensors or other actuators without making any changes (depending on sensors and actuators characteristics) because all the IN / OUT pins of the PIC® microcontroller are enabled. The most significant advantage of sub-dividing the main board is to be able to replace the power source board with a better one by optimizing the consumption with choppers that can be easily implemented. This kind of optimization will dramatically improve batteries durability.
Information about the movement of the motors is received on motor connection board (Figure 10). This board was designed to plug servomotors directly being able to support up to eight motors. J3
PIC B0 5.8v JP1 5.8v
2 1
1 2 3 4 5 6 7 8 9 10 11 12
PIC B1 5.8v PIC B2 5.8v
HEADER 2 PIC B3 5.8v
Figure 7 – Electronic Boards PIC B0 PIC B1 PIC B2 PIC B3
The power source circuit (Figure 8) is divided in two distinct sources (with different voltages). Using the same battery and with the help of two voltage regulators LM7805 we supply 5V to the whole system except the motors and a voltage next to 6V exclusively to the motors. A system for detecting low batteries was implemented on this board. The player will be alerted with a yellow LED when the battery is close to 7V. This is made by a voltage comparator. LED D1 indicates the power supply and D2 indicates low battery. U1 LM7805C/TO220 1
1
2 1
R2 2.2K
2
Battery
2
5.8v
3
OUT
GND
IN
SW2
JP1
C1 10u JP3 1 2
SW KEY -SPST HEADER 2
R3 100
1 2 3 4 HEADER 4
1 2 3 4 5 6 7 8 9 10 11 12
PIC B5 5.8v
JP6
PIC B4 PIC B5 PIC B6 PIC B7
J4
PIC B4 5.8v
PIC B6 5.8v
1 2 3 4
PIC B7 5.8v
HEADER 4
MotoresB4_7
Figure 10 – Motor‟s Connection circuit The communication circuit (Figure 11) receives information from server through [433; 434] MHz radio frequency or RS-232 (serial) with the commutation of SW3. This information reaches the MAX232 that converts rs232 signals in TTL to the microcontroller. This board connects to microcontroller over JP2. For the radio frequency communication a module from EasyRadio® is connected on CON14.
CONN PWR 2-H
JP1
U3 LM7805C/TO220 1
MotoresB1_3
JP5
IN
5v
3
OUT
GND
R4 1K
2 1
VCC 5 V
2 1
2
U4 C3 10u
R5
D1 LED
Serie TX
D2
C6
10u
C7
10u
13 8 11 10 1 3 4 5 2 6
R1IN R2IN T1IN T2IN
R1OUT R2OUT T1OUT T2OUT
12 9 14 7
C+ C1C2+ C2V+ V-
LED
JP5 1 J2
Antenna
VCC
C9 10u
PIC C1
JP2
1
C8 10u
Low battery
Serie RX
CONNECTOR DB9 P1
MAX232 1K
5 9 4 8 3 7 2 6 1
CONN PCB 2
C10 C
2 1 CONN PWR 2-H
Serie TX RF Serie RX RF
PIC C0
SW3 D6
R6 1K
3 7 2
6 1
Serie RX U6
+
5
-
R8 1.2K
1 2
Serie TX RF
1 2
CON14 radio
Serie TX PIC Serie TX CONN PCB 2 LM311
SW DPDT/SM
4 8
R10 1K
VCC
Serie RX PIC
3.9 V R9 100 Battery
JP2
Serie RX RF
1 2 3 4 5 6 7 8 9 10 11 12 13 14
Battery
Figure 11 – Communication circuit
Battery 5v
Control of battery
Figure 8 – Power Supply circuit The robot “brain” is placed in the control circuit (Figure 9). The microcontroller PIC18F258 will receive and process all the information sent from the user and will execute the respective actions. All ports of the microcontroller are available to future upgrades. 5V
JP1
U2 1 2
1 2 PIC PIC PIC PIC PIC PIC
CONN PCB 2
A0 A1 A2 A3 A4 A5
PIC C0 PIC C1 PIC C2 PIC C3
20MHz
1 2 3 4 5 6 7 8 9 10 11 12 13 14
28 27 26 25 24 23 22 21 20 19 18 17 16 15
PIC PIC PIC PIC PIC PIC PIC PIC
B7 B6 B5 B4 B3 B2 B1 B0 5V Serie RX PIC Serie TX PIC
PIC C5 PIC C4
PIC18F258
CRY STAL C4 33p
Vpp RB7 RA0/AN0 RB6 RA1/AN1 RB5 RA2/AN2 RB4 RA3/AN3 RB3 RA4/T0CKI RB2 RA5/AN4 RB1 VSS RB0/INT OSC1/CLKIN VDD OSC2/CLKOUT VSS RC0 RC7/RX RC1 RC6/TX RC2 RC5 RC3 RC4
C5 33p
JP5 PIC PIC PIC PIC PIC PIC
A0 A1 A2 A3 A4 A5
1 2 3 4 5 6 HEADER 6
PIC PIC PIC PIC PIC PIC PIC PIC
B0 B1 B2 B3 B4 B5 B6 B7
JP3 1 2 3 4 5 6 7 8
PIC C0 PIC C1 PIC C2 PIC C3 PIC C4 PIC C5 Serie TX PIC Serie RX PIC
HEADER 8
JP4 1 2 3 4 5 6 7 8 HEADER 8
Figure 9 – Control circuit
The server communication circuit (Figure 12) is a single board, which is directly connected to the server and establishes communication with robots. A LM7805 voltage regulator regulates the voltage to 5V, enough to supply the entire circuit. That means that a common battery of 9V will be enough (common 9V pile). The connection to the server is made by RS-232 through MAX232. LED D1 indicates the voltage supply, D3 indicates data transmission, D4 indicates data reception and D5 indicates state of BUSY.
SW2
JP1
U3 LM7805C/TO220
D2 2
1
ON/OFF
IN
OUT
1N4148
VCC
3 R4 1.8K
GND
1
2 1
2
HEADER 1 C6 100nF
C8 100nF
+ C7 10uF/16V
+ C9 10uF/16V
D1 POWER
JP5 1
1 J2
Antena
U4 Serie TX
+
+
13 R2in 8 11 C 10
C11 1uF/16V
R1IN R2IN T1IN T2IN
1 3 4 5 2 6
C12 1uF/16V
12 9 14 7
R1OUT R2OUT T1OUT T2OUT
Serie RX
C+ C1C2+ C2V+ V-
RS1 C Serie TX Serie RX VCC
RS1
J5 1 2 RSSI
P1 CONNECTOR DB9 CON14 radio
J3 1 2
J4
JP1
MAX232 +
5 9 4 Jump8 8 3 R2in 7 2 6 1
1 2 3 4 5 6 7 8 9 10 11 12 13 14
1 2 3
Jump8
C13 1uF/16V
CON3
VCC D5 BUSY
C14
+
1uF/16V
VCC D3 TxD
D4 RxD
Each client will send periodically two bytes containing the information about the direction of the robot and state of the stick. The server will regroup all information received adding the corresponding robot in the header of each individual client data and finalizing the data frame with the number five (Figure 15). The data is refreshed every 250 milliseconds. This time has been studied to satisfy both ethernet and internet players so they can play against each other in the same conditions.
R7 1.8K
R5 1.8K
Serie RX
R6 1.8K
Serie TX
Figure 12 – Server Communication circuit 3.3. Power Supply To feed the whole system we need a battery with high durability, little, light and small costs. Attending to those conditions we will use batteries based on common rechargeable piles. The battery used was from Graupner with 9.6V and 1500mA as shown in the Figure 13.
Figure 13 – Battery of 9.6V / 1500mA Those batteries require periodically attention. They have a specific charging time (between 6 to 8 hours) with a specific voltage and current of 12V/200mA. The batteries state has influence over robot‟s movement and that‟s why users will be alerted by a yellow LED on robots head when batteries are low. The batteries have a large durability and they can stand up over more than one hour and a half when playing. 4. Communications
Client 2 Robot 1
101 160
103 161
Server
1 103 161 2 100 160 3 101 160 4 100 160 5
Figure 15 – Example of data sends from two clients to server and from server to robots If server doesn‟t receive information about a robot it means that no one is controlling him. In that case the server will send data corresponding to resting position (Figure 16).
1…5
100…108 160…161
Number of Robot 5 Ending Flag
Movement of Robot Stick 100 Resting 160 Resting
Figure 16 – Data specification 5. Monitorization
Being able to have a system controlled over web in real time can‟t be done. Real time does not exist in web communications. What does exist is something near to real time. Our communication is based on TCP Sockets between clients and a server that will add data and send it to robots with a Radio Frequency interface. The Figure 14 illustrates the communications system. Client
Video Frame
Client 1 Robot 3
TCP
HTTP
Individual Client Data
Server
RF
All Clients Data + IDs
Robot 1
Robot 2
Robot 3
Robot 4
Mask 1
Mask 2
Mask 3
Mask 4
Figure 14 – Data communication between clients and robots
There are two types of video transmission. The first one is made for the internal LAN that consists on getting frame by frame with HTTP commands. This one is implemented in a thread giving independency between video and data communications. It requires an HTTP server that can be made with Apache®. The other one is adjusted for Web communications and is based on an ActiveX controller for video transmission. The disadvantage of this last one is that it requires additional software to accomplish the video acquisition to ActiveX controller. The additional software used was Active® Webcam that consists on video transmission over internet for ActiveX controllers, Applets and others. The Web software can also be used in internal LAN but the need of having ActiveX plug-ins installed in the server is reason enough to have software implemented just for LAN players and another for Web players. The frame rate will depend on player‟s connection but can reach up to six frames per second.
6. Webpage The webpage was made in HTML (Hypertext Markup Language), JavaScript and CSS (Cascade Style Sheets). The HTML is the base language used on internet pages permitting the connection between the different components of the page – image, text, graphics, etc. The JavaScript is used on calendar creation, since it‟s not static. The calendar is created in the moment that the page was loaded based on the system data. The CSS were used to format the page and allows in the future an easily change of the paper style and faster load of webpages. The different contents on the site are loaded on the initial page named index.html with the use of an iFrame (Figure 17). If the server is running for internet players, with Active® Webcam, the video transmission will be available in the page to any user.
Figure 17 – Screenshot of HoRoISEC‟s Webpage 7. Software
Figure 18 – Interface of Client‟s Software 7.2. Server’s Software The server‟s software (Figure 19) needs to be able to receive information from a different group of clients. Even if just four can play at the same time, the server is open to every client that wishes to know the state of robots (occupied or unoccupied). Besides that, the server will send captured frames to each client that connects to him through the software. We can divide server‟s software in three fundamental steps: an interruption to receive each client‟s data through TCP, an algorithm to adapt data from all clients and a timer to send information over radio frequency to all robots.
We can divide this project in two different kinds of software implementation. The user interface made in Delphi® and robot‟s code implemented on PIC® and programmed in C® language. Communications are the hardest thing to implement because it needs to be robust and fast. While clients send data to the server, the server will regroup it, adapt it, and resend it to all robots. This kind of coordination needs to be well implemented so that players won‟t feel like they‟re not controlling their robots as they want to. 7.1. Client’s Software Client‟s software (Figure 18) has three fundamental steps: a timer to read keyboard or game pad information, a timer to refresh the frame acquired by the server and a timer to send information over TCP about robot‟s movement.
Figure 19 – Interface of Server‟s Software 7.3. Robot’s Software The PIC® microcontroller executes actions while having the possibility of receiving new information at any time. We can divide the robot‟s software in two fundamental steps: an interruption to get new data received from radio frequency and timers to keep servo motors on the desired position.
8. Rules Here are some rules that players should follow while playing: The games will consist of three periods of 5 minutes each. There are only two robots on each team; Teams will have approximately 2 minutes to warm up, once the warm-up is over with, the game will start one minute after; After each period, teams will have to switch sides; When the game starts and after a goal, robots are placed on the black crosses on each side of the field and the ball will be placed in the middle of the field; After a goal, the robots that scored will have to stay still in the black crosses until one robot of the other team touches the ball;
While we contribute concretely to hockey robots, several features of the approach are applicable to general game-based adversarial environments. Furthermore, we believe that robots can be useful in other entertainment or educational tools. Acknowledgments Thanks to the Departments of Electronic and Mechanical for engineering support. References [1] [2] [3]
9. Conclusion
[4]
9.1. Future Work
[5] [6]
The communication system between server and robots should be changed to a Bluetooth® or Wireless® 802.11 interface. Bluetooth‟s Piconets [6] can support up to 1 master and 7 simultaneous slave with low power consumption and a range communication of 10 meters. Bluetooth devices are cheap and can transmit data over 1Mbit/s. Attending to our system, wireless has the unique advantage of being faster than Bluetooth. If the goal is to be able to compete against other users through the internet, the next step would be to have the choice of playing against AI. Autonomous robots are being developed day after day with complex algorithms like neural networks and genetic algorithms that implement learning methods. Those kinds of algorithms can give the possibility of true challenges, giving to robots the adaptive capability depending on the skill of the player. The need of having one player to each robot requires a group of users to play in the same team. In the most common soccer games like FIFA® or others, one user can control the whole team switching players as he desires. The other players that are not controlled by the user will be in AI mode. This will, certainly, be the next step after implementing robust AI algorithms. 9.2. Summary The project has been challenging due to data communication over the internet and has given us a lot of insight into the possibilities and problems of building robots and controlling them through the internet. To develop genuine expertise on controlling the robots it required several hours of training. The hockey robot competition might be a test platform, since we can, for instance, imagine studying the evolution of robot controllers, the evolution of communication, etc.
http://webhost.bridgew.edu/jnewcomb/history_.htm http://www.sonycsl.co.jp/person/kitano/RoboCup/RoboCupold.html Controlo de uma Equipa de Robots Móveis – Pedro Luís Cerqueira Gomes da Costa Project report Robotics and Autonomous systems - Kristofer Hallen, Johannes Hjorth and Magnus Jacobsson Modificar um Servomotor (tipo Hitech HS-311) Bluetooth – Dr. Ing. H. Ritter
Author(s) address Micael S. Couceiro, Carlos M. Figueiredo, J. Miguel Luz, Daniel D. Bastos, Nuno F. Paiva and Ricardo P. Faria, Students of Department of Electrical Engineering, Instituto Superior de Engenharia de Coimbra, R. Pedro Nunes, Quinta da Nora, 3030-199 Coimbra, Portugal, emails:
[email protected] ;
[email protected] ;
[email protected] ;
[email protected] ;
[email protected] ;
[email protected]
J. Carvalho Prof. Adj., Institute of Engineering of Coimbra, Dept. of Electrotechnical Engineering, Quinta da Nora, 3030-199 Coimbra, Portugal, email:
[email protected]
C. Lebres Eq. Prof. Adj., Institute of Engineering of Coimbra, Dept. of Electrotechnical Engineering, Quinta da Nora, 3030-199 Coimbra, Portugal, email:
[email protected]
N. M. Ferreira, Eq. Prof. Adj., Institute of Engineering of Coimbra, Dept. of Electrotechnical Engineering, Quinta da Nora, 3030-199 Coimbra, Portugal, email:
[email protected].
