1
TECHNICAL DOCUMANTATION PAPER
JUNIOR SOCCER B ROBOTS
Parham Rahimi, Arya Hamzehnava, Ali Hashemi, Ali Bahmanyar
Allameh Helli Electronics Lab 2016-2018
Allameh Halli High School, Ghaffari St. Tehran, Iran
Figure 1- Final Robots
ABSTRACT
This paper outlines the procedure and findings of ATLAS Robotics team during the
process of designing autonomous soccer-playing robots for participation in RoboCup1
competitions. First, the approach of the team in various technical sections in a junior soccer B
robot is explained. Later, the specific innovations and contributions to RoboCup, and in turn
to Robotics, are highlighted. Finally, future opportunities for further research are stated. It is
worth mentioning that the core purpose of the team members was to practically combine
electronics, programming, mechanics, teamwork, analysis and creativity in the light of
grasping a better understanding of influential fields of Robotics and Artificial Intelligence. The
results are stable robots with great processing power capable of demonstrating team tactics.
Keywords: Junior Soccer B Robot – Practical Knowledge – Robotics – Artificial Intelligence –
Great Processing Power
1 www.robocup.org
2
1. INTRODUCTION The participant robots in RoboCup Junior Soccer should have the ability to play a
modified version of soccer completely autonomously. The robots also should follow certain
criteria concerning weight, size, voltage and many other aspects (the full set of regulations
are available online2.) There are two sub-leagues within junior soccer called lightweight
and open-weight. The last generation of ATLAS robots follow the open-weight guidelines.
Open weight robots must also utilize Computer Vision to detect the ball by color. The
standard mode of competition is between two individual teams each operating two robots.
There is also another type of match between 4-5 individual teams in either of the two bigger
teams called super teams. The winner scores the highest number of goals. In the following,
various sections of ATLAS robots have been discussed.
2. LOCOMOTION 2.1. MECHANICS
2.1.1. BODY
The body of the robot is comprised of two main floors (boards.) The top
floor contains only electronics and is responsible for main processing, while the
bottom floor encompasses motors and part of the shooting system aside some
embedded electronics. Both floors are PCB3s made out of 1.6 mm thick fiber
glass
The locomotion system consists of wheels and motors. The motors are
screwed to PCB fiberglass connectors which are soldered to the bottom board,
increasing strength and precision while reducing weight.
One of the important factors in a robot’s mobility is its number and
configuration of spinning wheels. In the following various configurations are
compared.
Two wheeled systems: having two parallel wheels these systems cannot
move in more than two directions without rotation and face serious disadvantage.
Three wheeled systems: these systems can freely move in any direction
utilizing all their wheels according to relative vector decomposition alongside six
main directions using only two out of three motors. Their main advantage is
guaranteed contact to the ground on all three wheels
Four wheeled systems: Having eight main direction using two wheels these
systems can also move in any angle quicker than three wheeled system by using
all motors. However, this configuration also increases cost, energy consumption
and, most importantly, weight. ATLAS has addressed these issues by selecting
relatively light motors. Another downside of these systems is the vulnerability to
unbalanced contact of the four wheels to the ground (resulting to contact in only
three wheels,) meaning high accuracy in relative axel height is required. This
problem is addressed by using the mentioned fiberglass connectors for motor
connection.
Another important aspect in motor placement is the relative alignment
angle. We have favored forward velocity to side velocity by implementing 110-70
alignment angles instead of the typical 90-90 alignment, considering the
competition field’s greater length compared to its width. The motor axels have
also been shifted closer to each other in pairs to provide space for the shooting
system and a wide ball catching curve (figure 2.)
2 https://junior.robocup.org/rcj-soccer-open/ 3 Printed Circuit Board
3
Figure 2- motor alignment and the overall design of the bottom floor including motors and wheels (top view)
2.1.2. MOTORS AND WHEELS
One of the signature characteristics of ATLAS robots are their motors. Four
DC4 brushed coreless motors are responsible for movement in all directions. The
motors’ part number is 2224012SR from FAULHABER drive systems. They are
coupled with 9:1 model 22/2 gearboxes and IE216 hall-effect encoders (figures 3
and 4.) [1]
Figure 3- Motor and gearbox dimensions
The rated voltage for these motors is 9V. However, we apply 12V for
increased power. These motors have a typical power of 8.5 watts. The average
current consumption in our application, idle no-load current and max locked-
state current are 700, 50, and 2000mA respectively. Max RPM5 is around
14000, while efficiency tops at 80%. A 16 pulse per cycle rotary encoder is also
included for control purposes. It is worth mentioning that due to limited funds,
4 Direct Current 5 Revolutions Per Minute
4
second-hand motors were employed. Omnidirectional wheels have been used
to allow multi-directional movement (figure 4.)
Figure 4- Motor and Omnidirectional Wheel
2.2. ELECTRONICS The motors require 12V, while the microcontroller employed works at 3.3V
with limited output current. Therefore, four separate DC motor driver IC6s have been
implemented to drive the motors using the input PWM7 signal.
The motors can draw up to 2A max while locked. For further protection and
reliability, L6203 driver IC’s with max 4A current draw rating have been used. All the
required motor drive components and the microcontroller responsible for motor spin
control have been situated in an easily replaceable module board (figure 5.) The
utilized microcontroller is from STM32F1 family with STM32F103RBT6 part number.
Figure 5- Top view of the driver board with its respective PCB sketch
2.3. PROGRAMMING Using trigonometric functions and vector decomposition, the overall input angle
and velocity is translated into separate voltage values for each motor with a function
in the code. The generated values are then merged with the orientation correction
values (to correct unwanted z-axis rotation due to imperfections and impact; later
discussed in 4.ORIENTATION AND NAVIGATION.) A gradual transition filtering has
been applied at the final stage to prevent the robot from losing traction and sliding due
to sudden change of motor direction and voltage. An effort was made to include
closed-loop PID control for the rate of rotation using rotary encoders but proved
impractical due to limitations explained later in 10.2.MOTOR AND MOTION
CONTROL)
3. BALL DETECTION 3.1. SENSORS
The two cameras of Pixy CMUcam 5 (640*400@50fps) and Raspberry Pi Cam
v2.3 (1280*720@60fps) have been tested for computer vision purposes on ATLAS
6 Integrated Circuit 7 Pulse Width Modulation
5
robots. RPI Cam 2 and pixy have vertical and horizontal fields of view of 48.8, 62.2
and 48.8, 75 degrees respectively. Though functional, at the end Pixy replaced RPI
Cam as explained in 10.3.Computer Vision. Use of an optical system for complete
panoramic view is ideal to avoid time consuming camera rotation and scanning to
locate the ball. One such system is the use of a convex mirror situated at the top of
an up-facing camera. The team’s initial Idea was the use of a spherical mirror
accordingly. However, extensive research was carried and alternative designs and
limitations are addressed in 9.2.MIRROR AND OPTICS and 10.3. COMPUTER
VISION. Despite the efforts to reach better alternatives, the final mirrors used were
polished steel semi-spheres and mirror vinyl plates heated and formed against the
said steel spheres (figure 6.)
Figure 6- Polished Steel Sphere
3.2. PROGRAMMING 3.2.1. Raspberry Pi
Raspberry Pi Cam 2.3 with Raspberry Pi 3 were used. The main target is
to distinguish certain orange, blue, and yellow targets to locate the ball and the
goals respectively. Therefore, the recorded Image is processed into valuable
information in real-time with OpenCV library using Python programming
language. Initially a raw RGB8 array of the image is converted into an HSV 9format
array. It is convenient to modify few HSV search boundaries rather than RGB
values which will need many complex patterned boundaries to cope with
tolerances in lighting and color. The changes in lighting are simply covered by a
single boundary of saturation and value (brightness) in comparison.
After finding the pixels lying within the boundaries, a binary image is
formed. Noise is reduced using morphological filters. Finally, after detecting the
borders and morphing the clusters into individual objects, the center of the largest
object is determined as the coordinates of the ball. Distance can be calculated by
a variety of methods including block pixel area. It is worth mentioning that the
panoramic circular images can be converted to rectangular images using remap
functions to improve the ease of further geometric calculations.
8 Red Green Blue; each pixel is defined by a combination of the values of these main colors 9 Hue Saturation Value; a more humanly comprehensible representation of colors
6
3.2.2. Pixy CMUcam 5
Pixy is a commercial module with onboard camera that simplifies the
process of color-based object detection and simply outputs the respective
coordinates and pixel areas of the detected objects. As a result, after receiving
the results via UART10 serial protocol, the angle of the ball relative to the robot
can be easily calculated by taking the arctangent of the coordinates of the ball
relative to the mirror center. Details about accurate distance measurement are
given further at 9.3.BALL DISTANCE PLOYNOMIAL REGRESSION.
4. ORIENTATION AND NAVIGATION 4.1. SENSORS
Orientation control is absolutely vital to correctly face the opponent goal, block
the incoming attacks, and be able to move in a straight line. The imperfection of the
motors relative to each other, impacts and uneven wheel friction contribute to the
immediate diversion of the robot if left unsupervised. A sensory device is needed to
measure the robot’s relative orientation angle.
With the availability of computer vision, the opposite goals are identified with
their signature colors and thus a relative orientation angle is obtained. However, the
sample rate is too low and the data is too inaccurate to allow proper rotational error
control.
Traditionally compass modules have been used to give an understanding of
orientation to the robot, however they are extremely vulnerable to metallic objects and
electromagnetic interference alongside having a relatively low sampling rate.
Consequently, ATLAS uses the GY-25 AHRS11 module which relies on gyroscope
data that is more accurate and has a higher sample rate. The data is received via
UART.
Navigation and relative coordinates of the robot are also significant to correctly
position the robot in strategic locations. ATLAS operates three SRF-02 ultrasonic
rangefinders using I2C12 protocol to find coordinates in the field.
4.2. PROGRAMMING Normally, the robot is required to keep its orientation directly facing the
opponent goal (0 degrees.) Based on the desired correction angle, a linear PID13
control has been implemented. Due to the application’s relative instability (the
possibility of the robots remaining tilted for many seconds during direct contact with
opponent robots and developing a huge I value) the Integration coefficient has been
omitted. The resulted rotational value is then added equally to all the motors in the
final stage. The resulting PD control quickly and accurately corrects any errors.
Upon the need for navigating the robot to requested coordinates, the distance
and angle required for displacement is calculated. Then, by using a linear fuzzy control
depending on the remaining distance, the motors are commanded towards that
direction.
10 Universal Asynchronous Receiver/Transmitter 11 Attitude and Heading Reference System 12 A serial communication protocol 13 A linear control method based on the sum of Proportionate, Derivative and Integrative values of error
7
5. OUTLINE DTECTION 5.1. SENSORS
Crossing the outline completely requires the individual robot to be removed from
the game for a limited time frame. Thus, it is extremely important to effectively detect
and avoid outlines. The bottom board contains the line detection system and its
responsible 72 MHz microcontroller (STM32F103RBT6.) 35 phototransistors and 70
white LEDs are spread over the four main axes of the robot. The field’s color is green
while the outlines are white. The difference in the intensity of light reflected from green
and white sections allows the microcontroller to detect outlines based on the changes
in input voltage from phototransistors. There is higher concentration in the array of
sensors in forward and backward directions given the robot’s greater velocity in these
directions requiring more consistent data (figure 7.)
Figure 7- Sensor Array Configuration
5.2. PROGRAMMING Merging the cluster of received out indication data and their location, the
direction and depth of crossing is determined. If less than half of the robot is out, then
the robot actively moves in the opposite direction until no more out indication remains.
If more than half of the robot has crossed the line, the robot locks on the last exiting
direction calculated before passing 50% until the robot completely exits the outer
perimeter. If the robot is near the corners based on coordination data, the priority exit
direction is 45 degrees to counter the possibility of a reaction lag if the robot detects
one side of the corner prior to the other one.
6. FORWARD ROBOT The main objective of the forward is to position itself strategically before detecting
the ball, chase the ball upon detection, and to kick or direct the ball to the enemy goal after
catching it.
6.1. PROGRAMMING The most significant aspect of forward code is to quickly catch the ball in any
direction. One simple approach is to simply rotate towards the ball and move forward
until reaching it. Aside from its simplicity this approach has no advantages, needing
extra time to rotate towards the enemy goal and kick while having a vulnerable stance
against opponent robots with the possibility of losing the ball. An alternate approach
is to remain straight while chasing the ball in a forward-direction-emphasizing curve
and starting to rotate behind the ball towards the opponent goal in close proximity.
8
This method allows effective blocking in case of the opponent reaching the ball first
and requires less time for effective shoots.
A traditional approach of creating such curves is to shift the received ball angle
by constant values for different boundaries and moving in the resultant angle. Better
results are achieved by extending the number of boundaries. However, the resulted
curve may still prove inefficient especially in long distances. ATLAS actively adjusts
its curve by proportionately changing the shift in movement angle based on the
calculated ball distance. The more consistent linear control reduces catch time in
longer distances.
The opponent goal is detected by its color code and the robot rotates behind
the ball in close proximity with the ball being the center of rotation. This change in
orientation slightly before catching the ball allows for quick shoots towards the
unguarded portions of the opponent goal.
6.2. SHOOT (KICK) Shoots add a strategic aspect to the game as the robots are generally not able
to consider relative ball velocity, opening opportunity for scoring more goals.
Capitalizing on this possibility, ATLAS uses a solenoid electromagnet to kick the ball.
6.2.1. ELECTRONICS
The 12v from battery is not nearly enough to accelerate the ball properly. A
LX6009 commercial step-up module has been used to boost the voltage up to
45v. A 4700 microfarad capacitor has been included to cope with the extreme
abrupt current draw of the coil upon initial connection. The shooting circuit has
been completely isolated form the main circuit by a relay and a separate battery
to prevent voltage spike damage.
6.2.2. MECHANICS
Due to better consistency a solenoid has been used instead of alternate
pressure-based pneumatic systems. The solenoid has a kicker on its tip with
extended surface area to enable kicking the ball better.
6.3. DRIBBLER Better ball ownership is a significant aspect of the game. One of the ways to
reduce chances of losing the ball is the use of a spinning cylinder in front of the robot
to produce a backspin in the ball against the robot, making it harder for the ball to be
pushed away. This device is referred to as “dribbler” among RoboCup participants.
ATLAS tested two main mechanisms for a dribbler device:
1. Using the spinning surface of a typical brushless motor covered with gripping
material
2. A brushed motor coupled directly to a cylinder covered with gripping material.
The brushless motor provided great results in terms of spinning speed and ease
regarding to mechanical work. However, the demanding power consumption
combined with risky low-torque operation under heavy load, rendered this method
impractical. On the other hand, the brushed motor, albeit resulting in lower spinning
speed, would exert reasonable torque while locked and produce no harmful voltage
spikes in the circuit.
One other challenge in designing the dibbler is to direct the ball to the center so
that it can be accurately kicked. Two cones at the sides of the cylinder facilitate this
need. The covering material that contacts the ball is also important. It has to provide
both friction and a smooth surface. The top tested material was a combination of wire
heat shrinks and an elastic tube used in sports equipment.
9
A dribbler contains other tactical challenges as well. The use of a dribbler has
to be tested and configured through many tests. For example, poor control of the
dribbler resulting to the loss of the spinning ball near friendly goal may lead to an easy
score for the opponent by rolling into goal. These challenges combined with ATLAS’s
limited time and budget lead to the decision of giving the least priority to development
of a dribbler. As a result, the untested unstable final design was not included in the
robots that went to matches.
7. GOALIE ROBOT The primary duty of the goalie is to position itself near the friendly goal and effectively
defend incoming attacks. The kicker should not be utilized as it may lead to the ball slipping
out in close contact while pushing the opponent robots and rolling into the friendly goal.
7.1. PROGRAMMING Goalie ball chasing is different compared to forward ball chasing in its emphasis
on side movement. The goalie needs to accurately center itself relative to the ball
while keeping its distance first (so that appropriate quick response can be made in
case of a shoot or a charge.) After being centered, the robot should move forward but
in lower speed compared to the forward to open a window for reaction. Usually this
process is done using various “if” statements for different ball angle boundaries. An
alternate method of linear PD control movement based on horizontal distance of the
ball was tested. This method proved more sophisticated and quicker especially in
robots with a great range of velocity. However, the noisy data of ball distance
subjected to the slightest changes in lighting combined with the robot’s relatively low
side velocity didn’t useful utilization.
Auto-placement in front of the goal is done using the navigation functions
discussed in 4.ORIENTATION AND NAVIGATION.
8. COMMUNICATION BETWEEN ROBOTS ATLAS goalie and forward robots are identical in terms of hardware. This brings the
opportunity of tactical cooperation and role switching between them.
8.1. ELECTRONICS Two HC-05 Bluetooth modules carry out transmission of data between ATLAS
robots. These modules were chosen due to their reliability, low cost, and ease of use
compared to other wireless communication modules. HC-05 modules are connected
via UART to the main controller. Using the two-way wireless port created the robots
share coordinates, ball location, and ball ownership data.
8.2. PROGRAMMING The robots exhibit team tactics in a number of ways:
1. By sharing the relative ball location, a robot without direct sight of the
ball can chase the ball based on data from the other robot.
2. One of the classic problems in robots without communication is the
possibility of both forward and goalie robots chasing the ball and preventing each
other from reaching the ball crashing midway. Sharing ball ownership and location
data a closer or ball owning robot can signal the other to guard the goal regardless
of its original role (role swapping.)
3. In case of a damaged robot not being removed from the field, the
remaining robot can take the more defensive role of goalie.
9. INNOVATIONS AND CHALLENGES 9.1. ELECTRONICS
9.1.1. STM32ARM®
10
In 2014, ST announced the release of free STM32Cube software tool with
graphical configurator and C code generator. This was a huge milestone for
electronics enthusiasts as previously harnessing the capabilities of ARM®
microprocessors required extensive knowledge and effort involving manual
configuration of the peripherals with assembly code knowledge after hours of
digging into technical datasheets. Many junior researchers would use simpler
microcontroller families (namely the ATmega series.) However STM32 ARM
families were greatly superior both in terms of clock speed (168MHz in cortex F4
compared to 32 MHz in ATmega) and peripherals (16 timers vs 4 timers for
instance.) These newly available hardware was also more reliable and benefitted
from a 32bit architecture compared to usual 8 bit designs.
The advantages of STM32 ARM are not limited to hardware. The IDE that
ATLAS used, Keil µVision, greatly increased efficiency by providing a convenient
debugging feature and many other developer-friendly features. These options are
simply absent in alternate IDEs available for ATMEL and Arduino. [2][3]
Naturally with every new platform comes an inert uncertainty and risk.
ATLAS started experimenting with STM32Cube in late 2016, just two years after
its release. Several bugs and sophisticated challenges were met in the process
of adaptation over 2 years, some later elaborated in 10.1.COMPLETE LOGIC
ISOLATION
9.1.2. MCU14
ATLAS required the most compact and flexible design possible to open
room for versatility and deep development. In contrast, Most of the available
STM32 ARM commercial development boards were either too large or too under-
equipped aside being expensive. It was decided to design custom boards in a
manner that met the overall circuit requirements.
With dimensions as small as 3*4cm, the main MCU board was sketched,
housing only the microcontroller and supporting operation circuit along with an
on-board LED. The same board was compatible for both STM32F405RGT6
(168MHz) and STM32F103RBT6 (72MHz) with minimal adjustment. The
resultant board greatly reduced occupied space and price (figure 8.)
Figure 8- MCU board 3d simulation and PCB sketch
14 Main Control Unit
11
9.2. MIRROR AND OPTICS Optics is the outermost part of the computer vision section in the robot that can
be improved. Various efforts were made to improve the reflectance and nature of the
mirrors itself. Because the camera is faced upwards towards the convex mirror, a big
section of the image is occupied by the robot’s own reflection. An alternate idea was
to design a mirror that only projects the image outside the robot boundaries instead.
Such a design was achieved by cropping a section of a parabola and rotating it around
a vertical axis. The resultant conical-parabolic mirror was simulated and provided
improved results in a 3d software (figures 9 and 10.)
The initial plan was to construct this mirror by stretching a thin heated vinyl
mirror sheet over a 3d printed base covered by adhesive material to cover the gaps
between 3d printed layers. Unfortunately, the heat from the vinyl sheet quickly
transferred to the 3d printed base and caused distortions. However, ATLAS has
shared its findings with the RoboCup community in hope of advancements in the
optics used. Alternatively, ATLAS has improved image quality by shaping the
mentioned vinyl sheet against the steel spheres previously used.
Figure 9- Conical-Parabolic Mirror 3d Model
Figure 10- Conical-parabolic mirror simulation in 3d software with the ball at a distance of 1m
9.3. BALL DISTANCE PLOYNOMIAL REGRESSION Accurate estimation of ball distance can prove useful in providing more accurate
data for more sophisticated control. There are various methods to approximate
distance based on a panoramic image based on pixel area, pixel distance and other
comparative approaches. ATLAS inferred that ball pixel distance offers the greatest
data range among these methods and can provide more accurate approximations.
A modest approach to these approximations is using a polynomial derived from
plotted data in software. However, that proves to be a challenge as the detected ball
center coordinates are extremely sensitive to lighting; an hour of change in sunlight
angle in a room with curtains is enough to render the polynomial obsolete.
12
ATLAS attempted to counter this challenge by using automated polynomial
regression using least square fitting method15. This way, the operating user would
place the ball in various known distances in setup mode and allow the robot to collect
data and deduce the polynomial itself. This innovative approach allowed for relatively
accurate ball distance calculation. Despite the effective process, the data accuracy
was still low in long distances with one pixel being equal to 10-20cm change of
distance.
9.4. OUT DETECTION WITH PHOTOTRANSISTERS The robot’s max forward velocity is around 1m/s. The width of the outline is
around 2cm and a single sensor is designated to support each 2cm. As a result a
single sensor should have around 20ms to indicate out at top speed. The rise time of
a LDR is around 50ms which prompts detection in lower thresholds and higher
sensitivity. Despite greater vulnerability to noise LDRs also provide inconsistent data
causing less accurate response. At maximum speed, only 10 sensors would detect
outline out of 35 and the random placement of the 10 didn’t allow the robot to
effectively react.
Through the use of phototransistors, the ample rate improved drastically with
rise times in the order of microseconds. In fact, so quick that averaging techniques
were used to collect consistent peaks instead of the gradual change recorded by the
sensors.
9.5. SOLDER MECHANICAL CONNECTIONS As stated in 2.1.1.BODY a great challenge of four-wheeled omnidirectional
systems is to ensure equal contact with the ground in all wheels. To achieve accurate
relative placement of the motors in an inexpensive manner, ATLAS has capitalized on
the available CNC milled PCBs. PCB sections have been designed like puzzles to
perpendicularly connect to each other, forming a precise soldered connector for the
motors. The same approach has been implemented to attach ultrasonic range finder
sensors (figure 11.)
Figure 11- PCB mechanical connectors
9.6. COMPUTER VISION PIXYcam was preferred to Raspberry Pi for a number of reasons: even after
efforts for parallel processing and quick scanning, RPI could barely meet 40fps due
to its higher resolution. RPI drew 2A with greater peaks while Pixy could function at
15 https://neutrium.net/mathematics/least-squares-fitting-of-a-polynomial
13
FUTURE DEVELOPMENT OPPORTUNITIES
COMPLETE LOGIC ISOLATION
MOTOR AND MOTION CONTROL
COMPUTER VISION
0.5A without problems. Pixy was a simple single board while RPI required a lot of
provisioning.
ATLAS believes further development as addressed in 10.3.COMPUTER
VISION is required for better vision results.
10. 10.1.
Though durable, STM32 ARM microcontrollers faced some power supply
stability issues. Continuous ripple and spikes in overall circuit voltage levels dealt
damage. As a result, ATLAS resorted to simple means to minimize noise such as the
usage of zener diodes to bypass high voltage spikes.
We believe the alternate final solution to these problems should be the complete
isolation of logic sections through opto-isolator and separate voltage supplies.
Separate voltage supplies can be achieved either through separate batteries or by
implementing DC/DC converters with such capability.
10.2. The motors present in ATLAS have built-in 16 pulse per cycle rotary encoders.
Having that in mind, PID control over rotation speed was implemented. However, due
to the encoders’ small number of pulses per cycle, the resulted control was not
accurate and stable enough with many overshoots. As a result, the motors were
controlled without feedback in an open-loop scheme instead. The motors react linearly
to changes in applied voltage based on their datasheet. Therefore, the final control
over the motors was appropriate once orientation correction was implemented.
It would be a great enhancement if accurate PID control could be achieved with
more accurate encoders as it offers curtain advantages. With an accurate motor
speed control, the robot can behave better in situations when direction changes
suddenly. For instance, when the robot approaches the ball in full speed and needs
to suddenly turn behind the ball or when it detects out and needs to quickly move in
the opposite direction without causing the robot to tilt due to the stress caused.
Other uses of precise motor control can be in tactics, especially if merged with
acceleration data passed through Kalman filter. If the commanded speed is high while
the wheels are spinning quicker than usual with a low acceleration observed, that
could mean the robot is engaged in a head-on with an opponent robot trying to push
the ball. An appropriate response could be slightly rotating and moving to one side to
direct the ball out to an advantageous position.
Other uses could be in calculating a relative velocity merging the data of
accelerometers, encoders and ultrasonic range finders which could assist in outline
evasion.
Advanced control like the above are the key to pushing RoboCup to a higher
level. Another possible area of improvement is in ball chasing with possibility of
considering relative ball velocity and distance if more accurate vision data are
available.
10.3. The first noticeable improvement that can be done is in optics. Perhaps a
reliable yet affordable method can be find to build mirrors like the mirror proposed in
9.2.MIRROR AND OPTICS. Maybe better mirrors can be designed that optically zoom
on farther distances by emphasizing their curve near their circumference.
The 640*400 resolution in PIXY is not enough to detect the ball properly in long
distances and not nearly sufficient to use landmarks and detect friendly or opponent
robots.
14
SOURCES
ACKNOWLEDGEMENT
Increase in resolution can be achieved by using SBCs and external cameras.
However, graphical processors better be utilized in order to provide better framerate
for smoother movements. Aside these, there are many other advantages in having an
open-source vision code instead of a closed source product that most teams use.
11. Allameh Helli Electronics Laboratory and Allameh Helli High School for their support
throughout the project.
Boorsika online store for sponsoring the team.
12.
1. www.faulhaber.com
2. www.st.com
3. www.keil.com
Figure 12- Robots in IranOpen 2018 Competitions