ITAndroids Very Small Size League Team description paper 2016

Transcription

1 ITAndroids Very Small Size League Team description paper 2016 Igor Franzoni 1, Alexandre Muzio 1, Gabriel Ilharco 1, Gustavo Guimar 1, Lucas Lugão 1, Marcos Maximo 1 Abstract ITAndroids Very Small Size League group was created in the middle of 2013 by undergraduate students at Technological Institute of Aeronautics (ITA). Our objective at that time was to participate of the Brazilian Robotics Competition (CBR). So 2016 was dedicated to improve the strategy,optimize the sample time of all the dynamical system and improve the robot?s control system. In 2015 we participated of CBR (which happened along Latin American Robotics Competition), and we reached the 4th position in the competition. In this team report, we want to detail what we did, both in the hardware of the robots and the computer software. All in all, we will discuss the problems and some solutions to them,which we will try to implement from now on. Fig. 1. Overview of the VSS game. I. INTRODUCTION Since 2012, some members of ITAndroids, a robotics team from Technological Institute of Aeronautics (ITA) wished to participate of a non-simulated robot soccer competition,but we had no knowledge about it. Very Small Size League match our desire, so we started investing time on this game. The game is like any soccer game: the winner is the team which makes more goals. Each team has three robots that should be entirely autonomous and they are controlled by a computer that communicates with them using a radio. The position of the robots are taken through a camera that must stay 2 meters (or higher) above the field. Hence, an important rule of the game is that each team must use a specific color on the top of the robots, making them identifiable. These specific colors are standardized and are either yellow or blue. The teams always choose them before the game starts. Another important observation is that the ball is an orange golf ball. The figure 1 illustrates well the game s structure. Complete rules may be found at CBR s site [1]. This paper describes the evolution of the team since the beginning of it, i.e., we will detail the most relevant parts of the project. Sec. II explains the hardware used to create the robots and its embedded software. Sec. III presents how the vision system was built, which algorithms we used and a comparison between CPU and GPU usage. Sec. IV will describe which strategy was used. Sec. V shows the graphical user interface created to handle, in a more easy way, vision and strategy simultaneously. Sec. VI covers how we integrated the whole code, in other words, how we communicated vision, strategy, graphical interface 1 The authors are with the Autonomous Computational Systems Lab (LAB-SCA), Computer Science Division, Aeronautics Institute of Technology, Praça Marechal Eduardo Gomes, 50, Vila das Acácias, Sosé dos Campos, SP, Brazil. {franzoni315, ax.muzio lucaslugaoguimaraes,gabriel.ilharco}@gmail.com mmaximo@ita.br and robots. In every section above we will talk about the problems we faced and how we manage to deal with them in the future. Finally, Sec. VII concludes this paper. II. THE ROBOTS What we initially thought is that the robot should achieve a desired velocity, more specifically, it should control the speed of both wheels (we already assumed it would be a differential robot, we did not even imagine the possibility of an omnidirectional robot). If it is capable of doing this, then, it is able to go to any position of the field or turn a specific angle around its axis. Concluding, the main requirement of the robot is to control the velocity of each wheel. Then, this section is about how to make a robot obey to a speed message sent from a computer. We will divide this section in three subsections: the electronics, the mechanics and the embedded software. A. The Electronics The electronics are very simple and composed basically of a microcontroller, an H bridge, encoders for each wheel, motors and a radio. We will talk about each of these devices now. 1) The Radio Module: Let s start talking about the radio, since it is where everything starts. The objective of the radio is to receive a message from the computer and relay it to the microcontroller, where it will be processed. As we had no knowledge of antennas, we opted to buy a radio and ended up choosing the XBee radio, because it is very easy to use it and the whole electromagnetic part and communication protocol is transparent to the user. Basically, you only need to send a byte through the serial port to the XBee and it will send it to another XBee. Moreover, the XBee that received the byte, will send it through its serial port to another device, for example, the microcontroller. It is almost like if you had a serial wired link between the

