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