Documente Academic
Documente Profesional
Documente Cultură
Team Members:
Nicholas Jones 1068165
Michael Hill 1078262
Michael Shanahan 1078748
Executive Summary
This project final report documents the progress made in the development of a fully
automated team of three robotic soccer players designed for entry in the 2005 RoboCup
Small-Size league. The report summarises the research conducted, the design steps taken
and decisions made in developing and implementing the team of robots.
The project began with conducting research into the RoboCup competition to understand
the facets of the game, the requirements of the robotic players, along with the constraints
and specifications of the project. Additional investigation was also conducted into
designs used by other teams, to gain knowledge regarding which solutions and
components worked effectively. A database of this research was then established and
used as a reference when formulating a design solution.
The project was broken up into the following subsystems for concurrent development:
mechanical, vision, host software and communications. A design was then formulated
and the developed as detailed in this report.
It was found that the project budget was the most dominating factor in all design
decisions, often immediately constricting the number of options. As a result, the final
design was more so governed by the budget than what was deemed a successful solution.
The report recommends that the target budget be increased for future RoboCup
endeavours as designing and constructing a robot team of a competitive standard is not
viable with the current limited funding.
The majority of the project goals were achieved. A cost effective robot that met the entry
criteria for the RoboCup Small Size League was developed. A successful vision system
was implemented that allowed for coordination between the robots and game playing
strategies. Finally, a solid foundation for future teams to build upon was established.
Acknowledgements
The 2005 Soccer Robot Design Team would like to acknowledge and thank the
colleagues and organisations whose support and help have made this project possible. Dr.
Frank Wrnle (project supervisor), Silvio de Ieso and Derek Franklin from the schools
electronics workshop, Bill, Richard and Steve from the schools mechanical workshop,
Yasutake Takahashi & Taiki Mizuki from the Osaka University Team Osa-Yans, and
Wytec Evaluation Boards. Without the assistance and expertise of these individuals and
organisations this project could not have been completed with the level of success it has.
Table of Contents
EXECUTIVE SUMMARY ...........................................................................................................................1
ACKNOWLEDGEMENTS ..........................................................................................................................2
1
INTRODUCTION................................................................................................................................6
1.1
ROBOCUP ......................................................................................................................................6
1.2
1.2.1
1.2.2
1.2.3
1.2.4
1.3
DESIGN SPECIFICATIONS................................................................................................................8
1.4
TEAM ORGANISATION....................................................................................................................9
LITERATURE REVIEW..................................................................................................................10
2.1
INTRODUCTION............................................................................................................................10
2.2
2.2.1
2.2.1.1
2.2.1.2
2.2.1.3
2.2.2
2.2.2.2
2.2.2.3
2.2.2.4
2.2.2.5
Dribbler mechanisms.............................................................................................................17
2.2.3.1
Fixed bracket.............................................................................................................................. 17
2.2.3.2
Rotating cylinder........................................................................................................................ 18
2.2.4
2.2.2.1
2.2.3
2.3
2.2.4.1
2.2.4.2
INTRODUCTION............................................................................................................................21
3.2
3.2.1
3.2.2
Robot wheels..........................................................................................................................26
3.3
3.4
3.5
3.6
VISION SYSTEM..............................................................................................................................34
4.1
INTRODUCTION............................................................................................................................34
4.2
4.3
METHODOLOGY ..........................................................................................................................35
4.3.1
4.3.2
4.3.3
Colour definition....................................................................................................................35
4.3.4
4.3.5
4.4
5
CONTROL SOFTWARE..................................................................................................................40
5.1
INTRODUCTION............................................................................................................................40
5.2
5.3
5.3.1
5.3.2
5.3.2.1
5.3.2.2
5.4
5.5
INTRODUCTION............................................................................................................................50
6.2
6.3
6.4
ROBOT PROGRAMMING................................................................................................................52
6.4.1
6.4.2
Receiver side..........................................................................................................................53
6.5
6.6
CONCLUSION ..................................................................................................................................59
10
REFERENCES..................................................................................................................................63
10.1
10.2
APPENDICES .............................................................................................................................................65
APPENDIX A ROBOCUP RULES & REGULATIONS......................................................................66
APPENDIX B DESIGN CALCULATIONS...........................................................................................93
APPENDIX B.1 MOTOR CALCULATIONS ...................................................................................................93
APPENDIX B.2 KICKER DESIGN CALCULATIONS ......................................................................................95
APPENDIX C
1 Introduction
1.1 RoboCup
RoboCup(1) is a joint international venture aimed at promoting studies in the burgeoning
fields of artificial intelligence, robotics and strategic programming. It uses various soccer
leagues involving fully autonomous robots to cultivate interest in these fields, allowing
for advancements in associated areas that may one day lead to more significant
applications.
The intriguing and competitive environment created by RoboCup aims to bring together
skills such as autonomous design, design for function, artificial intelligence, multi-agent
coordination, real time communications, visioning systems, kinematics, game play
strategy and software programming. This encourages participants to further their
knowledge and improve skills in the above components of their chosen field of study.
RoboCup requires integrating the technologies mentioned above to produce independent
mobile robots with the ability to perform all necessary tasks involved with playing a
game of soccer. This entails fundamental tasks such as kicking, ball-retrieval, dribbling
and shot-aiming, as well as more complex tasks such as tracking objects on the field, and
implementing game-play strategies including the anticipation of opponent moves.
The robot design documented in this report is intended to meet the requirements for entry
in the RoboCup Small Size League (F180)(2), consequently a majority of the design
decisions were made in order to comply with RoboCup Small Size League design
constraints. The small-size league pits two teams of five robots against each other, each
robot required to fit within a cylinder of diameter 180 mm and height 150 mm. The
RoboCup rules aim to emulate those of the FIFA soccer organisation with a few
modifications for robotic players. The rules and regulations for the RoboCup F180 league
can be found in Appendix A.
Project definition
The aim of the 2005 level IV soccer robots design project was to design and build a team
of three small autonomous robots capable of playing a game of soccer using a golf ball.
The design of these robots was restricted to the conditions of entry of the RoboCup F180
small size league. These fundamental requirements lead to the following project
objectives.
1.2.2
Project objectives
Researching and developing an ideal robotic design suitable for entry in the
RoboCup small-size league and manufacturing a team of three such robots.
Providing a solid foundation for future project teams to build upon and achieve
success.
Gaining experience in all facets of robotics and promoting the advantages of such
aspects to the public through the popular medium of robotic soccer.
1.2.3
Project scope
A team must have five robots in order to compete in RoboCup. The scope of this project
was limited to the production and effective operation of three robots, due to the
constraints of time, budget and human resources. This project was thus not intended to
produce a full team fit for entry into the RoboCup tournament, but was merely aimed at
providing a partial team of functioning robots to be further developed by future projects.
7
1.2.4
Project significance
The significance of the Soccer Robots design project lies mainly in fostering skills and
innovation in students. The project is a complicated challenge which brings together
various systems including a vision system, motion control software, a means of
communication between the robots and the host computer, and the robots themselves,
which must be capable of responding correctly to instructions received. This challenge
requires that problems be addressed in the areas of robotics, electronics, communications
and software programming. These problems can result in innovative solutions which may
one day be developed into notable advances. In addition to this, a team of robots capable
of playing soccer provides entertainment, considered by many to be a worthy endeavour.
The ultimate aim of RoboCup is to, by the year 2050, create a team of robots capable of
defeating a team of humans in a game of soccer. It can be imagined that such an
achievement will involve such advances in autonomous robotics as to be highly
beneficial to many other applications, such as manufacturing machinery, unmanned
exploration or rescue vehicles and defence applications.
The mass of a single robot will be no more than 2.0 kg. This estimate was
obtained by summing the individual masses of all components predicted
necessary.
The robot will operate on a two-wheel differential drive system in order to comply
with the budget constraint.
The robot should be capable of achieving an acceleration of 1.0 ms-2. From this
value the torque required from the motors can be deduced.
8
The robot should be capable of achieving a velocity of 1.0 ms-1. From this value
the required motor speed characteristics can be deduced.
The kicking device will, whilst the robot is stationary, propel the ball with a
maximum speed of 1.0 ms-1.
2 Literature Review
2.1 Introduction
This literature review critically analyses what different teams have used for the primary
components of a soccer robot such as the driver, kicker and dribbler mechanisms and
sensor system.
Following this, it will be determined what can be done to develop a cost-effective robot
design which will bring the University of Adelaide closer to having a team of the current
RoboCup competitive standard.
Drive system
The drive system of a robot allows it to move around the field and therefore, must
provide adequate speed, acceleration and manoeuvrability to play a game of soccer. This
system consists of a configuration of motors and wheels. Two possible drive systems
were considered for this project: an omni-directional drive system and a differential drive
system.
The following drive systems are generally used:
2.2.1.1 Two-wheel differential system
This is a commonly used design, for example with the Carnegie Mellon Universitys
CMRoboDragons 04 Team(7) finishing fourth with this drive system in 2004, see figure
2.1. This design utilises two wheels that are placed side by side. This system is the
simplest and cheapest design to implement. It lacks the manoeuvrability of omnidirectional designs, and thus will be considerably slower than these when changing
directions.
10
11
Compared to the 2-wheel differential design, for a given unit force F provided from each
motor, the 3-wheel omnidirectional systems will have reduced driving forces in the
forward direction as the triangular arrangement results in driving forces from individual
wheels cancelling out to some degree. The effect of this is that the acceleration and
velocity will be slightly lower than that for a differential system with the same driving
force for each motor.
This is illustrated in figure 2.3 which represents the kinematic forces on an omnidirectional system. As can be seen in table 2.1, the total forces that would result in the
forward (Y-ref) direction for both the omnidirectional systems are less than the driving
force of F*2 that would be provided by a two-wheel differential system.
This omni-directional system has been successful for several teams in the past. It is used
by the German FU-Fighters(3), Australian RoboRoos(4) and Cornell Universitys Big
Red(5) teams, the first two of which came first and second in the 2004 RoboCup
competition respectively. Figure 2.4 displays the omni directional drive system employed
by the Australian RoboRoos team.
12
Direction: Y-ref
Direction: X-ref
Force (Wheel 1)
Force (Wheel 2)
Force (Wheel 3)
Total Driving
Force
=F*sin30
=F*sin30
=F*sin90
Force (Wheel 1)
Force (Wheel 2)
Force (Wheel 3)
Total Driving
Force
=F*sin15
=F*sin15
=F*sin90
=F*0.5
=F*0.5
=F*0.5
=F*2.0
=F*0.258
=F*0.258
=F*1.0
=F*1.52
Table 2.1: Net driving force for a 3-wheel omni directional drive system
Figure 2:4: 120-degree Omni-directional drive system used by Australian team RoboRoos
13
Direction: Y-ref
Direction: X-ref
Force (Wheel 1)
Force (Wheel 2)
Force (Wheel 3)
Force (Wheel 4)
Total Driving
Force
=F*sin30
=F*sin30
=F*sin30
=F*sin30
=F*0.707
=F*0.707
=F*0.707
=F*0.707
=F*2.82
Table 2.2: Net driving force for a 4-wheel omni direction drive system
The drawback of this design is that it requires the implementation and cost of a fourth
motor-wheel assembly which makes it a comparatively expensive option. The Lucky Star
Team(6) came third in 2004 using this system, see Figure 2.5.
Figure 2:5: 4-wheel omni directional drive system used by team LuckyStar
14
2.2.2
Kicker mechanisms
The kicker mechanism is the component of the robot that propels the ball in a given
direction. This component can have any number of varying designs, but most involve the
use of a solenoid to propel the ball in some way.
Figure 2:6: Solenoid kicker mechanism designed by 2001 Cornell University team
15
2.2.2.3
The Australian RoboRoos team designed a crossbow kicker mechanism wherein a striker
is retracted using a DC motor, held in place using a rack and pinion couple, storing elastic
energy in a cord. The striker is released using a trigger to disengage the rack and pinion,
hitting the ball. This mechanism has much the same features as the Linear Kicker
Mechanism, but can potentially garner much more power by storing elastic energy in its
cord. Depending upon the design and power of the motor, the system may need a second
or two to wind up. The main problem with this system is that it requires an additional
motor, more power and more space to implement the design. This means that the entire
robot design may have to be based around this kicker mechanism, rather than it being a
functional component of the robot. Figure 2.7 displays the RoboRoos Crossbow design.
16
2.2.3
Dribbler mechanisms
This optional mechanism aims to keep the ball close to the robot with out grabbing it,
which is against RoboCup rules. From this position the robot can then move with the ball,
while maintaining it in the optimal location from which the kicker mechanism can strike
it. Typically there are two variants that are used. One is that of a bracket, the other is a
variation of a rotating cylinder design. Teams may have a catcher mechanism to catch
the ball for the dribbler, but often the definition between the two is indistinct. Most of the
time the catcher mechanism is the dribbler mechanism, or a bracket that many would
define as a dribbler mechanism.
17
2.2.4
Sensory systems
Sensory systems primarily involve the vision system and how it is used to co-ordinate
robot movement. The vision system determines how the host computer keeps track of and
monitors the position of the robots on the field. Since nearly all robot teams are
compelled to use a global based vision system, there are very few variations in vision
system methods used.
18
19
20
3 Mechanical Design
3.1 Introduction
The design of a robotic soccer player presents a number of challenges to be overcome.
Examples of this include how the robot will be driven and how the ball will be propelled
by a kick. In order to gain an insight into possible design solutions, several current
RoboCup entrants designs were examined. From this investigation, a database of
existing solutions was compiled, as outlined in the Literature Review section of this
report. Using this database and with the project budget firmly in mind, solutions to each
of the design issues were decided upon.
Type
Small Stepper Motor, Step 35mm
TRANSWHEEL, (OMNI-LIT)
Cost
$8.00
$17.50
Quantity
9
9
TOTAL
Type
Small Stepper Motor, Step 35mm
Basic Cylinder Shaped Wheel
Cost
$8.00
$2.50
TOTAL
Quantity
6
6
21
Given the target budget of $250.00, it was agreed that an omni-directional drive system
was unaffordable. This was further reinforced by the additional power requirements. For
these reasons, the differential drive system has been selected and the components
discussed herein are intended for use in such a system.
3.2.1
Motor selection
The motors for the differential drive system needed to provide adequate torque for the
desired acceleration of 1 m/s as mentioned in the design specifications. The required
torque was calculated as detailed below.
The driving force required to accelerate the robot can be found from Newtons second
law, expressed in equation 3.1.
F = ma
(3.1)
Where F is the force acting on the robot, m is the mass of the robot and a is the
specified acceleration. Since this force is provided for two wheels, the force required by
each wheel, Fw is given by equation 3.2.
Fw = 0.5(m a)
(3.2)
The torque T required to generate this force depends on the wheel radius r, as follows
in equation 3.3. Substituting equation 3.2 in 3.3 yields equation 3.4.
T = Fw r
(3.3)
T = 0.5(m a r )
(3.4)
To compensate for possible mechanical losses and inevitable errors in estimating design
quantities, a safety factor of 1.5 was used. Therefore, the equation for the design torque,
Td is expressed in equation 3.5.
22
Td = 0.75(m a r )
(3.5)
The design procedure is often an iterative process. Whenever components are added or
changed, the total mass of the robot changes, as does the torque requirement. With all
components as described above, the mass of the individual robots was estimated to be
approximately 1.9 kg. This proved to be a significant over-estimation, as the true mass of
the robots is closer to 1.2 kg.
The decision of what wheel radius should be chosen was influenced by the size of the
motor. The size of the motor defines the minimum distance between the motor shaft and
the underside of the robot. It was desirable that the centre of mass of the robot be as low
as possible, as this improves its performance with regard to manoeuvrability.
Furthermore, small wheels lead to small torque requirements. Therefore, the wheel size
was chosen to provide the minimum necessary clearance between the underside of the
robot and the ground. With this in mind, it was decided that the wheels should have a
radius of 30 mm, giving a clearance of about 5 mm.
With an estimated mass of 1.9 kg, a wheel radius of 30 mm and a specified acceleration
of 1.0 ms-1, the design torque was 430 mNm.
It can be seen from the Literature Review that the majority of successful designs use
expensive DC motors from international suppliers such as the MicroMo Faulhaber 2224
DC Motor. Due to the restrictions on budget and time, Australian suppliers were given
priority in order to avoid costly currency conversion and extra shipping costs and time.
One possible solution was to use some spare motors available at the University of
Adelaide (for example, Thomson ECN H42S254001 Stepper Motors). Other possible
configurations are summarised in table 3.2.
23
Motor
H42S254001
M42SP-5
YM7251
Stepper
High Speed
Torque Motor
MO 0040 DC
Supplier
Thomson ECN
M-GEN
Jaycar
Electronics
Dick Smith
Electronics
Wiltronics
Torque
(g.cm)
1700
795
Voltage (V)
12
12
Mass (g)
150
200
450
12
Unavailable
101.7
69.2
320
12
12
Unavailable
Unavailable
29.7
59.4
The high speed torque motor from Dick Smith Electronics(11) does not generate enough
torque nor does the Wiltronics MO 0040(12) , thud they were eliminated. This left the MGen M42SP-5 and the Jaycar(13) YM2751, both of which satisfy the requirement. Based
on torque generated versus cost per motor the M42SP-5 was chosen.
The M42SP-5, pictured above in Figure 3.1, appears to be the most suitable motor,
satisfying the torque requirements and budget constraints. The rated current drawn by
these motors is listed as 0.4 A, which appears to be typical for this type of motor. As with
all motors, the torque provided by this motor varies with speed. The characteristics for
the M42SP-5 are given in figure 3.2.
24
As can be seen in the figure, when the speed of the motor increases, the torque it provides
decreases. Here, pps stands for pulses per second. Velocity v can be calculated from
the motor steps size in degrees s, the motor speed in pulses per second, p, and the
wheel radius, r, as seen in equation 3.6.
v=
(s p r )
360
(3.6)
Given the motor specifications, it is possible to calculate the robot velocity corresponding
to motor speed (see calculations in Appendix B.1). Table 3.3 displays robot velocity and
acceleration for given pulses per second in the selected motors. This data suggests that
the chosen motor satisfies specifications regarding robot velocity and acceleration.
Driver circuits provided by the University of Adelaide School of Mechanical Engineering
electronics workshop were used to control these motors. These driver circuits each have a
speed and a direction pin for each motor. The direction of a motor is controlled by a
single bit set to either 0 or 1 for positive or negative rotation. The speed is controlled by
the frequency of a square wave.
25
Speed (pps)
Torque (N.m)
Speed (m/s)
Acceleration (m/s^2)
20
0.063
0.08
1.4
40
0.059
0.16
1.31
60
0.056
0.24
1.24
80
0.052
0.31
1.16
100
0.048
0.39
1.07
120
0.044
0.47
0.98
140
0.04
0.55
0.89
160
0.037
0.63
0.82
180
0.033
0.71
0.73
200
0.029
0.79
0.64
220
0.025
0.86
0.56
240
0.021
0.94
0.47
260
0.018
0.4
1.02
280
0.014
0.31
1.1
300
0.01
0.22
1.18
320
0.006
0.13
1.26
340
0.002
0.04
1.34
Table 3.3: Robot velocity and acceleration for given motor pps
3.2.2
Robot wheels
The robot wheels are required to deliver consistent movement with minimal slippage
while not causing any damage to the playing field surface. With the majority of the
current RoboCup competitors entering omni-directional robots with advanced omnidirectional wheels, the literature review did not offer much advice with regard to suitable
differential drive wheels for the robot. Custom wheels were designed for manufacturing
by the University of Adelaide School of Mechanical Engineering workshop. The wheels
are cylindrical in shape with a 60 mm diameter and 3 mm width. They were made from
aluminium.
26
The distance moved by the kicker plate is equal to the stroke distance of the solenoid
multiplied by y/x. Neglecting frictional losses; the force exerted by the plate on a ball in
contact with it is equal to the force of the solenoid stroke multiplied by a factor of x/y.
The design of the solenoid-lever kicker is can be seen above in Figure 4.4.
The value x has been set at 10 mm and the value y at 25 mm. The chosen solenoid, the
Jaycar Electronics SS0901 pictured in figure 3.4, has a stroke length of 6 mm and an
average exerted force of 600 g (approximately 6 N). Calculations for how these values of
x and y were arrived at can be found in Appendix B.2.
28
It was difficult to predict the speed of the ball after being kicked. As development of the
kicker progressed, it became apparent that a more suitable specification for kicking
capability would have been a specified time for which the ball must travel a certain
distance when kicked. The current kicker design does not satisfy specifications generated
at the start of the project. Modifications were considered however. Since the force applied
by a solenoid is proportional to the current flowing through its coil, the performance of
the chosen solenoid can be improved by either applying a larger voltage to it, or by
rewinding the coil with thicker wire. Either method would result in a larger current, and
thus force exerted by the solenoid. This in turn, will result in a larger impulse acting on
the ball, causing it to be propelled faster and further.
Unfortunately there was no time to implement either of these modifications, resulting in a
reasonably low kick distance of about 600 mm.
29
The frame, pictured above in figure 3.5, consists of two flat plates connected by various
modules. These include two wheel modules on the sides of the robot, a kicker module in
the centre of the robot and a simple support strut at the rear. The microcontroller can be
bolted to the top plate. Also attached to the kicker module are two arms designed to trap
the ball during play. The arms are angled towards the centre of the robot so if the ball is
caught at the side of the robot, it will be drawn to its centre where it will rest against the
kicker plate. Space for the battery pack exists between the kicker module and the rear
support. The completed prototype assembly is covered in the summary of this chapter.
The dribbling mechanism was an integral part of the robot design as its ability in keeping
the ball close played an important role in determining how successful the robot was. The
results of the literature review suggest that two main types of dribbling devices exist in
the RoboCup entrants designs: rotating cylinder mechanisms or simple ball slots. Due to
the constraint of the budget it was not feasible to incorporate another motor into the
design, thus the simple ball-catching mechanism described above had to suffice to trap
the ball while a small recess back near the kicker mechanism would keep the ball in place
at the centre of the robot. The motion of the robot is intended to keep the ball close to its
body long enough for it to receive a kicking command. This recess can also be seen in the
frame diagram above.
30
31
32
Part
Roof Plate
Side Plate
Base Plate
Lever Arm
Centre Column
Kicker Plate
Wheel
Motor
Motor Driver
Circuit Board
Power Distribution
Board
Solenoid
Microcontroller
Receiver
Battery
Type
Aluminium
Aluminium
Aluminium
Aluminium
Aluminium
Aluminium
Aluminium
M-GEN M42SP-5 Stepper
Quantity
1
2
1
1
1
1
2
2
Custom
Custom
Jaycar SS0901
Wytec miniDRAGON+
RLP434
Powertech AA Ni-Mh
1
1
1
1
10
33
4 Vision System
4.1 Introduction
The Vision system was responsible for tracking the locations of the robots and the ball. It
provided coordinates defining these locations to the motion control software so that
game-playing strategies could be formulated.
This was achieved by capturing images of the field using a fire-wire camera. Each image
was then processed using an imaging toolbox to identify the ball and robots based upon
the colour ranges of their respective markers. Once these objects were identified, the
program passes the necessary object coordinate information, such as centroids and
orientation, to the motion control software.
34
4.3 Methodology
This section details the process used by the vision system to identify the perimeter of the
field, the position of the goals, and monitor the movements of all robots and the ball
during play.
4.3.1
The camera captures an image when the capImage(1)function is called. Using the
imageProcSilent(1) function, a previously captured image from the camera is
processed. YUV format is used during image capture since it only requires two thirds the
bandwidth for RGB24 format.
4.3.2
Since the positions of the robots and the ball are always changing, they need to be
constantly identified and tracked. In order to achieve this, a colour identification system
was established. The ball itself is uniquely coloured, and each robot has two distinctly
coloured markers; one defining its centroid, the other its orientation. The vision software
can then determine object location and orientation from images by searching for the
specific colour ranges that define these details. The exact colours the vision system can
identify are specified in the colour definition file.
4.3.3
Colour definition
The colour ranges that the vision system must search for are specified in the file
test_colors.txt. This text file contains a table listing the colour attributes associated with
each object listed. The structure is shown below in Figures 4.2 and 4.3:
35
36
4.3.4
Before the vision system can be used, two things must be done to ensure that the
information the vision system returns to the motion control software is accurate.
The coordinates of the field and the goals must be defined. These will remain constant
relative to the camera. Hence they will be pre-determined by the user from an
initialisation image of the field and entered manually. This information is passed to the
motion control software upon activating the vision system for the first time.
37
To track objects successfully using colour detection ranges, the colour ranges must also
be well defined. If the range specified is too wide, unwanted objects or areas may be
interpreted as part of the same object cluster. If the ranges are too narrow then nothing
may be detected. The MATLAB training program trainCamera.m can be used to
calibrate the colour ranges to ensure they are accurate. This takes an image and allows the
user to manually select the exact colour representing a specific object. The colour
characteristics are then returned and the established YUV range can be copied straight to
a colour definition file. Figure 4.3 shows calibration of the vision system via this training
program. By experimenting with manipulating this range, one can obtain even more
accurate results.
4.3.5
Using the previously mentioned methods, the vision system will successively process
images according to the following algorithm:
38
39
5 Control Software
5.1 Introduction
The motion control software, running on the host computer, essentially manages all
robotic movement and action. The software continuously receives ball and robot
coordinates from the vision system and from these, determines the most appropriate
action to be taken by each robot based on the current mode of play. The game is divided
into two basic styles of play depending on whether or not the ball is in possession. Both
these modes of play are primarily concerned with offence. Unfortunately, the project
budget does not allow for the development of an opposing team and as a result a
defensive mode of play will not be taken into consideration. However, this is an area
deemed to be worthwhile investigating in successive projects.
x1d
x2
x2d
x3
x 3d
yb
y1
y1d
y2
y 2d
y3
y 3d
Where xb and yb are the coordinates of the balls centroid, xi and yi are the coordinates of
robot is centroid and xid and yid are the coordinates of robot is orientation marker.
40
Prior to implementing the navigation software, it was first necessary to determine how to
physically instruct a robot to a set of specified coordinates. This involves mapping
distance to travel and angle to turn into motor pulses. Firstly, having received a robots
centroid and orientation marker coordinates and given a set of destination coordinates
(x, y), vectors describing the robots orientation (Vd) and the shortest path between it and
the destination point (Vs) can be established as follows:
x x1
Vs =
y y1
x1d x1
Vd =
y1d y1
These vectors originate from the centroid of the robot and point towards the orientation
marker and destination point respectively. The distance between the robot and the
destination point is then the norm of vector Vs. The angle the robot must turn in order to
face the destination point is simply the angle between these two vectors and can be found
using equation 5.3.1.
cos =
Vd Vs
Vd Vs
(5.3.1)
In order to map these measures of distance and angle to motor instructions, a number of
known constants need to be established. Denote d the distance to the destination, r the
radius of the wheels, w the length from the centroid of the robot to the wheel and
the angular speed of the wheel at a given pulse, the time the motors need to be pulsed is
given by equation 5.3.2.
T=
d
r
41
(5.3.2)
To enable the robot to turn the angle given by equation 5.3.1, the distance of the arc
length, l, subtended by that angle is found via equation 5.3.3. Here, the radius of the
arc-length is the distance from the centroid of the robot to its wheel since the wheels will
be pulsed in opposite directions to turn the robot. Once the arc-length is found, the
duration of the pulses is determined via equation 5.3.4.
l = w
T=
l
r
(5.3.3)
(5.3.4)
Once these times are calculated, the MATLAB command pause(T) was used to pulse
the motors at the correct speed for the required amount of time, allowing the robot to
come to a halt at the destination point. A MATLAB function that uses the above
equations to calculate the required angle to turn and distance to travel in order to reach a
particular position on the field can be found in Appendix G.2. This function, goToHere,
accepts three sets of coordinates, specified in 12 vectors. The first represents the
destination point, which is usually the coordinates of the ball or the goals, depending on
the current mode of play. The latter two represent the centroid and orientation marker of
the robot to be instructed. The function returns the distance between the robot and the
destination point and the angle the robot must turn in order to face this point. This angle
is either positive if the robot is required to turn clockwise or negative indicating the robot
should turn anticlockwise.
5.3.2
In order to allow both the motion control software and the communications system realtime access to the instruction telegram (see 6.3), a global variable vector representing
the 8 pieces of information required by the robots was established. This made altering the
values in the instruction telegram a trivial operation. Simple functions to select the
channel to transmit information, set the speed of the motors and energise the solenoid
were written. These can be seen in Appendix G.3.
42
As previously mentioned, in order to determine the appropriate actions for the robots,
game-play was divided into two modes of play dependent on possession of the ball.
Explicitly, these modes are: ball in dispute, which employs a ball fetching algorithm
and ball in possession, which employs a goal kicking algorithm. Both algorithms,
discussed below, are included in a single m-file that coordinates the entire game. This mfile can be seen in Appendix G.1.
possession. Otherwise, the loop repeats with the robot readjusting its orientation and
moving closer to the ball.
43
Speeding up the robot uses the balls inertia to ensure that it is kept close to the kicker
plate in preparation for shooting. Otherwise, the robot continues to move towards the goal
and the loop repeats.
A similar algorithm can be used to allow passing the ball between robots. For example, if
another robot is situated between the robot with the ball and the goals, a slightly modified
algorithm would be used to determine when the ball should be kicked to the free
teammate. Once the ball has been kicked, the robot it is now closest to would
automatically be instructed to retrieve it.
45
46
The algorithm is designed to predict the position of the ball at the next time the vision
system sends coordinates, based on the sample period and a simple assumption. By
calculating the characteristics of motion of the ball, the algorithm takes into account both
situations; when the ball is in motion and when it is stationary. Having received
component coordinates from the vision system, the algorithm calculates the distance
traveled by the ball since the last reading, as well as its average velocity, acceleration and
rate of acceleration over the sample period, using equations 5.4.1 through 5.4.4.
(5.4.1)
vcur =
d
T
(5.4.2)
acur =
vcur vprev
T
(5.4.3)
da acur aprev
=
dT
T
(5.4.4)
The angle of direction the ball is traveling in is also calculated from equation 5.4.5.
ycur yprev
xcur xprev
= arctan
(5.4.5)
An assumption is then made that over a small period of time, such as the sample period,
the rate of acceleration of the ball will remain constant. That is, the ball will
accelerate/decelerate at the same rate in the next time-step as was observed in the
previous time-step.
Using this assumption gives a value for the predicted rate of acceleration at the next timestep. This is then used to calculate the average acceleration and velocity expected over
47
the next sample time and the distance traveled by the next time-step, using the rearranged
equations shown in 5.4.6 through 5.4.8.
da
T + acur
dT
(5.4.6)
(5.4.7)
dnext = vnext T
(5.4.8)
anext =
Another assumption is made wherein the balls angle of direction is taken to be constant
over all time-steps. A prediction of the next coordinates of the ball is then obtained by
solving the simultaneous equations shown in 5.4.9 and 5.4.10.
tan =
ynext yprev
xprev xnext
(5.4.9)
(5.4.10)
The robot is then instructed to move to the anticipated position of the ball. This procedure
is repeated until the robot meets the ball and traps it, changing the mode of play to ball in
possession.
48
49
6 Communications System
6.1 Introduction
The software running on the host computer accepts instantaneous coordinates from the
vision system and calculates appropriate robot instructions based on the current mode of
play. It is the responsibility of the communications system to wirelessly transmit these
instructions to each of the three soccer robots so they implement the programs strategies.
A communications protocol needs to be developed to ensure that these instructions are
communicated both accurately and efficiently.
50
With each receiver receiving 800 bits per second, approximately 12.5 instructions are
being processed per second. The information transmitted is as follows:
Byte 1: Channel number
The channel number identifies for which robot the instructions are intended. This may
either be Channel 0, 1, or 2.
Byte 2: Element size
For each of the data being transmitted, one byte is sufficient. Thus this byte is set to 1
Byte 3: Number of elements
This defines how many elements are being transmitted. There are four items of data to be
transmitted, so this is set to four (these four elements are bytes 5, 6, 7 & 8).
Byte 4: Empty
This byte is unused and reserved for future functionality.
Bytes 5 & 6: Motor instructions
Each robot is driven by stepper motors. One byte is required for each motor (a total of
two bytes) to indicate the rate at which that motor should step. As a result, values for
speed will vary from -127 to +127, representing maximum speeds in both directions.
51
6.4.1
Transmitter side
The transmitter side, running continuously on the host computer, takes the instructions
calculated by the control software and assembles them into the 8 byte vector according to
the aforementioned protocol. The telegram is retrieved from the motion control software
via an S-Function block that provides constant access to the global variable vector
representing the 8 bytes of information. The communications system continuously
monitors the global vector, immediately transmitting it to the robots whenever a change
in any value is observed, thus providing instantaneous data relay between the control and
communications systems. The checksum for the telegram is calculated via the subsystem
shown in Figure 6.2 and the information is then sent to each of the robots receivers.
52
6.4.2
Receiver side
Each receiver listens on the same frequency for telegrams sent by the transmitter. When a
telegram is received, the channel number (Byte 1) must be checked to determine if the
robot is the intended recipient. This is achieved via the Simulink blocks shown in Figure
6.3, which performs a channel number check for the robot receiving on channel 0. Byte 1
is extracted from the vector and compared to the channel number of the robot. If the
equality result is true, the telegram is further processed. Otherwise the information is
disregarded.
Once the robot is certain it is the intended target of the telegram, the checksum must be
verified to ensure that the information has not been corrupted during transmission. The
checksum (Byte 8) is extracted from the vector and then subtracted from the sum of all
other bytes in the received telegram. If the result is zero the information is untainted and
thus retained by the microcontroller. Otherwise, the telegram is disregarded. Checksum
verification is accomplished via the subsystem shown in Figure 6.4.
53
54
Having identified that the information is both intended for the robot and uncorrupted, the
instructions can then be extracted from the vector. The motor drivers support a battery
saving function wherein if the instructions for both motors (Bytes 5 & 6) are zero, power
to the motors is cut so they cannot draw any current from the batteries. The subsystem
shown in Figure 6.5 enables this function by using the OR logical operator on the motor
instructions. The result will be false only if both instructions are zero, in which case the
motor control pin is set low to cut power to the motors. In all other cases, the result will
be true and said pin is set high, allowing one or both motors to be driven as desired. The
solenoid control pin is set high or low according to the value of byte 7.
In order to correctly pulse the motors, a variable square wave subsystem was created.
This takes the motor, speed retrieved from the telegram, and uses its value to set the
period of a square wave, required to step the motors. The variable square wave subsystem
can be seen in Figure 6.6.
55
57
7 Cost Analysis
As previously discussed, the Soccer Robot project was assigned a target budget of $250.
Many components were provided by the University of Adelaide free of charge and thus,
did not affect the budget. These components include the fire-wire camera, the three
miniDragon+ micro-controller boards, and all parts supplied by the workshops including
the robot chassis, wheels, the power distribution and motor driver circuitry as well as the
camera frame.
Despite the significant number of components provided free of charge, the project still
managed to exceed its target budget. However, this was found to be acceptable in
consultation with the project supervisor. An analysis of all components affecting the
budget can be seen in table 7.1.
Part
Type
Batteries
AA Ni-Mh 1650MAH
Tagged Cell Powertech
SS0901
Solenoids
Motors
Bearings
Field
Green Mat
$2.15
60
$14.95
$8.00
$6.58
$40.00
3
1
Total Cost
Jaycar
$129.00 Electronics
Jaycar
$44.85 Electronics
$48.00 M-GEN
Small Parts &
$19.74 Bearings
$40.00 Spotlight
$289.59
Table 7.1 illustrates the current parts necessary and their costs. However, there are some
small additional costs involved in the project that have not been presented here, for
example, nuts and bolts for assembling the robots.
58
8 Conclusion
The research, construction and implementation of an autonomous robotic soccer team has
not yet been fully completed. The project has developed to the point where individual
robots can be implemented successfully, but not to the extent that they can cooperate as a
team.
A robot design has been successfully manufactured and a vision system enabling multiagent coordination has been established.
A communications system was implemented for facilitating complete automation and
multi-agent coordination. However, the system was originally intended to use radio
frequency transceivers to send data. This was unsuccessful due to a 4 Hz interference
that, due to time constraints, could not be filtered out. A cable was used to compensate, as
per the contingency plan.
As anticipated, the project budget currently exceeds the target budget of AU$250.00.
However, preliminary research into other designs indicated that it is unrealistic to expect
to produce a design of a competitive standard given the target budget. The design solution
produced is a highly cost effective design. Whilst the design exceeds the target budget,
this excess is still within an acceptable margin as negotiated with the project supervisor.
The overall system produced contains vision, communications, and motion control
systems that can be easily modified and improved upon by other groups. Hence there is a
solid foundation for future project teams to build upon and achieve success.
The project group has gained experience in many facets of robotics and automation, and
as a result, is capable of effectively promoting the many advantages of Mechatronics
through the popular medium of soccer robotics.
59
9 Future Recommendations
For the University of Adelaide to achieve greater progress in the Soccer Robot Design
Project in future years, it is recommended that the following two improvements be
incorporated.
Firstly, it is recommended that the budget be increased to that of $1500. This years
project group aimed to improve upon the current standard of the 2003 team. However,
given the current target budget of $250, this truly proved to be a tougher challenge than
originally conceived. As documented in this report, several of the design decisions made
were based solely upon cost. After completing the literature review, it was acknowledged
that there is little dispute regarding what components and design solutions provide greater
performance, but it is simply a matter of affordability. It must be acknowledged that the
majority of successful teams have budgets far exceeding that of the current target budget.
Unless the budget is highly increased, the improvement of the current Adelaide
University standard over successive years will remain limited.
Secondly the University of Adelaide RoboCup team requires further development to meet
the current competitive standard. This development includes the creation and
implementation of two more robots, further developing the motion control system,
upgrading to a more optimal drive system, implementing a more powerful kicker device,
upgrading to a more reliable radio communication system and providing a more efficient
computational platform to run the vision system. It is advised that the following work be
done in these areas.
A small-size league team requires five robots to compete in RoboCup. The current team
consists of only three. A future project group hoping to enter a team into RoboCup must
build two additional robots, in addition to bringing the current three robots up to
competition standard.
In order to better develop game strategy, a future team may find it useful to build a
second team of five robots. This will allow testing of robot performance in competition.
60
The current team has very primitive motion control software. The capability of this
software is currently limited to the following simple tasks: retrieval of the ball, moving
with the ball and shooting for goal. In order to compete against an opposing team, the
host software must be capable of predicting the trajectories of objects such as the ball and
any opposing robots. Such ability will make it possible to implement game-play strategies
when facing opposition. The motion control software is currently written in MATLAB,
which is not effective at measuring time intervals. It will not be possible to measure
velocities and accelerations of objects on the field without implementing a means of
reasonably precise timing.
The movement of the robots would be significantly improved through the implementation
of an omni-directional drive system. Given the current competition standard, it is unlikely
that a differential drive system could be effective enough in competition with current and
recent champion teams. Implementing such a system would, however, require a complete
re-design of the robot chassis.
The current kicker device is not powerful enough to be effective. The power of the kicker
is determined by the current flowing through the coil of the solenoid. This could be
improved by applying a higher voltage to the solenoid or rewinding the coil with tighter
loops. Either or both of these modifications should be simple for a future team to
implement. Due to time constraints, the current team was unable to do so.
The radio transceivers used to transmit instructions proved to be ineffective due to
interference making it impossible to determine when an instruction telegram began. The
2005 team resorted to the use of tether cables to transmit instructions. Wireless
communication is essential for the team to function properly. This means that an
alternative system must be implemented, or that the 4Hz interference that prevented the
implementation of the current radio frequency transmitters be filtered out.
The vision system currently provides new co-ordinates at a rate of about one set per
second. This will not be adequate for effective prediction of objects on the field. The
61
62
10 References
10.1 Electronic Resources
1. Official RoboCup Website: [Accessed 18/03/2005]
http://www.robocup.org
2. RoboCup Small Size League (F180): [Accessed 18/03/2005]
http://www-2.cs.cmu.edu/%7Ebrettb/robocup/
3. Freie Universitt Berlin FU-Fighters Website: [Accessed 21/03/2005]
http://robocup.mi.fu-berlin.de/index.html
4. University of Queensland RoboRoos Website: [Accessed 21/03/2005]
http://www.itee.uq.edu.au/~dball/roboroos/
5. Cornell Universitys Big Red Team Website: [Accessed 24/03/2005]
http://robocup.mae.cornell.edu/
6. University of Swedens LuckyStar Team Website: [Accessed 24/03/05]
http://www.ida.liu.se/ext/robocup/
7. Carnegie Mellon Universitys CMRoboDragons Website: [Accessed 03/04/2005]
http://www-2.cs.cmu.edu/~robosoccer/small/
8. University of Alberta, Canada Team Canuck Website: [Accessed 03/04/2005]
http://www.cs.ualberta.ca/~robotics/robocup/
9. M-GEN The Mechatronic Generation Website: [Accessed 25/04/2005]
http://www.mgen.com.au
10. Thomson Airpax Industries Website: [Accessed 25/04/2005]
http://www.thomsonindustries.com/Sections/Products
11. Dick Smith Electronics Website: [Accessed 21/04/2005]
http://www.dse.com.au
12. Wiltronics Research Pty Ltd Website: [Accessed 21/04/2005]
http://www.wiltronics.com.au/
13. Jaycar Electronics Website: [Accessed 23/04/2005]
http://www1.jaycar.com.au/
14. Wytec Evaluation Boards Website: [Accessed 25/04/2005]
http://www.evbplus.com/
63
64
Appendices
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
(3.5)
a=
Td
0.75(m r )
(B.1)
From this equation, and the torque characteristics of the motors, an estimate of the
acceleration of the robot at different speeds can be calculated.
The M42SP-5 motors have a step size of 7.5 degrees, resulting in 48 steps per revolution.
Therefore, if p is the current motor speed in pulses per second, the number of revolutions
per second made by the robot is p/48 revolutions/second
The wheels have a diameter of 0.06 m. Therefore, in one revolution, the robot travels:
0.06 p
= 0.00393 p [m/s]
48
93
According to figure B.1, the relationship between torque (T) in mNm and motor speed
(p) in pps is roughly linear and can be approximated by equation B.2:
T = 0.19 p + 67
(B.2)
From this equation, the torque produced by the motors has been calculated in the table
below. From this, the resulting acceleration of the robot has also been determined.
The numbers in bold indicate where design specifications have been met.
Speed (pps)
20
40
60
80
100
120
140
160
180
200
220
240
260
280
300
320
340
Speed
(m/s)
0.08
0.16
0.24
0.31
0.39
0.47
0.55
0.63
0.71
0.79
0.86
0.94
1.02
1.1
1.18
1.26
1.34
Torque (Nm)
0.063
0.059
0.056
0.052
0.048
0.044
0.04
0.037
0.033
0.029
0.025
0.021
0.018
0.014
0.01
0.006
0.002
Acceleration (m/s^2)
1.4
1.31
1.24
1.16
1.07
0.98
0.89
0.82
0.73
0.64
0.56
0.47
0.4
0.31
0.22
0.13
0.04
94
0.006
STROKE LENGTH (m)
0.006
0.005
0.004
0.003
0.002
0.001
7.59
3.81
It is desirable that the force be exerted should be maximised at the end of the kick
This is increases the impulse of the kick.
Therefore, the slit should be vertical when solenoid fully retracted.
= 22 degrees
Distance from fulcrum when extended:
Distance from fulcrum when retracted:
X
SQRT(X^2 + 6^2)
SQRT(X^2 + 6^2) X
SLIT LENGTH
To allow for possible future alteration of the device, the slit length
was designed to be 5mm
Kicker Force and Stroke Length
Value of Y in extended position.
BASE Y (m)
0.025
Vertical projection of Y throughout kick.
ACTUAL Y (m)
0.023
0.024
0.024
95
0.025
0.025
0.025
600
715
830
5.89
7.01
8.14
3.63
4.76
Unless X=Y, the kicker plate will exert a different force to the solenoid.
and will travel a different distance.
KICKER-PLATE FORCE (N)
1.5
2.18
2.86
3.53
4.21
KICKER STROKE DISTANCE (m)
0.0093
0.0077
0.0062
0.0046
0.0031
4.88
0.0015
The kicker stroke has been adjusted to be sufficient to hit a ball which may have
bounced a short distance from the kicker whilst moving.
Velocity of Kicked Ball
Due to the varying dynamic conditions under which a ball may be kicked,
it is not possible to predict accurately the velocity of the ball upon being kicked.
If, generally, the ball is not propelled from the robot at sufficient speed, measures
can be taken to improve it.
96
ALPHA
stroke
4
5
6
7
8
9
10
11
12
13
1
14.04
11.31
9.46
8.13
7.12
6.34
5.71
5.19
4.76
4.40
2
26.56
21.80
18.43
15.95
14.04
12.53
11.31
10.30
9.46
8.75
3
36.87
30.96
26.56
23.20
20.56
18.43
16.70
15.26
14.04
12.99
4
45.00
38.66
33.69
29.74
26.56
23.96
21.80
19.98
18.43
17.10
5
51.34
45.00
39.81
35.54
32.01
29.05
26.56
24.44
22.62
21.04
6
56.31
50.19
45.00
40.60
36.87
33.69
30.96
28.61
26.56
24.78
FORCE
(g)
21
22
23
24
25
26
27
28
29
30
31
32
828.7
197.31
188.34
180.15
172.65
165.74
159.37
153.46
147.98
142.88
138.12
133.66
129.48
714.4
170.10
162.36
155.30
148.83
142.88
137.38
132.30
127.57
123.17
119.07
115.23
111.63
600.1
142.88
136.39
130.46
125.02
120.02
115.40
111.13
107.16
103.47
100.02
96.79
93.77
485.8
115.67
110.41
105.61
101.21
97.16
93.42
89.96
86.75
83.76
80.97
78.35
75.91
371.5
88.45
84.43
80.76
77.40
74.30
71.44
68.80
66.34
64.05
61.92
59.92
58.05
257.2
61.24
58.45
55.91
53.58
51.44
49.46
47.63
45.93
44.34
42.87
41.48
40.19
1
4.2
4.4
4.6
4.8
5
5.2
5.4
5.6
5.8
6
6.2
6.4
2
8.4
8.8
9.2
9.6
10
10.4
10.8
11.2
11.6
12
12.4
12.8
3
12.6
13.2
13.8
14.4
15
15.6
16.2
16.8
17.4
18
18.6
19.2
4
16.8
17.6
18.4
19.2
20
20.8
21.6
22.4
23.2
24
24.8
25.6
5
21
22
23
24
25
26
27
28
29
30
31
32
6
25.2
26.4
27.6
28.8
30
31.2
32.4
33.6
34.8
36
37.2
38.4
Kick force
y
x:
flap kick dist
y
5
stroke
21
22
23
24
25
26
27
28
29
30
31
32
97
98
Appendix C.2
99
100
Appendix C.3
101
Appendix C.4
102
103
1800
2050
104
data
date
data
data
data
data
data
1
2
3
4
5
6
7
=
=
=
=
=
=
=
ball (pink)
r1 centroid (yellow)
r1 direction (blue)
r2 centroid (red)
r2 direction (light green)
r3 centroid (orange)
r3 direction (white)
rgb = capImage(0);
out = imgProcSilent(rgb, scan4col);
105
maxArea = 0;
while(kk)
[cx, cy, x1, y1, x2, y2] = getCoordinates(out(j).Regions, kk);
area = (x2-x1)*(y2-y1);
if(area>maxArea)
maxArea = area;
largest = kk;
end
%Decrements the current object/subregion for that region
kk = kk - 1;
end
%if not null
if(largest > -1)
%get data of largest
[cx, cy, x1, y1, x2, y2] = getCoordinates(out(j).Regions, largest);
ll = plot([x1 x2 x2 x1 x1], [y1 y1 y2 y2 y1]); %plots the square
set(ll, 'Color', [1 1 1] - col);
ll = plot(cx, cy, 'x');
set(ll, 'Color', [1 1 1] - col);
drawnow
%save the centroid
data(colID+1, :) = [cx, cy];
end
end
%test output
data(: , :)
hold off
end
% ==========================================================
function [cx, cy, x1, y1, x2, y2] = getCoordinates(currentRegion, kk)
cx
cy
x1
y1
x2
y2
=
=
=
=
=
=
currentRegion(1,
currentRegion(2,
currentRegion(3,
currentRegion(4,
currentRegion(5,
currentRegion(6,
kk);
kk);
kk);
kk);
kk);
kk);
% centroid
% boundary box
106
107
108
i=1;
setChannel(1);
stopMotors();
disp('Robot 2 has stopped');
setChannel(0);
disp('Robot 1 is moving');
%elseif((d2 < d1) && (d2 < d3))
%
i=2;
%
setChannel(1);
else
i=2;
disp('Robot 2 is Moving');
setChannel(0);
stopMotors();
disp('Robot 1 has Stopped');
setChannel(1);
end;
%Determine if robot has ball
if (do(1, i) > POSSESSION)
gotBall = 0;
%Robot does not have ball, i.e. go get it
[dist, ang] = goToHere(ball, robots(i,:), robotsd(i,:));
%arc = ROBOT_WIDTH*abs(ang)/2;
if(d1 > 250)
T = abs(ang)*1.7;
else
T = abs(ang)*2.2;
end;
if(ang > 0)
%Robot must turn clockwise
setMotors(-10, 10);
pause(T);
stopMotors();
elseif(ang < 0)
%Robot must turn counterclockwise
setMotors(10, -10);
pause(T);
stopMotors();
else
%Robot does not need to turn
end;
%travel towards ball for a bit
setMotors(20,20);
pause(3);
else
gotBall = 1;
break;
end;
end;
end;
%Robot does have ball
while(gotBall == 1 && ballShot == 0)
109
110
setChannel(1);
stopMotors();
disp('Robot 2 has stopped');
setChannel(0);
disp('Robot 1 is moving');
%elseif((d2 < d1) && (d2 < d3))
%
i=2;
%
setChannel(1);
else
i=2;
disp('Robot 2 is Moving');
setChannel(0);
stopMotors();
disp('Robot 1 has stopped');
setChannel(1);
end;
if(d(1,i) <= POSSESSION)
disp('I have the ball!!!');
%stopMotors();
[dist, ang] = goToHere(GOALNORTH, robots(i,:), robotsd(i,:));
%If on target, speed up and shoot
if(ang <1 && ang>-1 && dist < 300)
setMotors(20, 20);
pause(0.5);
setMotors(30, 30);
pause(0.5);
shoot();
stopMotors();
ballShot = 1;
break;
end;
%kick if close to goal
if(dist < MAX_KICK)
shoot();
stopMotors();
ballShot = 1;
break;
end;
%arc = ROBOT_WIDTH*abs(ang)/2;
T = abs(ang)*3;
if(ang > 0.5)
%robot must turn clockwise
setMotors(0, 10);
pause(T);
stopMotors();
elseif(ang < -0.5)
%Robot must turn counterclockwise
setMotors(10, 0);
pause(T);
stopMotors();
else
end;
%setMotors(20, 20);
111
%pause(2);
else
gotBall = 0;
disp('I have lost the ball :(');
end;
end;
stopMotors();
end;
end;
stopMotors();
ballShot = 0;
pause(5);
112
The function goToHere accepts coordinates for a destination point and the centroid and orientation
marker of a specific robot. It returns the angle the robot must turn to face the destination point and the
distance it must travel in order to reach that point.
function
% @param
% @param
% @param
113
Appendix F.3
These telegram editing functions make use of the global variable vector to instantaneously set the
instructions within the telegram.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Function to set the channel number in the telegram
% Michael Shanahan 1078748
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
function setChannel(c)
global V;
V(1, 1) = c;
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Function to set the motor speeds
% Michael Shanahan 1078748
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
function setMotors(L, R)
global V;
V(1,5) = L;
V(1,6) = R;
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Function to cut power to the motors
% Michael Shanahan 1078748
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
function stopMotors()
global V;
V(1,5) = 0;
V(1,6) = 0;
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Function to shoot the kicker
% Michael Shanahan 1078748
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
function shoot()
global V;
V(1,7) = 1;
pause(2);
%De-energise the solenoid shortly after
V(1,7) = 0;
114
Transmitter model
The transmitter model, shown below in figure G.1 retrieves a telegram from the motion
control software whenever the global variable vector is altered. The S-function block
labeled Fetch telegram returns the global variable vector from the motion control
system and the transmitter model calculates the checksum for the telegram via the
subsystem shown in figure 6.2. The instruction telegram is then sent to the robots
microcontrollers via the FreePortComms_TX block.
115
116
117
118