2 Fig. 2. Xbee Trace Antenna Series 1. Fig. 3. Xbee Explorer USB. PC and the microcontroller: if you send a byte through the serial port of your PC, it appears at the serial port of you microcontroller. The XBee model we used is XBee Trace Antenna Series 1. It works with a frequency of 2.4 GHz, a RF data rate of 250 Kbps, an interface data rate of Kbps (serial port speed), its range is up to 100 m indoor and its working voltage is from 2.8 to 3.4 V. Fig. 2 shows the radio. Full details of this radio might be found at [4]. A team has three robots and one computer, so 4 XBee s are needed. For the computer, particularly, we had to buy a serial to USB converter like the XBee Explorer [5] depicted in fig. 3. The USB converter is important to configure the radios (though it is also possible to configure it using AT commands sent through any serial line). With X-CTU you can easily configure parameters like baud rate (BD parameter) of the serial interface, channel, address of the radio (MY parameter) and of the destination device (DH and DL parameters) and so on. To understand better how to program the XBee take a look at the documentation part of Digi s site [7]. For beginners, try to look for some tutorials on the internet. A nice one is how to make a serial link between the XBee s [8]. The AT mode permits only fixed addresses (both yours and the destination). If you use this mode you will have to use the same address for the radios of the robots, since the computer s XBee can have only one destination address. This was the way we first tried. We used to send a byte at the beginning of the message that indicated the ID of the robot. The microcontroller, in this case, would choose if he accepted or not the message based on the ID byte. For example, if you send the byte 0x01 (1 in decimal) and the microcontroller was programmed to accept only the ID 0x02, it would no accept the message. Nevertheless, this is a not good method, if you take performance in account, by the reason that the microcontroller would loose time rejecting messages that were not directed to it (every time you send one message, the three robots would receive them and reject or accept it later). A better way to do this is to use the API mode of the radio. In this mode, you can change the destination address, without the need to reconfigure the radio. Thus, you can have different addresses for the robot s radios and they would not loose time processing a message of another robot. Good tutorials about API mode can be found on Internet, [9] is particularly good. 2) The Motors, Encoders and Motor Driver: For the motors, we ended up buying Pololu micro motors and the fact is that almost every team uses the same motor with 50:1 reduction. Note that we did not create any requirements for the motors, they were simply chosen by experience of previous projects (they work pretty well in a line follower) and because they are relative cheap. More information might be found at [11]. A big problem of this motor is that it does not have much informations about motor constants like frictions or torque. Without this data it is quite difficult to make a good speed controller. Fig. 4. Pololu Motor with a Reduction of 50:1. Another reason to choose this motor is due to the fact that they have their own encoders. They are quadrature optical encoders with 48 counts per cycle of resolution and working voltage from 3 to 9 V. Since the encoders works with infrared light, the encoders come with two potentiometers to configure the sensors. With an oscilloscope, it is possible to calibrate the encoders. Fig. 5. Pololu Motor, Wheel and Encoder. As motor driver, we decided to use the model TB6612FNG, also from Pololu. It is a dual H-Bridge, i.e, it can control two motors independently. It fits exactly our needs, since the stall current of the motors is 1.6 A at 6 V and the driver can handle up to a 3 A current peek per channel, although it is designed to work with a continuous current of 1 A. Complete specifications may be found in [12]. Fig. 6. TB6612FNG Dual Motor Driver.

