“LUCIAN BLAGA” UNIVERSITY OF SIBIU ENGINEERING FACULTY DEPARTMENT OF COMPUTER SCIENCE, ELECTRICAL AND ELECTRONICS ENGINEERING DISSERTATION SCIENTIFIC… [308927]
“LUCIAN BLAGA” [anonimizat]: Conf. dr. ing. Macarie BREAZU
GRADUATE:
Vasile Robert Rujan
Embedded Systems
Sibiu, 2018 –
“LUCIAN BLAGA” [anonimizat]: Conf. dr. ing. Macarie BREAZU
GRADUATE:
Vasile Robert RUJAN
Embedded Systems
(attach here the thematic plan)
[anonimizat], I decided to choose the subject that refers to a [anonimizat].
I would like to thank the teachers for their support and guidance provided during my whole school activity.
Also, I would like to thank my family for their moral support and emotional involvement.
Contents
1. Introduction 1
1.1. Background 1
1.2. RoboCup Small Size League 1
1.3. Objectives 3
2. Current state 5
2.1. Short history 5
2.2. Robocup Small Size League 2018 6
2.3. Robots used for Small Soccer League 9
2.4. Robot locomotion 10
2.5. Ball dribbling and kicking 14
2.6. [anonimizat] 19
3. Background information 23
3.1. Omnidirectional wheels 23
3.2. [anonimizat] 23
3.3. Tuning Methods of PID Controller for DC Motor Speed Control 25
4. Design of the robot 27
4.1. Overview 27
4.2. Locomotion system 27
4.2.1. Wheels 28
4.2.2. 3 omni-wheeled vs 4 omni-wheeled design 31
4.2.3. Asymmetrical arrangement of the wheels 32
4.2.4. Motors 33
4.2.5. Motors speed control 36
4.3. Dribbling system 37
4.3.1 Dribbler bar 38
4.3.2. Dribbler motor 39
4.4. Kicking system 43
4.5. Wireless communication 47
4.5.1. Communication setup 47
4.5.2. Wireless modules 48
5. Implementation 51
5.1. Overview of the robot system 51
5.2. Main board 53
5.3. Power supply 54
5.2. Robot locomotion 56
5.3. Ball dribbling 60
5.4. Ball kicking 62
5.5. [anonimizat] 65
6. Conclusions 71
References 71
Appendix 1: RoboCup Small Soccer League rules summary 71
Appendix 2: Robot code 71
Channel detail 73
Things to note: 74
References: 75
Abstract
The Robocup Small Size League is one of the Robocup soccer leagues, a friendly competition designed to advance robotics and artificial intelligence research. [anonimizat] F180, [anonimizat] a [anonimizat] a hybrid centralized/distributed system.
[anonimizat] a robot for the Small Size League is discussed. [anonimizat].
[anonimizat], followed by a series of references and annexes.
An introduction in Robocup Small Size League soccer competition was made in the 1-st chapter. Here, [anonimizat], and on the Robocup Small Size League rules.
To know the existing technologies, a comparison of the main robot systems was made between the actual competing robots. This study provides the basics for the main systems of the robot. This is presented in the 2-nd chapter of this paper.
A short presentation of the theoretical fundamentals of the methods that were used in this paper is presented in the 3-rd chapter.
In the 4-th chapter, the design of the robot systems is presented. This robot houses all the systems required to participate in the Robocup Small Size League soccer competition. To play a soccer game, the following problems need to be solved: the robot locomotion, the ball kicking and dribbling and the communication to PC.
The robot locomotion is solved by the Locomotion system. This is based on omnidirectional wheels driven by DC motors. The speed of the motors is controlled trough drivers by a microcontroller.
The ball kicking is solved by the Kicking system. This uses a solenoid to kick the ball. The kicking force can be controlled.
The ball dribbling is solved using a Dribbling system. This system uses a roller to spin the ball, driven by a DC motor. The motor speed of the dribbling system can also be controlled.
The communication with the off-field computer is solved by the Wireless communication system. To communicate with the PC, two wireless modules are used. One module is connected to de robot and the other is connected to the PC.
The implementation of the main systems on the robot is presented in the 5-th chapter. The problems encountered during the system integration and the experiments results are also presented here.
In the 6-th chapter are presented the general conclusions about this project.
1. Introduction
1.1. Background
During the time, people have tried to make any kind of devices to reduce the effort made in daily work. Some of these devices was capable to reproduce animal or human movements.
Robotics is branch of technology that deals with the design, construction, operation, and application of robots. [Oxford, 1].
A robot is a machine capable of carrying out a complex series of actions automatically, especially one programmable by a computer. [Oxford, 2012]
Robots can be used in any situation and for any purpose, but today many are used in dangerous environments (including bomb detection and de-activation), manufacturing processes, or where humans cannot survive. Much of the research in robotics focuses not on specific industrial tasks, but on investigations into new types of robots, alternative ways to think about or design robots, and new ways to manufacture them. [Wikipedia, 1]
RoboCup is an annual international robotics competition proposed [1] and founded in 1996 (Pre-RoboCup) by a group of university professors (among which Hiroaki Kitano, Manuela M. Veloso, and Minoru Asada). The aim of such a competition consists of promoting robotics and AI research, by offering a publicly appealing, but formidable challenge [Wikipedia, 2].
The goal of this project is to create a robot that meets all the requirements for RoboCup Small Size Soccer League soccer competition and therefore to be used in the development of a team of robots that would be able to participate in a RoboCup division.
1.2. RoboCup Small Size League
The Small Size league is one of the oldest RoboCup Soccer leagues. It focuses on the problem of intelligent multi-robot/agent cooperation and control in a highly dynamic environment with a hybrid centralized/distributed system [Robocup, 1]
There are two divisions in the RoboCup Small Size League, Division A and Division B. A Small Size robot soccer game takes place between two teams of eight robots each for Division A and six robots each for Division B. They use for playing a standard orange golf ball. The field of play is rectangular and have different dimensions for each division. The playing surface is green felt mat or carpet. [Robocup rules]
The field have a set of cameras shared trough a shared central vision server. The teams can get localization data from this vision equipment. The objects on the field are tracked by this vision system that processes the data from four cameras located 4 m above the playing surface. This standard vision system uses the SSL-Vision software and provide localization data via Ethernet. The vision system is an open source project maintained by the league’s community. [Robocup rules] [Robocup, 1]
The teams need to use a certain set of standardized colors and patterns on top of their robots. This are operating requirements of the shared vision system. Before a game, the two teams have a yellow or a blue color assigned. This color is used as a color marker for all the team’s robots and is placed in the center of a top plate of the robot. Around this center marker, the robot need to have four round markers with different colors, as is shown in Figure 1.1.
Figure 1.1. The Standard Color Assignments [Robocup rules]
Each robot must respect the dimensions as specified in the rules book. The robot must fit within a 180 mm diameter cylinder and must have a maximum height of 150 mm. [Robocup, rules]
The game is controlled by a referee. The robotic equipment is to be fully autonomous. To communicate with computers or networks located off the field, the robots can use wireless communication. A team use an Off-field Computer (OFC) for controlling the robots, based on the data received from the vision system and from the referee. [Robocup, rules]
The flow of data from the overhead cameras is shown in Figure 1.2.
Figure 1.2. Flow of data from the overhead cameras [Wiki, SSL]
The referee’s signaling equipment is using the Referee Box software. This is a device that convert the referee’s signals into Ethernet communication signals and then are transmitted to the teams. The Referee Box software is maintained by the SSL community. [Robocup, rules]
Dribbling devices that actively exert backspin on the ball, which keep the ball in contact with the robot, are permitted to be used. Vertical or partially vertical dribbling bars, known as side dribblers, are not permitted. [Robocup, rules]
Building a successful team requires clever design, implementation and integration of many hardware and software sub-components into a robustly functioning whole making Small Size robot soccer a very interesting and challenging domain for research and education. [Wiki, SSL]
1.3. Objectives
A complete robotic system used to play in a RoboCup Small Size League competition, is a complex system that involves not only the development of the robots that are playing on the field, but also the development of a software platform to be used on the Off-field Computer for a high level controlling of the robots.
This project is focuses on the design of one robot that will be used later to build a group of robots to play as a team in a Small Size League division.
Before starting the robot development, all requirements and limitations must be known. For this, the rules that set the design specifications, are summarized in Appendix 1.
The following objectives will have to be met to reach the goal of this research:
The design of the robot must be done in accordance with the rules of the RoboCup Small Size League;
A locomotion system should be developed to solve the robot locomotion. This should be assembled and implemented on the robot. The locomotion system should be tested and modified for accurate movement on the field.
A dribbling device should be developed to solve the ball dribbling. This should be assembled and implemented on the robot. The dribbling device should be tested and modified for an effective control of the ball.
A kicking device should be developed to solve the ball kicking. This should be assembled and implemented on the robot. The kicking device should be tested and modified for an effective ball control.
A wireless communication system need to be implemented on the robot. This should be tested and modified for an effective communication with the Off-field Computer.
The robot capabilities should be tested, and any modification should be made, after all the systems are implemented on the robot.
2. Current state
2.1. Short history
In the history of artificial intelligence and robotics, the year 1997 will be remembered as a turning point. In May 1997, IBM Deep Blue defeated the human world champion in chess. Forty years of challenge in the AI community came to a successful conclusion. On July 4, 1997, NASA’s MARS Pathfinder mission made a successful landing and the first autonomous robotics system, Sojourner, was deployed on the surface of Mars. Together with these accomplishments, RoboCup made its first steps toward the development of robotic soccer players which can beat a human World Cup champion team.
The idea of robots playing soccer was first mentioned by Professor Alan Mackworth (University of British Columbia, Canada) in a paper entitled “On Seeing Robots” presented at VI-92, 1992. and later published in a book Computer Vision: System, Theory, and Applications, pages 1-13, World Scientific Press, Singapore, 1993. A series of papers on the Dynamo robot soccer project was published by his group.
Independently, a group of Japanese researchers organized a Workshop on Grand Challenges in Artificial Intelligence in October, 1992 in Tokyo, discussing possible grand challenge problems. This workshop led to a serious discussions of using the game of soccer for promoting science and technology. A series of investigation were carried out, including a technology feasibility study, a social impact assessment, and a financial feasibility study. In addition, rules were drafted, as well as prototype development of soccer robots and simulator systems. As a result of these studies, the researchers concluded that the project was feasible and desirable. In June 1993, a group of researchers, including Minoru Asada, Yasuo Kuniyoshi, and Hiroaki Kitano, decided to launch a robot competition, tentatively named the Robot J-League (J-League is the name of the newly established Japanese Professional soccer league). Within a month, however, they received overwhelming reactions from researchers outside of Japan, requesting that the initiative be extended as an international joint project. Accordingly, they renamed the project as the Robot World Cup Initiative, “RoboCup” for short.
Concurrent to this discussion, several researchers were already using the game of soccer as a domain for their research. For example, Itsuki Noda, at ElectroTechnical Laboratory (ETL), a government research center in Japan, was conducting multi-agent research using soccer, and started the development of a dedicated simulator for soccer games. This simulator later became the official soccer server of RoboCup. Independently, Professor Minoru Asada’s Lab at Osaka University, and Professor Manuela Veloso and her student Peter Stone at Carnegie Mellon University had been working on soccer playing robots. Without the participation of these early pioneers of the field, RoboCup could not have taken off.
In September 1993, the first public announcement of the initiative was made, and specific regulations were drafted. Accordingly, discussions on organizations and technical issues were held at numerous conferences and workshops, including AAAI-94, JSAI Symposium, and at various robotics society meetings.
Meanwhile, Noda’s team at ETL announced the Soccer Server version 0 (LISP version), the first open system simulator for the soccer domain enabling multi-agent systems research, followed by version 1.0 of Soccer Server (C++ Version) which was distributed via the web. The first public demonstration of this simulator was made at IJCAI-95.
During the International Joint Conference on Artificial Intelligence (IJCAI-95) held at Montreal, Canada, August, 1995, the announcement was made to organize the First Robot World Cup Soccer Games and Conferences in conjunction with IJCAI-97 Nagoya. At the same time, the decision was made to organize Pre-RoboCup-96, in order to identify potential problems associated with organizing RoboCup on a large scale. The decision was made to provide two years of preparation and development time, so that initial group of researchers could start robot and simulation team development, as well as giving lead time for their funding schedules.
Pre-RoboCup-96 was held during International Conference on Intelligence Robotics and Systems (IROS-96), Osaka, from November 4 – 8, 1996, with eight teams competing in a simulation league and demonstration of real robot for middle size league. While limited in scale, this competition was the first competition using soccer games for promotion of research and education.
The first official RoboCup games and conference was held in 1997 with great success. Over 40 teams participated (real and simulation combined), and over 5,000 spectators attended. – See more at: http://www.robocup.org/a_brief_history_of_robocup#sthash.d4BHtrld.dpuf
2.2. Robocup Small Size League 2018
In 2018, the Robocup competition was held in Canada, in Montreal, between 18 and 21 of June. For the Small Soccer League was qualified 9 teams for Division A, and 8 teams for Division B. The teams qualified for Division A are shown in Table 2.1. and the teams qualified for the Division B are shown in Table 2.2.
Starting in 2018, the Small Size League will be divided into two divisions with separate tournaments: Division A and division B. Division A is aimed at advanced teams whereas new and/or less competitive teams can play in division B. Each team will only play in one of those two divisions.
The Organizing Committee will make division assignments based on available spots at competition, previous performance, qualification materials, and team preference.
http://wiki.robocup.org/Small_Size_League/RoboCup_2018/Divisions
Table 2.1. Small Size League Division A qualification status for 2018
Table 2.2. Small Size League Division B qualification status for 2018
For the qualifications, the teams had to submit the requested material, until January 16, 2018. One of the qualification criteria is the Team Description Paper. Every team had to submit this paper for qualifications, or, if the team was in the first 8 teams in 2017, the teams had to submit an Extended Team Description Paper.
In the Team Description Paper are described in detail the innovations that the team has produced, to facilitate reproducibility for the other teams, if they need it. The Extended Team Description Paper had to describe the aspects of the team system which contributed to success.
The RoboCup Small Size League Excellence Award is given to the team that best embodies the goals of the RoboCup Federation. This team will have notable success on the soccer pitch, share knowledge with the community, and exhibit good sportsmanship.
The RoboCup Small Size League Open Source Award goes to a team that has demonstrated a commitment to sharing and supporting their software and hardware designs for the benefit and advancement of the RoboCup community.
The RoboCup Small Size League Most Improved Team Award is given to a team that has seen the greatest improvement between the previous RoboCup competition and the current competition. The improvement can be related to game performance, robot design, or other aspects. http://wiki.robocup.org/Small_Size_League/RoboCup_2018/Awards
The winner team of Robocup Small Size League competition is XXX for Division A, and YYY for Division B. The results are shown in Table 2.3.
Table 2.3. Robocup Small Size League: winners of soccer competition
2.3. Robots used for Small Soccer League
Most of the teams have similar approach regarding the design of the robots used for the RoboCup Small Size League competition. The robots have cylindrical shapes, close to 180 mm in diameter and 150 mm height.
TIGERS Mannheim used for this year competition the robot version v2016. Having a total weight of 2.65 kg, the dimensions of the robot are 179 mm in diameter and 146 mm in height. The maximum coverage of the playing ball is 19.7%. For the robot locomotion they used omi-wheels with a diameter or 57 mm driven by Maxon EC-45 flat 50W motors and US Digital E8P encoders, with 2048 pulses per rotation. For the motion control, they used also gyroscope and accelerometer. To dribble the ball, they used a dribbling bar of 14 mm in diameter driven by a Maxon EC-max 22, 25W. For the kicker they used solenoids at high voltage with flyback converter kicker charge topology, being able to straight kick the ball to a maximum 8 m/s. For the communication with the of-field computer, they used Semtech SX1280. The robot was built based on the STM32F746 microcontroller. [Tiger mennhain]
In figure 2.1. is shown the prototype of the robot used in the RoboCup Small Size League competition by the TIGER Mannheim team.
Figure 2.1. Robot prototype of TIGER Mannheim team
The robots are covered, for a good protection of the internal components. The top of the coverage is painted in black, having sticked on it five colored papers, needed for the shared vision system.
In figure 2.2. is shown the robot, with and without the coverage, of the CMµs team, for the RoboCup Small Size League competition.
Figure 2.2. The CMµs team robot
2.4. Robot locomotion
The robot locomotion system is critical for a team to have competitive robots. Most of the teams improved the locomotion system of their robots, for this year competition. A comparison of the robot locomotion systems used this year by the teams in the RoboCup Small Size League competition in 2018 is shown in table 2.4.
Table 2.4. Comparison of robot’s locomotion systems for RoboCup Small Size League competition in 2018:
Almost all the teams that are competing in the RoboCup Small Size League used on their robots 4 omni-directional wheels for locomotion.
The ZJUNlict team has redesigned the omni-directional wheels used on their robots to reduce the polygon effect. The polygon-effect occurs due to the small wheels from the omni-directional wheel. Because of these small wheels, the shape of the section of the wheel is not perfectly round. [ZJUNlict]
Testing the prototype of an omni-directional wheel with 20 small wheels and 24 small wheels, they proved that increasing the number of the small wheels on the omni-directional wheel, the system become more stable, reducing the vibration when the robot is moving at high speeds. [ZJUNlict]
In the Figure 2.1. is shown the omni-directional wheel used by the ZJUNlict team on their robots, for the Robocup Small Size League competition in 2018.
Most used motors to drive the wheels on the robots for the RoboCup Small Size League in 2018 is the 50W Maxon flat, brushless DC motor. The motors are fixed on an aluminum chassis.
To drive the wheel, there are used direct drive motors or motors with reducers. The first version is preferred when more space is needed between the motors.
Figure 2.1: Omni-directional wheel used by ZJUNlict team in 2018 [ZJUNlict]
The wheels are placed with the axis in a diagonal position, symmetrical or asymmetrical, with a sufficient space between the front wheels for the dribbling device.
In Figure 2.2. are shown the present and the preview configuration of the wheels of the KIKS team. Figure 2.2 (a) shown the symmetrical configuration, ans Figure 2.2 (b) shown the asymmetrical configuration.
Figure 2.2. Robot wheels configuration, KIKS team. (a) preview; (b) present [KIKS]
The asymmetrical configuration brings some advantages than the symmetrical configuration. One advantage is the improvement of the running stability in front and back direction. Another advantage is the space gained for a bigger dribbling device. With a bigger dribbling device, it is easier to catch and shot a ball. [KIKS]
One disadvantage of the asymmetrical configuration is less performance of braking and moving in diagonal direction. [KIKS]
The motion control of the robots has different approach by the teams. To maintain the expected velocity and position the AIM team applied PID control on every wheel once the setpoint speed is calculated for every robot. This controller is shown in Figure 2.3.
Figure 2.3. Robot wheel speed control system – AIM team
The navigation of the robot used to be done by sending its target velocity in every command which was being sent after every frame process, thus every 60 times per second the robot receives its new target velocity. This method had some issues in producing a smooth and accurate movement. To solve this problem, we choose to send the movement displacement instead of the targeted velocity. After using this method, the robot has a better view on its movement and runs a PI (PID without the Differentiation) controlling algorithm to reach the target position in the least time. [Imortals]
An issue of our current robot-generation has been that we were driving and accelerating slower than other teams. Because of this it was difficult to realize strategic maneuvers.
New hardware is planned for the robot-generation 2018, but for the RoboCup in 2017 changing the hardware was not possible. So we had to increase the performance of the existing hardware by software, namely with work on the motion-control.
We previously used a regular PI-Controller with a static feedforward. However, a discrete state-space controller with a dynamic feedforward is significantly better. We managed to implement this for our hardware. This chapter explains the mathematical background of the controlling theory and intends to help other teams to realize a state-space-controller for their systems.
The system to be controlled is the motor of the robot. This system can be separated in two partial systems, the electrical part and the mechanical part. Both can be handled absolutely similar, so in this paper only the electrical part will be shown. In order to transfer it to the mechanical part you just have to adapt the mathematical model. The way of calculating the controller and feedforward stays the same though. [ER-Force]
Verifica pana aici sursa!!!
2.5. Ball dribbling and kicking
Like a real football player, the robot that play in the RoboCup Small Size League competition need to be able to dribble and kick the ball. For this, the teams use on their robots dribbling and kicking devices.
The dribbler device uses a roller driven by a motor to spin the ball. The dribbler device used by the NEWIslanders team is shown in Figure 2.4. A comparison between the dribbling devices used on the robots for the Robocup Small Size League competition in 2018 is shown in table 2.5.
Figure 2.4. The dribbler device used by the NEWIslander team [NEWIslander]
Table 2.5. Comparison between the dribbling devices used on the robots for the Robocup Small Size League competition in 2018
The roller used in the robots dribbling systems have different shapes and are covered with materials like robber or silicone, for a better handling of the ball. There are teams that used cylindrical dribbling bar on their robots, and teams that used 3D printed molds to cast screw-shaped rollers. This screw-shaped roller can maintain the ball in the center of the dribbling device.
The most used motor to drive the roller of the dribbling device of the robots is the 30 Watts Maxon EC 16. To transmit torque from the motors to the rollers, most of the teams used gears. The belt drives were preferred by some teams.
Figure 2.5. Screw-shaped roller used by the UBCThunderbots
For the kicking device, the teams used on their robot’s solenoids to transmit linear motion to the kicker. Most of the teams built their solenoids for the robots kicking systems for the Robocup Small Soccer League competition.
The RoboDragons built their high voltage solenoids from enameled 0.6 mm diameter wire. To power the solenoid, they use boosters build from capacitors. The electric charge of the capacitors takes about 3s for an output voltage of 200V. The ball velocity is over 8m/s using the straight kicker. [robodragons]
The RonoJackets team changed the design of their kicking device due to an issue that occurred to the old variant. After repeated kicks, one of the component of the kicking device, the threaded stud component, had an axially shifting, inducing the boot rotation. To prevent the boot rotation, they mounted to it alignment rods that go through the solenoid stand. [robojakets]
The robots kicking device of the RoboJackets team used in the Robocup Small Size League competition in 2018 is shown in Figure 2.6.
The RoboTeam Twente improved the kicking device by giving the ability to rotate it. This give to the robot the possibility to shoot the ball at a desired angle, without rotating the robot. The solution for this rotating kicker was to use a Geneva drive. This type of drive was used by another team in the previously RoboCup Small Size League competition. [roboteam twente]
Figure 2.6. Robot kicking device used by the RoboJackets
The kicker setup of the RopoTeam Twente is shoun in Figure 2.7., and the Geneva drive solution adopted by the RoboTeam Twenty is shown in Figure 2.8.
Figure 2.7. RoboTeam Twente: Top view of the kicker setup [roboteam twente]
Figure 2.8. RoboTeam Twente: Top view of the Geneva drive [roboteam twente]
Most of the teams use a chipper device to get the ball off the ground. This device uses a lever to chip the ball, actuated by a solenoid. After ball chipping, the mechanism returns to the original state, using springs. [Roboteam twente]
Usually, this mechanism is a part component of the kicking system.
In the Figure 2.9. is shown the side view of the chipper mechanism of the RoboTeam Twente.
Figure 2.9. RoboTeam Twente: Side view of the chipper mechanism [roboteam twente]
To control the solenoid, the RoboJackets team used new kicker board with an AVR microcontroller, to allow complete operation of it. On the preview generations they used IGBTs to control the solenoid current. They replaced the IGBTs with FETs due to the IGBTs overkill for current passed through the solenoid. This change helped to improve the energy efficiency for the discharge. [robojackets]
The robot’s kicker board of the RoboJackets team used in the Robocup Small Size League competition in 2018 is shown in Figure 2.10.
Figure 2.10. Robot Kicker board used by the RoboJackets
2.6. Communication with Off-field Computer
Robots communicate wireless with the off-field computers. Most of the teams used nRF24L01 modules on their robots. The Imortals team used on their robots the nRF52832 SoC, that is a powerful, highly flexible ultra-low power multiprotocol SoC, supporting a 2.4GHz radio multiprotocol, being directly accessed by the ARM processor, giving the possibility to connect the robots using the same protocol, regardless of their nRF chip. [imortals]
The TIGERs Mannheim team used on their robots the Semtech SX1280 Wireless Transceiver. The SX1280 transceiver offers LoRa, FLRC and FSK modulation modes, the team chose the FLRC modulation mode, due to the best compromise between the speed and robustness. Until 2013, they used the nRF24L01+ wireless module from Nordic Semi-conductor for the communication with the off-field computer. They changed the nRF24L01+ wireless module with the Semtech SX1280 Wireless Transceivers, because they experienced link quality and connection issues in the recent competitions. [TIGERs Mannheim]
A comparison between the nRF24L01+ wireless module and the Semtech SX1280 Wireless Transceivers is shown in table 2.6.
Table 2.6. Comparison between the nRF24L01+ wireless module and the Semtech SX1280 Wireless Transceivers [TIGERs Mannheim]
The teams have similar approach regarding the design of the data packets used for communications between the robots and the off-field computer. The Robo Team Twente changed the design of the data packets for the RoboCup Small Soccer League competition for this year, for a better understanding of the measurements done on the robot, by requesting and sending debug information. The packet sent by the off-field computer to the robot facilitate the control of the kicking device, and the packet sent by the robot to the off-field computer provide status information about the robot. [Robo team twente]
In the Figure 2.8. is shown the packet sent by the off-field computer to the robot, and in the Figure 2.9 is shown the packet sent by the robot to the off-field computer, for the Robo Team Twenty.
Figure 2.8. The packet sent by the Robo Team Twenty off-field computer [robo team twenty]
The first 8 bits from the packet from Figure 2.8., sent by the off-field computer, represents the robot ID. The packet is received by all the team robots, and the robot with the ID specified in the packet will take it consider the message.
The next 22 bits represents the robot velocity and the moving direction. The robot should move in the specified direction, with the speed specified in the data frame.
The rotating direction of the robot, R, is send on one bit, and the angular velocity is sent on 11 bits. The robot should rotate in the specified direction, with the angular speed specified in the data frame.
The next 3 bits, K, C and I, represent requests to kick or chip the ball. The first bit requests to kick the ball when the ball will be detected, the second one requests to chip the ball when the ball will be detected, and the third one requests to kick or chip immediately, without waiting to detect the ball.
The next 19 bits represents the kick power, the dribbler speed and the kicker angle.
On one bit from the data frame, D, are requested debug data from the robot. The next bit, E, indicates that this packet contains extra information. The extra information is sent on the next 32 bits and represents the position and orientation of the robot on the field, information given by the vision system.
Figure 2.9. The packet sent by the Robo Team Twenty robot [robo team twenty]
The first 8 bits from the packet from Figure 2.9., sent by the robot, represents the robot ID. The next 6 bits represents the battery status, the status of the left front wheel, the status of the right front wheel, the left back wheel status, the right back wheel status, and the rotating kicker status.
The next 22 bits represent the robot position, and the next one bit represents the rotating direction of the robot. Ne next bits from the data frame represents the angular velocity of the robot, the robot velocity, the orientation, the moving direction, the ball sensor value, the robot acceleration and the angular rate.
3. Background information
3.1. Omnidirectional wheels
The omnidirectional wheels give the possibility to a robot to drive straight on a certain path, from a given point, without having to rotate. For this reason, the omnidirectional wheels become very popular for robots. [robocup.mi.fu]
The omnidirectional wheel can roll in two different directions simultaneously. The driven axis of the wheel is the primary axis. If a motor is connected to the wheel, will drive the wheel to roll around this axis. The other axis would be allowed to roll freely in a direction that is not parallel to the driven direction. There is needed a minimum of three wheels to be monted on a mobile platform to achieve 3-DOF motion on a plane. [collectionscanada]
In the Figure 3.1. are shown 3 types of omnidirectional wheels: (a) segmented omnidirectional wheel, (b) double omnidirectional wheel, (c) mecanum wheel.
Figure 3.1. Types of omnidirectional wheels: (a) segmented omnidirectional wheel,
(b) double omnidirectional wheel, (c) mecanum wheel.
3.2. Kinematic model of omni-wheeled Robots
The omni-wheeled robots can perform various movements that are difficult or impossible for the robots with differential wheels. In terms of dexterity and driving abilities, the omnidirectional wheeled robots are superior to the differential wheeled robots. [Design and Analysis of a Four…]
In Figure 3.1. is shown the top view of an omnidirectional wheeled mobile robot, with four omnidirectional wheels.
Figure 3.1. Top view of an Omni-wheeled robot [Design and Analysis of a Four…]
– world coordinates
– robot coordinates
– radius of the wheels
– radius of the robot
– the angle between the axles of the wheels
– the angular velocity of each wheel
– the direction of the linear velocity of the center of the wheels
– the angle between the coordinates and
– linear velocity of the robot
– angular velocity of the robot
In this representation, the distance from the wheels to the center of the robots is the same distance () for each wheel. If we assume that the axis align with the 4th wheel axis, the following kinematic relation exists, [Design and Analysis of a Four…]
(1)
(2)
(3)
(4)
where
From (1), (2) and (3), the angular velocities of the wheels are derived as the function of the robot linear and angular velocities,
(5)
(6)
(7)
(8)
To obtain a certain linear speed of the robot and a certain angular speed of the robot , the angular velocity of the wheels can be determinate trough the above equations. [Design and Analysis of a Four…]
3.3. Tuning Methods of PID Controller for DC Motor Speed Control
A proportional–integral–derivative controller (PID controller or three term controller) is a control loop feedback mechanism widely used in industrial control systems and a variety of other applications requiring continuously modulated control. A PID controller continuously calculates an error value
e ( t ) {\displaystyle e(t)}
as the difference between a desired setpoint (SP) and a measured process variable (PV) and applies a correction based on proportional, integral, and derivative terms (denoted P, I, and D respectively) which give the controller its name. [Wikipedia pid]
PID [Wikipedia pid]
3.3.1. Good Gain method
3.4. Wireless communication
4. Design of the robot
4.1. Overview
To play in a Robocup Small Size League competition, a robot should be designed according to the rules book.
The overall dimensions of the robot must fit in a 180 mm cylinder and should not exceed 150 mm in height. Also, the robot must be compatible with the standardized patterns for the shared vision system. For this, the robot should be designed with a flat surface on the top side, with sufficient space available for the standardized pattern.
The standard pattern used for shared vision system from the Robocup Small Size League competition is shown in the figure 4.1.
Figure 4.1. The standard pattern for the shared vision system [rule book]
Due to the dimension limitations from the rule book, the chose solution for the robot body is a cylindrical shaped body, with a diameter between 170 mm and 180 mm, and a height close to 150 mm.
4.2. Locomotion system
The locomotion system helps the robot to move on a certain surface. In our case, the surface is a play field covered with a green felt mat or carpet.
Before starting the design of the locomotion system, we must take into consideration the application. The robot will be used to play in a RoboCup Small Size League competition. For Division A, the length of the field is 12 meters, and the width of the field is 9 meters. The robot should be able to travel fast any distance on this field.
In figure 3.1 are represented the field dimensions for Division A from the RoboCup Small Size Soccer League.
Figure 3.1. The field dimensions for Division A from the RoboCup Small Size Soccer League
The teams that participated in the RoboCup Small Soccer League competition this year, used on their robots, omnidirectional wheels driven by DC motors. All the teams used four omnidirectional wheels due to the drive efficiency, and space needed for the kicking device. For our robot we will chose the same approach.
4.2.1. Wheels
Most of the teams are using custom built wheels. Building the wheels involves a lot of effort. Before taking this option into consideration, we searched for ready-made wheels that fits to our application.
Searching on the market, we stopped on two ready-made variants for our robot:
The 60 mm Aluminum Omni Wheel from Nexus Robot
The 50 mm Omni Wheel – 4mm Bore from GTF Robots
The ready-made 60 mm aluminum omnidirectional wheels from Nexus Robot, have 10 roller wheels. The roller wheel is covered in rubber and have a diameter of 13 mm. Some advantages of this wheels are that they have two plates, are made from aluminum material, and have a good friction with the playing surface, due to the rubber material of the roller wheels.
The Nexus Robot omni-wheel is shown in figure 3.4, and the specifications of the wheel are shown in table 3.1.
Figure 3.4. The 60 mm Aluminum Omni Wheel from Nexus Robot [robotshop]
Table 3.1. The 60 mm Aluminum Omni Wheel, from Nexus Robot, specifications
The ready-made omnidirectional wheels from GTF Robots, the model SW-504, have 50 mm in diameter, and have 18 roller wheels. The roller wheel is covered in rubber and have a diameter of 8 mm. Some advantages of this wheels are that they are light, being made from aluminum material, are thin and have a good friction with the playing surface, due to the rubber material of the roller wheels.
The GTF Robots omni-wheel is shown in figure 3.4, and the specifications of the wheel are shown in table 3.1.
Figure 3.5. The 50 mm Omni Wheel – 4mm Bore from GTF Robots [robotshop]
Table 3.2. The 50 mm Omni Wheel – 4mm Bore, from GTF Robots, specifications
Comparing the two ready-made wheels, each of them has its own advantages and disadvantages.
One disadvantage of the Nexus Robor omni-wheels is the width of the wheel comparing with the GTF Robots omni-wheel. In plus, the mounting hub that is needed for the Nexux Robot wheel will increase the total width of the wheel. This will reduce the space between the motors, in consequence, will reduce the chance to find proper motors for our robot.
The space between the motors is also reduced by the wheel diameter. Because our robot has a cylinder shape, the wheel margins must fit inside this cylinder. Increasing the wheel diameter, the wheel centrum will move to center of the robot. The motors, will move also to the center of the robot, decreasing the distance between them.
Another disadvantage of the Nexus Robor omni-wheels, comparing with the GTF Robots omni-wheels is the distance between the contact points with the surface, of the roller wheels. To reduce the polygonal effect and, in consequence, the vibrations, this distance must be smaller. The Nexus Robot wheels have a much bigger distance between the contact points of roller wheels, comparing to the GTF Robots wheels.
Another disadvantage of the Nexus Robor omni-wheels, comparing with the GTF Robots omni-wheels is additional need of the mounting hub. The GTF Robots wheels have built-in mounting hub with the size of the hole, for the motor shaft, of 4 mm, making them ready to be used.
Taking all the advantage and disadvantages of the two omni-wheels, we chose for our robot the 50 mm Omni Wheel – 4mm Bore from GTF Robots.
4.2.2. 3 omni-wheeled vs 4 omni-wheeled design
Any design we chose for our robot, between a three omni-wheeled locomotion system and a four wheeled locomotion system, each of these platforms has their own advantages and disadvantages. [wheel_control_theory]
One of the advantages of using a three omni-wheel design is that the three wheeled platforms are well balanced, and the robot can move even on uneven terrain. This offers a better traction for the robot. Another advantage is the cost. Using four omni-wheels will increase the cost of the locomotion system due to the cost of the 4th wheel and the 4th motor necessary to drive this wheel. [wheel_control_theory]
One of the disadvantages of using a three omni-wheel design is that the robot will have less speed than a four omni-wheeled robot, due to the wider angles between the wheels axis. One of the disadvantages of using a four omni-wheel design is that the four wheeled platforms does not balance on uneven terrain. [wheel_control_theory]
4.2.3. Asymmetrical arrangement of the wheels
To gain more space for the dribbling device, we choose for our robot the locomotion system with the asymmetrical arrangement of the wheels. The angle between the front wheels axis is wider than the angle between the rear wheels axis.
In Figure 3.2 is represented the wheels arrangement of our robot.
Figure 3.2 The wheels arrangement of our robot.
To make the robot to move on a desired path, we apply the Kinematic model of omni-wheeled Robots from chapter 3.
4.2.4. Motors
Most of the teams used in the RoboCup Small Size League competition, for the robots locomotion, the 50W Maxon flat, brushless DC motors. These brushless DC motors are preferred by the teams because they have a flat design and they fits very wheel on the robot base plate, letting more space for the kicking device. They have a diameter of 42.8 mm and a total length of 40 mm. They work at a nominal voltage of 24 V and allows maximum speeds up to 10000 rpm. [maxon datasheet]
In the figure 4.7. is shown the Maxon EC 45 flat Ø42.8 mm, brushless, 50 Watt, with Hall sensors, and its values to the nominal voltage are shown in table 4.5.
Figure 4.7. Maxon EC 45 flat Ø42.8 mm, brushless, 50 Watt
Table 4.5 Maxon EC 45 flat Ø42.8 mm, brushless, 50 Watt, values at nominal voltage
These Maxon motors are small and powerful, making them a good choice for the robot locomotion. These motors have a high acquisition price. Because of the high price, we will search for a low-cost alternative.
We need a motor with a good stall torque at the nominal voltage, to reach in a short time the desired velocity of the robot.
The Pololu 9.7:1 Metal Gearmotor HP at 6 V is a high-power brushed DC motor with an attached metal spur gearbox and have a stall torque of 275 mNm at the nominal voltage. These motors have a diameter of 25 mm and a total length of 60.3 mm. The variant with a 48 CPR encoder have a total length of 72 mm. They work at a nominal voltage of 6 V and the no load speed at 6 V is 990 rpm.
In the figure 4.8. is shown the Pololu 9.7:1 Metal Gearmotor HP at 6 V with 48 CPR Encoder, and its values to the nominal voltage are shown in table 4.5.
Figure 4.8. The Pololu 9.7:1 Metal Gearmotor HP at 6 V with 48 CPR Encoder
Table 4.5 Pololu 9.7:1 Metal Gearmotor HP at 6 V, values at nominal voltage
We can find the force on the robot wheel from the motor torque applying the torque formula:
where,
M is the motor torque
F is the force on the robot wheel
d is the distance between the center of the wheel and the contact point with the surface
In our case, using the Pololu 9.7:1 Metal Gearmotor HP at 6 V, and the 50 mm omni wheels, the force at the robot wheel is
The resulting force of the four wheels of the robot is
From Newton’s second law we can calculate the acceleration of the robot
where,
a is the acceleration of the robot
m is the mass of the robot
If we assume a robot mass of 2 kg, then the acceleration of the robot will be
The Pololu motors have a speed at 6 V of 990 rpm. The angular velocity of the wheels is
The wheel speed is
where,
v is the wheel speed
r is the wheel radius
The maximum resulting speed of the robot, if the wheels axes are perpendicular between each other and two wheels are driven wheels and two wheels are free wheels, is
The time needed for the robot to reach this speed is
Using these Pololu motors, the robot should be able to reach speeds up to 2.59 m/s in a very short time.
The motor for the robot locomotion is the Pololu 9.7:1 Metal Gearmotor HP at 6 V with 48 CPR Encoder.
4.2.5. Motors speed control
The Pololu 9.7:1 Metal Gearmotor HP at 6 V with 48 CPR Encoder have an integrated quadrature encoder with 48 CPR on the motor shaft. This encoder provides 464.64 CPR on the output shaft of the gearbox.
Using this encoder, we will be able to control the motor speed, using a PID controller.
A PID controller (proportional–integral–derivative controller) is a control loop feedback mechanism that continuously calculates an error value as the difference between a desired setpoint and a measured process variable and applies a correction based on proportional, integral, and derivative terms. [wikipedia]
Using the following relation, we can create a PID controller algorithm, to control the speed of our motors
where,
– the control variable
– the error value
– the coefficient for the proportional term
– the integration time
– the derivative time
The relation (1) can be also written
where
and
where
– the coefficient for the integrative term
– the coefficient for the derivative term
For a desired control response, the PID controller can be tuned, by adjusting its control parameters to the optimum values.
In our application, the PID output is the PWM duty cycle for the motor drive.
4.3. Dribbling system
The dribbling system helps the robot to dribble the ball. Before starting to design the dribbling sistem, we must take into consideration the rules from the rule book for the RoboCup Small Size League soccer competition.
One of the rules from the rule book says that are accepted only devices that exert spins of the ball perpendicular to the playing ground. [rule book]
All the teams that participated this year in the RoboCup Small Size League competition used on their robots dribbling bars parallel to the playing ground, with different shapes and dimensions. We will choose for our robot a similar design.
In the figure 4.3. is shown how a dribbler may work on a robot for the RoboCup Small Size League soccer competition.
Figure 4.3. How a dribbler may work [rule book]
Another rule from the RoboCup Small Size League competition is the 80/20 rule. This rule says that the ball should be visible from above in a proportion of 80% when a robot is holding it. Also, the ball must not be inside the convex hull more than 20%, giving the possibility to another robot to remove the ball. [rule book]
In figure 4.4. is shown the 80/20 rule for the RoboCup Small Size League soccer competition.
Figure 4.4. 80/20 ball covering rule. [rule book]
4.3.1 Dribbler bar
We want to place the dribbler device in the front of the robot. The position of the dribbler bar is established by the 80/20 rule and by the diameter of the dribbler bar. Knowing the ball diameter and the dribbler bar diameter, we can calculate the position from the ground of the dribbler bar.
In the figure 4.5. is shown the dribbling device setup.
Figure 4.5. Dribbler setup
D: diameter of the ball
d: diameter of the dribbler bar
H: height of the dribbler bar
The diameter of the ball is 43 mm. For the dribbler bar, we chose a diameter of 18 mm. knowing these dimensions, and based on the 80/20 rule, the maximum height of the dribbler bar can be:
The dribbler bar will be placed on the robot on a height of 42 mm.
4.3.2. Dribbler motor
Most of the teams used on their robots in the Robocup Small Size League competition the Maxon EC 16 Ø16 mm, brushless, 30 Watt, with Hall sensors. These motors are working at high speeds, having a nominal speed of 39300 rpm.
In the figure 4.7. is shown the Maxon motor EC 16 Ø16 mm, brushless, 30 Watt, with Hall sensors, and its values to the nominal voltage are shown in table 4.5.
Figure 4.7. The Maxon motor EC 16 Ø16 mm, brushless, 30 Watt, with Hall sensors
Table 4.5 The Maxon motor EC 16 Ø16 mm, brushless, 30 Watt, with Hall sensors, values at nominal voltage
The encoder is attached to the motor, on the motor shaft. Using this encoder, the robot will be able to control the rotation speed of the dribbler bar, for a better control of the ball. If the robot will move forward, will need a lower rotation speed for the dribbler bar, and if it is moving backward, the robot will need a higher rotation speed for the dribbler bar.
These Maxon motors are a good choice for the robot dribbling system, having a high speed and a good torque. These motors have a high acquisition price, and, because of the high price, we will search for a low-cost alternative.
The Pololu 4.4:1 Metal Gearmotor HP at 6 V is a high-power brushed DC motor with an attached metal spur gearbox and have a stall torque of 141 mNm at the nominal voltage. These motors have a diameter of 25 mm and a total length of 72 mm, for the variant with a 48 CPR encoder. The nominal voltage is 6 V and the no load speed at 6 V is 2150 rpm.
In the figure 4.8. is shown the Pololu 4.4:1 Metal Gearmotor HP at 6 V with 48 CPR Encoder, and its values to the nominal voltage are shown in table 4.5.
Figure 4.8. The Pololu 4.4:1 Metal Gearmotor HP at 6 V with 48 CPR Encoder
Table 4.5 Pololu 4.4:1 Metal Gearmotor HP at 6 V, values at nominal voltage
At the nominal voltage, the no load speed is 2150 rpm. We will use a 1:2 spur gear to transmit the torque to the dribbler bar. Doing this, the dribbler bar will have a speed, at the nominal voltage of the motors, of 4300 rpm.
The ball diameter is 43 mm. Having a dribbler bar of 18 mm, the spinning speed of the ball, at the nominal voltage of the motors, will be
During the game, the spinning speed of the ball can be boosted up with 25%. This boost can be possible by powering the motors for short periods of time with an increased voltage value of 25%. The effect of this boost will consist in a reduction of the lifetime of the motor. The spinning speed of the ball will be in this case
Even if the spinning speed of the ball is much lower than of the other teams, we chose the Pololu 4.4:1 Metal Gearmotor HP at 6 V for our dribbling system. The spur gear can be modified for a higher spinning speed of the ball, if the dribbling device will not be able to control the ball in the real application.
In figure 4.6. is represented the dribbling device for our robot. The dribbler bar (2) is driven by the motor (1). The torque is transmitted from the motor to the dribbler bar trough the spur gear (4).
Figure 4.6. The dribbling device representation
1 – DC motor with encoder
2 – Aluminum chassis
3 – Dribbler bar
4 – spur gear
4.4. Kicking system
The kicking system helps the robot to kick the ball, to pass to another team player robot, or to kick the goal. One of the rules for the RoboCup Small Size League soccer competition says that if the ball kicked by a robot exceeds 6.5 m/s, the opposite team receive an indirect free kick. [book rule]
To make the ball reach speeds close to this limit, most of the teams used custom built kicking devices based on high voltage custom built solenoids.
Usually, the kicking system have two devices:
The kicker device, or the straight kicker, is the primary kicking device and is used to kick the ball on the ground, to a straight path, to pass or to score a goal.
The chip kicker device is the secondary kicking device and is used to kick the ball off the ground, over the opposite robots, to score a goal or to give elevated “chip kick” passes to the other team robots.
Not all the teams used on their robots, chip kicker devices. Also, we will not use this device on our robot. The focus is to build a kicker device, used for straight kicks.
We will use on our robot a custom-built kicker device, based on a ready to use solenoid.
Searching on the market, a real challenge was to find solenoids that fits to our application. The limited space between the motors make the search even harder. We found two variants:
Linear solenoid, 12 VDC, 60 ohm, 2.4 W, Push mode, Continuous – from Multicomp
STA® Push DC Tubular Solenoid, 12VDC, 20.7 ohm, 7 W, Push mode, Continuous – from Ledex – Johnson Electric.
Comparing the two variants, we will choose the solenoid to be used in the kicking system
on our robot based on the force of the solenoid depending on the stroke.
In Figure 4.7. is shown the stroke versus force diagram of the Multicomp solenoid.
Figure 4.7. Stroke versus force – Multicomp solenoid [datasheet]
The maximum force of the Multicomp solenoid at 12 V is close to 2 N. The maximum force of the solenoid is around 7 N, at 38 V, using it in an intermittent mode, with a maximum duty cycle of 10%. The maximum ON time for 10% duty cycle is 3 s.
In Figure 4.8. is shown the stroke versus force diagram of the Ledex solenoid.
Figure 4.8. Stroke versus force – Ledex solenoid [datasheet]
The maximum force of the Ledex solenoid at 12 V is close to 9 N. The maximum force of the solenoid is around 22 N, at 38 V, using it in an intermittent mode, with a maximum duty cycle of 10%. The maximum ON time for 10% duty cycle is 15 s for a single pulse.
To calculate the velocity of the ball, kicked by these two solenoids, we will apply the impulse theory: [wiki impulse]
where is the resultant force applied from to .
From Newton’s second law we have:
From (1) and (2) results:
As the result we have:
where
m is the mass of the object,
F is the resultant force applied,
is the time when the impulse begins,
is the time when the impulse ends,
is the initial velocity of the object,
is the final velocity of the object.
Let’s suppose that we apply the maximum force of each solenoid at 12 V, to the golf ball, for 0.05 seconds. The time when the impulse begin is , and the initial velocity of the object is .
The ball velocity, if the ball is kicked by the Multicomp solenoid, is:
The ball velocity, if the ball is kicked by the Ledex solenoid, is:
These are hypothetical values, using the maximum forces of the solenoids at 12 V to calculate these values. In the real application we must consider the average forces of the solenoids and the speed of the pluggers, at the same voltage.
Considering (4) and (5), the Ledex solenoid is the choice for our project.
In figure 4.9. is represented the kicker device that will be implemented on our robot. When powered, the solenoid (1), fixed on kicker body (3) will move the plugger (2) to kick the ball with the boot (4). Two alignment rods (5) are mounted on the kicker body, to prevent the rotation of the boot. After the boot kicks the ball, the kicker device returns to the initial state through a spring that pull the plugger to home position. The spring used for this action is not represented in the figure.
Figure 4.9. The kicker device representation
1 – Solenoid
2 – Plugger
3 – Kicker body
4 – Kicker Boot
5 – Alignment rods
4.5. Wireless communication
The wireless communication system is used by the robot to communicate with the off-field computer. Before starting the design of the wireless communication system, we must take into consideration the rules for the RoboCup Small Size League competition, and the application.
One of the rule say that are not allowed Bluetooth wireless communications. Another rule says that if the teams have common preferred fervency for the wireless communication, the teams should be able to swap the allocation of the frequencies. [rule book]
During the game, the robot will be located at distances up to 15 m, from the off-field computer. The robot should be able to communicate with the off-field computer, at these distances.
Taking this into consideration, the communication system for our robot should:
not use Bluetooth communication;
have the possibility to communicate on different, selectable, channels;
exceed 15 m transmission distance.
4.5.1. Communication setup
We will use for the wireless communication two wireless RX-TX modules based on the same protocol. One module will be connected to our robot and the other module will be connected to the off-field computer.
In figure 4.5. is shown the wireless communication setup for our application.
Figure 4.5. Wireless communication setup
1 – Our robot
2 – Robot wireless module
3 – Robot wireless module antenna
4 – Off-field computer
5 – Off-field computer wireless module
6 – Off-field computer wireless module antenna
In figure 4.5., our robot (1) will transmit and receive wired the data packet to and from the robot wireless module (2). The robot wireless module will send wireless, trough the antenna (3), the data packet received from the robot, to the off-field computer wireless module (5), and will send wired the data packet received from the off-field wireless module, to the robot. The off-field computer wireless module will send wired the data packet received from the robot wired module, to the off-field computer, and will send wireless, through the antenna (6) the data packet received from the off-field computer, to the robot wireless module.
4.5.2. Wireless modules
Most of the teams used for the communication with the off-field computer, wireless modules based on the nRF24L01+ transceiver from Nordic Semi-conductor. This transceiver is on-air compatible with other transceivers from Nordic Semi-conductor like nRF2401A, nRF2402, nRF24E1 and nRF24E2. This transceiver operates in 2.4 GHz ISM band, with 250 kbps, 1 Mbps and 2 Mbps on air data rates.
There are a lot of wireless modules from different producers, based on the nRF24L01+ transceiver, on the market. We stopped on the nRF24L01 module from SparkFun. This module has a Reverse Polarized SMA Connector for external 2.4 GHz Antenna, allowing transmissions up to 100 m at 250 kbps with an appropriate antenna.
In Figure 4.8. is shown the nRF24L01 wireless module from SparkFun, and its specifications are shown in table 4.5.
Figure 4.8. The nRF24L01 wireless module from SparkFun
Table 4.5 The specifications of the nRF24L01 wireless module from SparkFun
Another wireless modules preferred by the teams in the robotic competitions are based on the Zigbee protocol. One of this module is the XBee S2C from Digi International. XBee S2C is based on the Silicon Labs EM357 SoC radio ICs, utilizing 32-bit ARM Cortex™ M3 processor. The module operates in 2.4 GHz band with 250 kbps data rate and have a transmit range up to 60 m for indoor applications and up to 1200 m for outdoor applications.
In Figure 4.8. is shown the XBee S2C wireless module from Digi International, and its specifications are shown in table 4.5.
Figure 4.8. The XBee S2C wireless module
Table 4.5. The specifications of the XBee S2C wireless module from Digi International
One important criteria in choosing the wireless module for our application is the transmission range. Even if the nRF24L01 wireless module from SparkFun supports data rates up to 2 Mbps, at 250 kbps the transmission range is only up to 100 m, with an appropriate antenna. The XBee S2C have a transmission range up to 1200 m outdoor, and up to 60 m indoor.
Transmit power and receiver sensitivity are two parameters that are essentially to consider when trying to determine the range. The XBee S2C module have a better sensitivity on the receiver, increasing the transmission range.
Both wireless modules fit to our application. The nRF24L01 wireless module from SparkFun have a higher acquisition price than the XBee S2C module. Also, the nRF24L01 wireless module require a separate antenna that will increase the final cost.
We will choose for our application the XBee S2C module from Digi International.
5. Implementation
5.1. Overview of the robot system
A real challenge of this project is the robot system integration. To implement al the systems of the robot, we start first with the robot body. The robot’s body consists in a strong chassis on which are fixed all the robot components, and a cover that protect the robot components.
The robot’s chassis consists in three plates fixed together with four supportive columns. The plates used for the chassis are 4 mm plates made from Methyl polymethacrylate.
On the base plate of the chassis are fixed the motors used for robot locomotion, the dribbling device and the kicking device. The base plate is holding also the main power supply. If, during the game, the material used for the base plate will prove to be not strong enough, we will consider replacing the base plate with an aluminum alloy one.
On the middle plate of the chassis are fixed the locomotion system motor drivers. To have enough space for the robot locomotion motors and for the kicking device, the middle plate is placed at 41 mm distance from the base plate. Also, the middle plate shape let us fit the dribbling device and the main power supply on the robot.
On the top plate of the chassis are fixed the robot main board, the dribbler motor driver, a 5 V power supply, the kicker solenoid driver, the 32 V power supply, and a voltmeter.
The robot cover consists in three cover pieces fixed together with rivets and screws. The lateral cover has a 1.5 mm thickness and is made from Polyvinyl chloride matte black painted. The front cover plate has a 4 mm thickness and is made from Methyl polymethacrylate matte black painted. The top cover plate has a 2 mm thickness and is made from Methyl polymethacrylate matte black painted.
On the top cover plate are sticked the colored papers for the shared vision system color pattern.
In figure 5.1. is shown our robot for the Robocup Small Size League soccer competition ((a) with cover, (b) without cover) and in Table 5.1. are shown the robot main components.
Figure 5.1. Our robot for the Robocup Small Size League soccer competition
(a) with cover, (b) without cover
Table 5.1. The main components of our robot for the Robocup Small Size League soccer competition.
5.2. Main board
The robot main board is an Arduino Mega 2560 based on the Atmel ATmega2560 microcontroller. The Arduino Mega 2560 has 54 digital I/O pins, 15 of them can be used for PWM control, 16 analog input pins, 4 UART communication interfaces and a USB port.
In figure 5.2. is shown the Arduino Mega 2560 board used on our robot, and its specifications are shown in table 5.1.
Figure 5.2. The Arduino Mega 2560 board used on our robot
Table 5.1. Specifications of the Arduino Mega 2560 board used on our robot
The Arduino Mega 2560 board is used for the robot locomotion system control, for the ball dribbling and kicking control and for wireless communication with the off-field computer. The board is powered from a 5 V voltage regulator, trough the Vin pin.
5.3. Power supply
To power different components of our robot with the recommended voltage, we use three different power supplies.
The main power supply is used to power with energy the entire robot. It is based on 4 x LG LGABD11865 3000 mAh 10 A 3.7 V Li-ion rechargeable battery, and have a nominal voltage output of 7.2 V.
In figure 5.3. is shown the main power supply of the robot and its specification are shown in Table 5.2.
Figure 5.3. The main power supply of the robot
Table 5.3. Specifications of the main power supply of the robot
For a visual check of the voltage output of the main power supply, a digital voltmeter is used, with a LED display. Is a V20D Dual-Wire 0.36" LED Digital Voltmeter Module, with red LED light, having the measurement range is between 2.5 V and 30 V DC.
In figure 5.4. is shown the V20D Dual-Wire 0.36" LED Digital Voltmeter Module used to check the main power supply voltage output.
Figure 5.4. The V20D Dual-Wire 0.36" LED Digital Voltmeter Module
The second power supply is a Pololu 5 V Step-Down Voltage Regulator, used to power the Arduino Mega 2560 board and other robot components that need a regulated 5 V power supply. This switching step-down voltage regulator takes the input voltage of 7.2 V, received from the main power supply, and reduces it to 5 V. The 5 V Step-Down Voltage Regulator have a 700 kHz switching frequency and a typical continuous output current of 7 A.
In figure 5.5. is shown the 5 V Step-Down Voltage Regulator. (a) unmounted [pololu], (b) mounted on our robot.
Figure 5.5. The 5 V Step-Down Voltage Regulator
(a) unmounted [pololu], (b) mounted on our robot.
The third power supply is an adjustable 9-30 V Step-Up Voltage Regulator, used to power the kicker solenoid. This switching regulator from Pololu takes the voltage received from the main power supply and generate higher output voltage between 9 V and 30 V, adjustable, allowing input currents up to 5 A.
In figure 5.6. is shown the adjustable 9-30 V Step-Up Voltage Regulator. (a) unmounted [pololu], (b) mounted on our robot.
Figure 5.5. The adjustable 9-30 V Step-Up Voltage Regulator
(a) unmounted [pololu], (b) mounted on our robot.
5.2. Robot locomotion
The robot is moving on the field surface using four aluminum omni wheels, from GTF Robots, with a diameter of 50 mm, driven by four high power motors at 6 V, from Pololu.
The motors have a 9.7:1 metal gearbox attached in the front, and a 4 mm output shaft to attach the wheels. In the back, the motors have attached to the shaft a 48 CPR Encoder.
The motors are controlled using the main board, Arduino Mega 2560, based on the Atmel ATmega2560 microcontroller, through the dual VNH5019 motor driver shields from Pololu.
The motors are fixed on the robot base plate using aluminum brackets at the specified angles. The front motors have angle between axes of 110° and the back motors have an angle between axes of 90°.
On the middle plate are fixed the dual VNH5019 motor driver shields from Pololu. Having 4 motors, we use two dual driver shields.
In figure 5.6. are shown the motors fixed on the base plate (a) and the dual VNH5019 motor driver shields fixed on the middle plate (b).
Figure 5.6. (a) the motors fixed on the base plate
(b) the dual VNH5019 motor driver shields fixed on the middle plate
In figure 5.7 is shown the robot locomotion block diagram.
Figure 5.7. The robot locomotion block diagram
The main power supply is powering the motors, trough the dual motor driver shields, and the 5 V Step-up voltage regulator. The 5 V Step-up voltage regulator is powering the Arduino Mega 2560 board and the motors encoders.
To control the motors speed, a PID controller is used. A PID algorithm is implemented on the Arduino Mega 2560 board. The quadrature encoders placed on the motor shafts, have a resolution of 48 counts per motor rotation. The exact gear ratio of the gearboxes attached to the motors is 9.61:1. As a result, we will have 464.64 CPR on the gearbox output shaft and, in consequence, on the wheels.
The quadrature encoders are powered trough the 5 V Step-down voltage regulator. The encoder outputs are square waves from 0 V to 5 V approximately 90° out of phase. The transitions order gives the direction and the transitions frequency gives the speed of the motor. The speed of the motor is the measured process variable for the PID controller.
The PID algorithm calculates an error as the difference between the desired speed of the motor and the measured speed of the motor, applying corrections, to minimize the error over time, basted on the proportional, integral, and derivative terms, by adjusting the PWM signal for that motor.
Arduino Mega 2560 board have six external interrupt pins. We use four external interrupt pins and four digital I/O pins for the motor encoders.
The motors are PWM controlled trough the dual VNH5019 motor driver shields. The PWM signal is adjusted by the PID algorithm resulting a PWM output on the driver’s motor output that will increase or decrease the motor speed.
In figure 5.8. is shown the connection diagram between the dual VNH5019 motor driver shield and the microcontroller. The gray connections are not required and was not implemented.
Figure 5.8. The connection diagram between the motor driver and the microcontroller [pololu]
M1A and M1B are the motor 1 outputs
M2A and M2B are the motor 2 outputs
VIN and GND are connections for the motor power supply. The motor power supply is the main power supply.
VDD and GND are connections for the logic power supply. The GND pins are sharing a common ground.
M1INA and M1INB are the motor 1 direction inputs
M1PWM is PWM input for Motor 1
M2INA and M2INB are the motor 2 direction inputs
M2PWM is PWM input for Motor 2
Controlling the motors speed, the robot should be able to move on any desired trajectory on the field surface.
The first tests of the robot locomotion showed that the robot was not able to drive on a straight path. Wi will try to improve the robot locomotion by tuning manually the PID controller.
In figure 5.8. are shown the motors step response, before and after the PID tuning process.
ATENTIE AICI!!!
After the tuning process of the PID controller, an improvement was observed, but the robot still has problems in driving on straight pats. During the game, the robot will be tracked by the shared vision system, the off-field computer being able to correct the robot trajectory.
5.3. Ball dribbling
To dribble de ball, a dribbling device was build. The ball is dribbled using a roller based on an aluminum shaft covered with a non-repulsive rubber. The roller has a diameter of 18 mm and a length of 75 mm. The roller is driven by a high-power motor at 6 V from Pololu, through a spur gear. A metal gearbox is attached to the motor wit a gear ratio of 4.4:1 on the output shaft. In the back, the motors have attached to the shaft a 48 CPR Encoder. The encoder is used to control the spinning speed of the roller.
The roller and the motor are fixed together on an aluminum body. The dribbler device is fixed to the robot base plate, in the front of the robot.
The motor is controlled through a VNH5019 motor driver carrier from Pololu. The motor driver is fixed on the robot chassis top plate.
In figure 5.9. is shown the dribbler device unmounted on the robot (a) and the VNH5019 motor driver carrier mounted on the robot (b).
Figure 5.9. (a) the robot dribbler device
(b) the VNH5019 motor driver fixed on the top plate
In figure 5.10 is shown the robot dribbling system block diagram.
Figure 5.10. The robot dribbling system block diagram.
The dribbler motor is powered from the main power supply trough the VNH5019 motor driver. The 5 V Step-up voltage regulator is powering the Arduino Mega 2560 board and the motor encoder. Also, the motor driver is connected to the 5 V Step-up voltage regulator for the logics level.
The robot should be able to control the roller speed. A lower speed is needed for the dribbler roller while driving the robot forward and a higher speed is needed for the dribbler roller while driving backward.
The VNH5019 motor driver motor output is PWM controlled. The PWM signal is adjusted by a PID controller implemented on the Arduino Mega 2560. The quadrature encoders have a resolution of 48 counts per motor rotation. With a gearbox gear ratio of 4.4:1, we will have 211.2 counts per roller rotation. Based on the encoder counts, we can calculate the roller speed. The roller measured speed is an input for the PID controller, together with the desired speed. The PID controller will adjust the PWM signal to obtain a roller speed close to our desired speed.
To transmit the torque from the dribbler roller to the ball, the roller is covered in a non-repulsive rubber material.
The first material used to cover the aluminum shaft of the roller was from polyolefin. During the first tests was observed a high slippering between the roller and the ball. To reduce the slippering, the material used to cover the aluminum shaft of the roller was 100% synthetic rubber.
In figure 5.11. is shown the dribbler device spinning the ball with 100% synthetic rubber covered roller.
Figure 5.11. The dribbler device spinning the ball
The 100% synthetic rubber have non-repulsive properties. Using this rubber for the roller cover decrease the roller slippering, increasing the ability of the robot to control the ball.
During the tests was observed that the robot is losing the ball while driving backward. To solve this issue, the roller speed is boosted by increasing the voltage with a maximum 25% over the nominal voltage, while driving backward. An improvement was observed, but the ball dribbling was still difficult while driving backward.
The roller speed can be changed by changing the gear ratio between the motor and the roller. For future applications it is recommended to change the gear ratio of the spur gear to obtain higher spinning speeds of the ball.
5.4. Ball kicking
To kick the ball, a kicker device was built. The kicker device has an aluminum body that is fixed on the robot chassis base plate. The main component of the kicker device is a push DC tubular solenoid from Ledex, Johnson Electric. The solenoid body is made from aluminum and the plugger is made from steel. The kicker has a steel boot fixed on the solenoid plugger. When the solenoid is powered, the plugger will be pushed to the front and the boot will kick the ball.
Clontrolling the solenoid voltage, the kicking force can be controlled. The solenoid is controlled through a VNH5019 driver carrier from Pololu. The driver is fixed on the robot chassis top plate. For solenoid control is used the Arduino Mega 2560 board.
When the solenoid is powered, the plugger is pushed to the front. To return the plugger to the initial position, a spring is used on the kicker device.
In figure 5.11 is shown the kicker device unmounted on the robot (a) and the VNH5019 driver carrier from Pololu mounted on the robot (b).
Figure 5.9. (a) the robot kicker device
(b) the VNH5019 driver fixed on the top plate
In figure 5.12. is shown the kicking system block diagram.
Figure 5.10. The robot kicking system block diagram.
The solenoid is powered from an adjustable 9-30 V Step-Up Voltage Regulator, through the VNH5019 driver carrier. This voltage regulator takes the voltage received from the main power supply and generate higher output voltage between 9 V and 30 V. The output voltage can be manually adjusted.
The Arduino Mega 2560 is powered from a 5 V Step-down voltage regulator. Also, the solenoid driver is connected to the 5 V Step-up voltage regulator for the logics level.
A PWM signal is generated from the Arduino Mega 2560 board. The solenoid driver output corresponds to the PWM signal generated. The maximum kicking force is gained using a PWM signal with a 100% duty cycle.
Testing the kicking device, a very low kicking force was observed while powering the solenoid at the nominal voltage of 12 V. The solenoid can be powered at higher voltages as is described in the datasheet. The solenoid is designed to work in a continuous mod at 12 V nominal voltage. At higher voltages, the solenoid can work in an intermittent mode. For example, at 17 V, the solenoid can be on for a certain time and should rest for the same time. The solenoid can be on only 50% from the total working time. The effect of powering the solenoid at a higher voltage is a reduction of the on time. If we power the solenoid at 38 V for 100 ms, the solenoid should rest for 900 ms.
In figure 5.13. is shown the kicking device mounted on the robot while kicking the ball. (a) before kicking, (b) during kicking, (3) after kicking
5.13. The robot kicking device while kicking the ball.
(a) before kicking, (b) during kicking, (3) after kicking
Testing the solenoid at higher voltage, an improvement in the kicking force was observed, but was not enough for our application. The solenoid was tested at maximum voltages of 17 V. Over this voltage, the solenoid driver is activating the protection mode.
For future applications is recommended to improve the powering method of the solenoid. A high voltage discharge circuit based on voltage boosters and electrolytic capacitors should be considered for future development.
5.5. Communication with Off-field Computer
The robot communication with the off-field computer is based on the XBee S2C wireless modules from Digi International. The XBee S2C modules are using the ZigBee protocol. One XBee S2C module is connected to the robot and the other is connected to the off-field computer.
In figure 5.15 is represented the communication system with the off-field computer using the XBee modules.
Figure 5.15. Communication system with the off-field computer using the XBee S2C modules
The robot XBee module is connected to the Arduino Mega 2560 using a ready-made shield from Sparkfun. The shield is mounted directly on the Arduino board and on the shield is mounted, using the dedicated shocked, the XBee S2C module.
The other XBee S2C module is connected to the off-field computer using the XBee explorer USB from Sparkfun. This is a simple to use explorer board based on the FT231X USB to Serial converter.
In figure 5.15 is shown the XBee S2C module connected to the XBee shield (a) and the XBee shield connected to the Arduino Mega 2560 board (b).
In figure 5.16 is shown the XBee S2C module connected to the XBee explorer.
Figure 5.15 (a) The XBee S2C module connected to the XBee shield
(b) The XBee shield connected to the Arduino Mega 2560 board
Figure 5.16 The XBee S2C module connected to the XBee explorer
The message with the desired actions for the robot, is sent from the off-field computer through USB to the XBee S2C module connected to the XBee Explorer. The XBee Explorer translate the message for the XBee module. The XBee S2C module take the translated message and send it wireless to the other XBee S2C modules. The XBee S2C module connected to the robot take the message received wireless and send it to the Arduino Mega 2560 board trough the UART interface.
In figure 5.17 is represented the connection between the XBee S2C module and the Arduino Mega 2560 board.
Figure 5.17 Connection between the XBee S2C module and the Arduino Mega 2560 board.
The Xbee S2C module is sending data to the Arduino board trough the DO (data out) pin and receive data from the Arduino board through the DI (data in) pin.
During the tests was observed that the Arduino board don’t received always the data, even if the receiving LED from the XBee Shield was on. This problem occurred because we used the Arduino’s hardware UART (RX0 and TX0 pins) to communicate with the XBee module.
We decided to use, for the communication, the Software Serial library. This library allows the serial communication through the digital I/O pins. Not all the digital I/O pins of the Arduino board can be used as RX pins. To communicate with the XBee module, we decided to use pins 10 and 11 of the Arduino board. The connection between the Arduino shield and the Arduino boar was removed on the pins 0 and 1, and, using two wires, the pins 0 and 1 of the Arduino shield was connected to the pins 10 and 11 of the Arduino board. In this way, the DO (data out) pin of the XBee module was connected to pin 10 (RX) of the Arduino board, and DI (data in) pin of the XBee module was connected to pin 11 (TX) of the Arduino board.
To communicate between them, the XBee modules needed to be configured. The XBee modules can be configured to be used in a mesh network. One of the XBee module needs to be configured as a coordinator and the odher modules can be configured as routers or end devices.
The XBee S2C module connected to the off-field PC was configured as a coordinator and the XBee S2C module connected to the robot was configured as a router.
To configure the XBee modules, was used the XCTU program from Digi international. The XCTU program was installed on a computer and the XBee modules was connected to the computer trough an XBee Explorer USB from Sparkfun.
The following parameters was configured on the XBee modules:
ID (PAN ID): to be in the same network, the PAN ID needs to be the same on all the XBee module from our network. The PAN ID defines the network that an XBee module will attach to. Randomly, the number 2018 was chose for the PAN ID. In figure 5.15. is shown the PAN ID configuration of the XBee modules, using the XCTU program.
Figure 5.15. PAN ID configuration using the XCTU program
JV (Channel Verification): The Channel Verification parameter verify if a coordinator exists on the same channel. If exists, the XBee module will join the network, if not exists, the XBee module will leave the network. On the XBee module connected to the off-field computer, this parameter was disabled, and on the XBee module connected to the robot, this parameter was enabled. In figure 5.16. is shown the Channel Verification configuration of the XBee module connected to the robot, using the XCTU program.
Figure 5.16. Channel Verification configuration using the XCTU program
CE (Coordinator Enable): The Coordinator Enable parameter sets the XBee module as a coordinator. This parameter was configured as enabled on the XBee module connected to the off-field computer and as disabled on the XBee module connected to the robot. In figure 5.17 is shoun the Coordinator Enable configuration on the XBee connected to the off-field computer, using the XCTU program.
Figure 5.17. The Coordinator Enable configuration using the XCTU program.
DH (Destination Address High): Destination Adress High parameter defines the module address (high part) to transmit the data to. When only two modules are connected in a network, the Destination Address High parameter on one module can be configured to correspond with the Serial Number High parameter from the other module. Using multiples modules in the network, during the game, the Destination Address High parameter is set to 0 on all XBee modules.
DL (Destination Address Low): Destination Adress Low parameter defines the module address (low part) to transmit the data to. When only two modules are connected in a network, the Destination Address Low parameter on one module can be configured to correspond with the Serial Number Low parameter from the other module. Using multiples modules in the network, during the game, the Destination Address Low parameter is set to FFFF on the XBee module connected to the off-field computer and to 0 on the XBee modules connected to the robots.
NI (Node Identifier): Node Identifier parameter is used to define a name for the XBee module, to be easy identify. In figure 5.18 is shown the configuration for the XBee module connected to the robot, using the XCTU program.
Figure 5.18 The Node Identifier configuration using the XCTU program.
The other parameters were not changed. The default values were used to configure our network. By default, the network is configured in transparent mode, to transmit data over the serial interface. In transparent mode the data received through serial is send wireless exactly as it was received, the XBee modules acting as a serial line replacement.
To test the communication between the robot and the off-field computer, a remote controlling application was implemented on the off-field computer.
The application sends command messages, to the robot, and interpret the state messages received from the robot.
In figure 5.19. is shown the data packet sent by the off-field computer to the robot.
Figure 5.19. Data packet sent by the off-field computer to the robot
The first 8 bits sent from the off-field computer to the robot represents the Robot ID. If the Robot ID not corresponds to our robot, the message is not taken into consideration.
The next 8 bits from the data packet represents the desired moving direction of the robot. The desired robot velocity is represented by the next 16 bits from the data packet. The bits value sets the robot velocity value.
The desired rotating direction of the robot is represented by the next 8 bits from the data packet and the desired angular velocity of the robot is represented by the next 16 bits from the data packet sent by the off-field computer.
The next 48 bits from the data packet sent by the off-field computer are for dribbling and kicking the ball. For the dribble command are used 8 bits. Depends on the bits value, the robot will start or stop to dribble the ball. The dribbler speed is represented by the next 16 bits. The next 8 bits represent the kick command. Based on the bits value, the robot will kick or not, the ball. The kicking force is represented by the next 16 bits.
A debug request is sent in the last 8 bits from the data packet. Based on this bits value, the robot will send to the off-field computer, the system state: the moving direction, the robot measured speed and the measured angular velocity, the rotating direction and the measured angular velocity, the dribbler status and the dribbling speed, the kicker status and the kick power.
The data packet sent by the robot to the off-field computer is similar to the data packet sent by the off-field computer to the robot. The only difference is that the robot is not sending a debug request to the off-field computer.
In figure 5.18. is shown the data packet sent by the robot to the off-field computer.
Figure 5.18. The data packet sent by the robot to the off-field computer
6. Conclusions
References
Appendix 1: RoboCup Small Soccer League rules summary
Appendix 2: Robot code
For Division A, the field of play will have a length of 12000mm and a width of 9000mm, and for Division B will have a length of 9000mm and a width of 6000mm. The exact field dimensions and the field markings may vary with 10% in each linear dimension. [Robocup rules]
The dimensions of the goals, and special field areas are different for each division and are specified in the rules book. In figure 1.1 are shown the dimensions of the field, goals, and special field areas for Division A.
Figure 1.1: The field dimensions for Division A [Robocup rules]
The maximum dimensions of the robot are shown in the Figure 1.2.
Figure 1. The maximum robot dimensions [Robocup, rules]
Channels, Zigbee
http://cms.digi.com/resources/documentation/digidocs/90001537/references/r_channels_zigbee.htm
Channel detail
802.15.4 and Zigbee break the 2.4Ghz band into 16 channels as shown below.
Things to note:
References:
[Oxford, 1]https://en.oxforddictionaries.com/definition/robotics
[Oxford, 2012] https://en.oxforddictionaries.com/definition/robot
[Wikipedia, 1] https://en.wikipedia.org/wiki/Robotics
[Wikipedia, 2] https://en.wikipedia.org/wiki/RoboCup
[Robocup, 1] http://www.robocup.org/leagues/7
[Robocup rules] 2018
[Wiki, SSL] http://wiki.robocup.org/Small_Size_League
[robocup.mi.fu] http://robocup.mi.fu-berlin.de/buch/omnidrive.pdf
[collectionscanada] www.collectionscanada.gc.ca/obj/thesescanada/vol1/OOSHDU/TC-OOSHDU-29.pdf
[ftp.inf] ftp.inf.fu-berlin.de/pub/Rojas/omniwheel/shortomni.pdf
[activerob] https://www.active-robots.com/60mm-double-aluminium-omni-wheel.html
[vexrob] https://www.vexrobotics.com/mecanum-wheels.html
[Wikipedia pid] https://en.wikipedia.org/wiki/PID_controller
[wiki impulse] https://en.wikipedia.org/wiki/Impulse_(physics)
wheel_control_theory] http://www.robotplatform.com/knowledge/Classification_of_Robots/wheel_control_theory.html
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: “LUCIAN BLAGA” UNIVERSITY OF SIBIU ENGINEERING FACULTY DEPARTMENT OF COMPUTER SCIENCE, ELECTRICAL AND ELECTRONICS ENGINEERING DISSERTATION SCIENTIFIC… [308927] (ID: 308927)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.