3 3) The Microcontroller: The board used is an Arduino Nano 3.0. It has the same specifications of the more famous Arduino Uno, but it is smaller and fits well to the project. The microcontroller itself is an ATMEGA 328, running at 16 MHz, with 32 KB of flash memory, 14 I/O Pins. Full specification of Arduino Nano and ATMEGA 328 might be found at [2] and [3], respectively. Fig. 7 shows the Arduino Nano. Fig. 7. Front and hear of the Arduino Nano. 4) The Power Supply: We chose a 7.4 V LiPo battery to supply power to the whole circuit. LiPo s are good for their high discharge rate, high charge capacity and light weight. We could connect the battery directly to the motors and to the Arduino, which has its own voltage regulator to 5 V and 3.3 V. This 3.3 V line was used to turn on the Xbee module and the 5 V line was used to power the encoders. More information might be found in reference [10]. in this section is explaining some problems and errors we made. First, we did not use the full capability of the encoders. As seen in the diagram, we used only one channel of the two available, because we thought that Arduino had only two external interrupt pin available, i.e., one for the left encoder and one for the right. Therefore, our encoder had its resolution halved to 24 pulses per rotation. Another problem, is that we could not measure the direction of the wheel anymore, which is something important to the speed controller. The second problem is related to the radio. It communicates with the microcontroller using a serial line. We used common digital pins from Arduino and used a serial software library to emulate serial pins. The problem is that the maximum baud rate reached was only 9600, or about 1 bit per millisecond, which is a very low speed. If we tried to use higher speeds, we started to receive wrong bits. The reason why we used emulated serial pins is that the single serial port of Arduino is already used to burn the program in the Flash Memory. Actually, the solution would use a jumper to select if the serial would be connected to the XBee or to the computer. Fig V LiPo Battery. To illustrate better the connections related to the power supply, Fig. 9 shows a connection diagram. Fig. 10. Circuit Diagram. B. The Mechanics The robot mechanics consists on two layers: one where there is the battery and the other with the electronics. Besides that, the two motors fit between this two layers. The wheels are attached to the motors and the body was 3D printed using acrylonitrile butadiene styrene (ABS). Fig. 9. Power Supply Diagram. 5) Connecting everything in the PCB: Next, we will talk about the circuit. Fig. 10 shows a scheme of the connections of the modules. We decided to modularize the board, so it would be easier to change a broken CI. What we will do C. The Embedded Software The function of the microcontroller is to process a speed message sent from a computer through a radio and control the speed of both wheels. So the first thing we need is a protocol, that is, we need to create a language that both the computer and the microcontroller understands. A fast way to do this is to send data using bits instead of bytes. Doing this will surely let send the message faster, since you have fewer bits to transmit. The protocol diagram can be seen in Fig. 12

4 Fig. 13. Logitech C920. Fig. 11. Fig. 12. Robot mechanics overview. Protocol diagram example. The communication protocol consists of 5 bytes: the first three are data bytes and are related to the speed of each motor. The checksum byte is a used to provide more reliability to the message and is done by simply summing the first bytes. The termination char byte is used to show that the message is finished. After receiving the message, the microcontroller must guarantee that the speeds received are executed. To do this, we used a simple PI controller. We ran the PI algorithm in a rate of 30 ms. We had problems to reach the desired velocity, as the encoders have low resolution and they were quite noisy. Another problem is that we did not use the two channels of the encoders, so we did not have feedback about the direction of the motor rotation, which is important to make the robot go backwards. III. THE VISION SYSTEM The Vision Systems consists of a camera working as hardware and the processing software that was created by the vision team of the ITAndroids Team. 1) The Hardware: The hardware used was a Logitech C920 camera, see the photography below. This camera was chosen without much criteria, mainly because it was a camera that showed smaller distortion compared to the former camera, which is of an unknown source, and it had a sufficiently large FOV. The resolution of the camera was sufficiently high(1080p) to be used on the software system showing a decent precision, as well as adjustable (by software) to be properly used on the Software subsystem, as the algorithm takes longer to process the image depending on the resolution. Its specs may be found in [16] 2) The Software: The Software consists of a set of algorithms that would perform the necessary tasks to extract the information from each frame. Mainly written in C++, the routine was simple: capture a frame, apply a field mask, cut the undesirable colors, find the color clusters and then extract the information of the image. Capturing the frame was quite straightforward: OpenCV would compartmentalize this subproblem and black-box it into a function called in the inner-loop of the program. Hence, this task was quite simple and showed to be a trivial one. Applying the field mask on the captured frame would work as a way of minimizing the computational effort necessary to extract the information later on. OpenCV code allowed it to be easily applied and it was also a black-box. The main issue was creating the mask of the field. A portion of the code was dedicated to calibrate this mask and it would simply retrieve a set of points from user input that were the edges of the field and then generate the mask from this set. The algorithm used to cut off the undesirable colors was a threshold on the three channels of color. Every color that didn t fit any of the predefined colors would be removed from the image by changing its pixel values to zero, in a predefined range for each channel. The predefined colors and each range were defined by an human operator in-code. Finding the color clusters was done simply using a depthfirst search. This algorithm finds the connected components of a undirected graph, by which the image can be represented. The criteria of connection used was the proximity of the pixels - or in more details only pixels that are neighbors - and the color of each. Different colors implies disconnection as well as pixels that aren t horizontal or vertical neighbors are not connected. The extraction of the information would be done in the finding color clusters algorithm and consisted of the average of the position of the pixels, that would be approximated to be the actual position of the object. Combining two of these positions enabled our team to also extract the orientation of each robot. Two small squares were used for this task on each robot, although it showed to be a very noisy way of

5 Due to its nature of being a vector field, we found that it would be extremely useful to have some kind of tool to help us visualize what was happening with the vectors while changing some constants. Added to this we found that debugging in the Simurosot simulator was really limited (figure 15 shows the Simurosot simulator). Fig. 14. Example of a univector field getting the orientation. The speed of each object would be calculated based on previous frame. Performance issues were the main focus of the Vision System. The Software had to be sufficiently fast to enable live streaming of the information to the strategy. The key points that affected performance were the frame rate of the camera and the resolution of the image. The first was and still is the main obstruction to have faster update rates. However, it is not viable for our team to purchase a camera with higher capture frame rate, as the frame rate used in the new camera(30 Hz) already enables a live stream. The resolution of the camera affects mostly the finding color cluster algorithm. It has to be sufficiently large to have a decent precision and has to be sufficiently small for the processing to be fast. 3) Final comments: The main problems of the Vision System were integration with the GUI, ease of use and software robustness. This system showed to be a very hostile one for the average user due to its pilot form and the amount of settings that had to be set manually. Provided this, the next major step into the Vision System is to create a more userfriendly way to setup these parameters and integrate it to the GUI. Also, the detection wasn t robust enough to support lighting changes as the time passed and ignore variations throughout the field. As a second major step, a more robust way of predefining colors will be coded and added to the Vision System. Fig. 15. Simurosot Simulator The solution we found was making our own simulator from scratch. Using the Monogame framework, we started by implementing a kinematic model of the robot and the same control we used in our actual strategy. Then we started adding features to help with the univector field problem. This way we could change the position of the ball, goal, robot, add obstacles and change the influence each one had over the field in real time and see the kinematic model of the robot follow the desired path. Then we could without much trouble add our changes to the Simurosot simulator and test our additions in a better model. We found that the possibility of adding any graphical elements we needed made debugging much easier and faster. Fig. 16 illustrates the use of the simulator we built, as well as the implemented univector field. IV. THE GAME STRATEGY The movement of the robots was built primarily based on a unitary vector field which is an improvement of a basic potential field, as only the desired angle is controlled. The potential field is created by setting attractive?forces? relative to the desired destination and repulsive?forces? relative to the obstacles in the way. Graphically, it can be represented by a series of directed vectors, each one pointing to the direction the robot should follow under control. Once created the field, we can easily control the robots path to the destination, avoiding collisions. One should observe that, because of the movement of the other robots (obstacles), the field changes in time and, thus, has to be actualized constantly. Figure 14 illustrates a univector field and the influences of obstacles and the destination. Fig. 16. Screen shot of our Monogame built simulator V. THE GRAPHICAL USER INTERFACE The graphical user interface is composed by the camera view, a debugger and buttons to start and stop the game. The camera view simply shows the images captured by the

6 source/ action/ communication/ interface/ localization/ modeling/ robot/ strategy/ team/ utils/ vision/ Fig. 17. C++ Compilation Process Overview camera; the debugger permit the user know what is the path planned by the strategy algorithm; the start button run the code, and the stop button makes all the robots stop. Before accessing this interface, there is another one designed for the calibration, where it is possible to adjust the color identification using. In this case, there is screen showing the user how the current calibration is recognizing the colors. VI. INTEGRATING EVERYTHING It is very important to design a system that is easily maintainable. That is what we hoped to achieve in our robot software design. A. Project Structure The robot s abstraction is composed of 5 modules, described as specific components that deal with different (and restricted) tasks. They are: Vision, Modeling, Strategy, Action and Communication. Each component plays a precise role. Each module is modeled as a class belonging to the robot entity. All the components of the robot were written using C++. The following diagram shows our choice of the code base directory tree, note that each module corresponds to a namespace and is contained in separate folders, making it easy to navigate between different units. The use of helper classes in different namespaces (utils folder) is also very good programming practice that was used. B. Project Compilation CMake files were used for the compilation of the project files. CMake files are text files that tells uses a script language (CMake) to generate makefiles. These text makefiles will tell make the compilation path. In a simplified view, a makefile consists of "rules" that relate a target (usually the name of a file that is generated by a program, e.g object files) to dependencies (prerequisites that is used as input to create the target) and the action that make should carry out. By using them, it was possible to create makefiles that already takes care of the compilation process of newly created files in the project directory. VII. CONCLUSION The vision system is one of the most relevant parts of the project since it can be used to many real life situations, such as autonomous cars, although this VSS is much simpler, it gives some start to think about more complex situations. Another crucial point of the team is the strategy, because it is responsible for the behavior of the robots. In this case, this is the part that can be highly improved. One example of how this can be done is by making possible to the robots to change functions among them, so then, depending on the situation, the attacker could substitute the goal picker. ACKNOWLEDGMENTS Acknowlodgments to ITA and FAB (Brazilian Air Force) for the support. Thanks to Poupex and Radix that gave us financial support. REFERENCES [1] Rules of VSS are available at: wp-content/uploads/2014/03/verysmall2008_en.pdf [2] Arduino Nano specification is available at: en/main/arduinoboardnano [3] ATMEGA 328 datasheet is available at: com/images/doc8161.pdf [4] Xbee Trace Antenna Series 1 specification is available at: wireless-wired-embedded-solutions/ zigbee-rf-modules/point-multipoint-rfmodules/ xbee-series1-module#specs [5] XBee Explorer USB can be found at: com/products/11373 [6] XCTU can be downloaded at support/productdetail?pid=3352 [7] Documentation of XBee can be found at: com/products/wireless-wired-embedded-solutions/ zigbee-rf-modules/point-multipoint-rfmodules/ xbee-series1-module#docs [8] XBee Serial Link tutorial can be watched at: youtube.com/watch?v=mpx3tjzve9u [9] XBee API mode tutorial can be watched at: youtube.com/watch?v=jh-giaghijw [10] Zippy 7.4 V LiPo Battery specifiation is available at: https: // ZIPPY_Compact_850mAh_2S_35C_Lipo_Pack.html [11] Pololu 50:1 motor specification available at: pololu.com/product/998 [12] TB6612NG Dual Motor Driver specification is available at: http: // [13] C++ Compilation Overview: ~mcmahon/cs241/notes/compile.html [14] How C++ Compilation Works software/make/manual/make.html#introduction [15] Makefile GNU Introduction: software/make/manual/make.html#introduction [16] Specifications on the Logitech C920 camera: logitech.com/product/9442