small-size soccer robots - university of...
TRANSCRIPT
Small-Size Soccer Robots
2005 Level IV Design Project
Final Report
Supervisor: Dr. Frank Wörnle
Team Members:
Nicholas Jones 1068165 Michael Hill 1078262
Michael Shanahan 1078748
- ROBOCUP -
“By the year 2050, develop a team of fully autonomous humanoid robots that
can win against the human world soccer champion team.”
- The Ultimate Goal
1
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.
2
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 Wörnle (project supervisor), Silvio de Ieso and Derek Franklin from the school’s
electronics workshop, Bill, Richard and Steve from the school’s 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.
3
Table of Contents EXECUTIVE SUMMARY ...........................................................................................................................1
ACKNOWLEDGEMENTS ..........................................................................................................................2
1 INTRODUCTION................................................................................................................................6
1.1 ROBOCUP......................................................................................................................................6 1.2 THE 2005 LEVEL IV SOCCER ROBOTS DESIGN PROJECT ...............................................................7
1.2.1 Project definition .....................................................................................................................7 1.2.2 Project objectives ....................................................................................................................7 1.2.3 Project scope ...........................................................................................................................7 1.2.4 Project significance .................................................................................................................8
1.3 DESIGN SPECIFICATIONS................................................................................................................8 1.4 TEAM ORGANISATION....................................................................................................................9
2 LITERATURE REVIEW..................................................................................................................10
2.1 INTRODUCTION............................................................................................................................10 2.2 CRITICAL ANALYSIS AND DISCUSSION .........................................................................................10
2.2.1 Drive system ..........................................................................................................................10 2.2.1.1 Two-wheel differential system................................................................................................... 10 2.2.1.2 Three-wheel omni directional system ........................................................................................ 11 2.2.1.3 Four-wheel omni directional system .......................................................................................... 14
2.2.2 Kicker mechanisms ................................................................................................................15 2.2.2.1 Linear kicker mechanism ........................................................................................................... 15 2.2.2.2 Solenoid with striker plate ......................................................................................................... 15 2.2.2.3 Crossbow kicker mechanism...................................................................................................... 16 2.2.2.4 DC powered pinball mechanism ................................................................................................ 16 2.2.2.5 Bending kick board .................................................................................................................... 17
2.2.3 Dribbler mechanisms.............................................................................................................17 2.2.3.1 Fixed bracket.............................................................................................................................. 17 2.2.3.2 Rotating cylinder........................................................................................................................ 18
2.2.4 Sensory systems .....................................................................................................................18 2.2.4.1 Colour based vision system........................................................................................................ 19 2.2.4.2 Micro switches as touch sensors ................................................................................................ 19
2.3 LITERATURE REVIEW SUMMARY ................................................................................................20
3 MECHANICAL DESIGN .................................................................................................................21
3.1 INTRODUCTION............................................................................................................................21 3.2 DRIVE SYSTEM ............................................................................................................................21
4
3.2.1 Motor selection ......................................................................................................................22 3.2.2 Robot wheels..........................................................................................................................26
3.3 KICKING MECHANISM.................................................................................................................27 3.4 FRAME AND DRIBBLING MECHANISM ..........................................................................................29 3.5 POWER SOURCE...........................................................................................................................31 3.6 MECHANICAL DESIGN SUMMARY ................................................................................................31
4 VISION SYSTEM..............................................................................................................................34
4.1 INTRODUCTION............................................................................................................................34 4.2 HARDWARE SET-UP.....................................................................................................................34 4.3 METHODOLOGY ..........................................................................................................................35
4.3.1 Capturing and processing the image .....................................................................................35 4.3.2 Colour identification system ..................................................................................................35 4.3.3 Colour definition....................................................................................................................35 4.3.4 Initialisation and calibration .................................................................................................37 4.3.5 Image processing algorithm ..................................................................................................38
4.4 VISION SYSTEM SUMMARY ..........................................................................................................39
5 CONTROL SOFTWARE..................................................................................................................40
5.1 INTRODUCTION............................................................................................................................40 5.2 VISION SYSTEM INTERFACE.........................................................................................................40 5.3 NAVIGATION SOFTWARE .............................................................................................................41
5.3.1 Mapping coordinates to motor instructions...........................................................................41 5.3.2 Motion control software ........................................................................................................42
5.3.2.1 Ball fetching algorithm .............................................................................................................. 43 5.3.2.2 Goal kicking algorithm .............................................................................................................. 44
5.4 PREDICTIVE MOTION SOFTWARE ................................................................................................46 5.5 CONTROL SOFTWARE SUMMARY .................................................................................................49
6 COMMUNICATIONS SYSTEM .....................................................................................................50
6.1 INTRODUCTION............................................................................................................................50 6.2 HARDWARE SETUP ......................................................................................................................50 6.3 INSTRUCTION TELEGRAM ............................................................................................................50 6.4 ROBOT PROGRAMMING................................................................................................................52
6.4.1 Transmitter side.....................................................................................................................52 6.4.2 Receiver side..........................................................................................................................53
6.5 RISK ANALYSIS AND CONTINGENCY PLAN ...................................................................................56 6.6 COMMUNICATIONS SYSTEM SUMMARY .......................................................................................57
7 COST ANALYSIS .............................................................................................................................58
5
8 CONCLUSION ..................................................................................................................................59
9 FUTURE RECOMMENDATIONS .................................................................................................60
10 REFERENCES..................................................................................................................................63
10.1 ELECTRONIC RESOURCES............................................................................................................63 10.2 LITERATURE RESOURCES ............................................................................................................64
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 COMPONENT DATA SHEETS....................................................................................98
APPENDIX C.1 MINIDRAGON+ DEVELOPMENT BOARD.........................................................................98 APPENDIX C.2 M42SP-5 STEPPER MOTOR...............................................................................................99 APPENDIX C.3 SS0901 PULL-TYPE SOLENOID .......................................................................................101 APPENDIX C.4 RF TRANSMITTER AND RECEIVER ..................................................................................102
APPENDIX D VISION SYSTEM FRAME DIAGRAMS...................................................................104
APPENDIX E VISION SYSTEM SOFTWARE..................................................................................105
APPENDIX F MOTION CONTROL SOFTWARE CODE...............................................................107
APPENDIX F.1 MOTION CONTROL SOFTWARE MAIN PROGRAM..............................................................107 APPENDIX F.2 FUNCTION GOTOHERE....................................................................................................113 APPENDIX F.3 TELEGRAM EDITING FUNCTIONS.....................................................................................114
APPENDIX G COMMUNICATIONS SYSTEM BLOCK DIAGRAMS..........................................115
APPENDIX G.1 TRANSMITTER MODEL ...................................................................................................115 APPENDIX G.2 RECEIVER MODEL...........................................................................................................116
6
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.
7
1.2 The 2005 Level IV Soccer Robots Design Project
1.2.1 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
The primary goals of the Soccer Robots project are:
• Researching and developing an ideal robotic design suitable for entry in the
RoboCup small-size league and manufacturing a team of three such robots.
• Developing and implementing a vision system to allow for multi-agent
coordination between the robots and the ball.
• Developing and implementing a wireless communications system to facilitate
complete automation.
• Developing and implementing control software to realise simple robotic soccer
manoeuvres and coordinate strategic game-play.
• Complying with a target project budget of AU$250.00.
• 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.
8
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.
1.3 Design specifications
The specifications of the robot design were ultimately chosen to comply with the project
constraints. The budget played a predominant role in the selection of these specifications
as they provide an affordable target product. Choosing attainable design specifications
also allows for the informed selection of components such as motors and solenoids and
hence is a crucial step in the design process. The complete project specifications are
detailed as follows:
• 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.
9
• 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.
1.4 Team organisation
Due to the complexity and scale of the project and the small team size, it was necessary
that each member be responsible for overseeing various sections within the project whilst
still supporting all aspects of the project in a general sense. This concurrent design
strategy was chosen as it allowed for separate aspects of the design to be developed
simultaneously with minimal dependence on other sections. That being said, it was
imperative that each member maintained a strong knowledge of the other sections so that
interfacing between completed subsystems could be achieved with ease. Given the
limited time available, this method helped ensure a quality, thorough design with equal
input from each member.
The complete design was divided into four main subsystems; Mechanical System, Vision
System, Communications System and Control System. The responsibility of supervising
the completion of these systems was delegated amongst the team members as follows:
Mechanical System – Nicholas Jones
Vision System – Michael Hill
Communications & Control Systems – Michael Shanahan
Constant communication between each of these systems regarding development and
integration ideas meant that every member had an influence on all aspects of the design.
Design decisions that affected individual systems were left to that system’s respective
head. However, the responsibilities of program interfacing, debugging and report writing
were shared collectively to ensure quality, though the tasks of management and editing
were undertaken by one member to ensure consistency, structure and quality.
10
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.
2.2 Critical analysis and discussion
2.2.1 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 University’s
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 omni-
directional designs, and thus will be considerably slower than these when changing
directions.
11
Figure 2:1: Two-wheel differential design used by team CM RoboDragons ‘04
2.2.1.2 Three-wheel omni directional system
An omni-directional wheel has several smaller wheels integrated into it, allowing it to
have a higher manoeuvrability, see figure 2.2 below. By combining three omni-
directional wheels a robot is capable of moving in any direction without having to turn
first. The omni wheels are typically distributed in either a 120 or 150 degree
configuration.
Figure 2:2: (A) Omni-directional wheel design by German team Fu-Fighters.
(B) Omni-Directional wheel offered by supplier M-GEN.
12
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 omni-
directional 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.
Figure 2:3: 3-wheel omni directional drive 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 University’s 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.
13
Direction: Y-ref Direction: X-ref 120 Degree Omni-directional System Force (Wheel 1) =F*cos30 =F*0.866 Force (Wheel 1) =F*sin30 =F*0.5 Force (Wheel 2) =F*cos30 =F*0.866 Force (Wheel 2) =F*sin30 =F*0.5 Force (Wheel 3) =F*sin90 =F*0.0 Force (Wheel 3) =F*sin90 =F*0.5 Total Driving Force =F*1.73
Total Driving Force =F*2.0
150 Degree Omni-directional System Force (Wheel 1) =F*cos15 =F*0.966 Force (Wheel 1) =F*sin15 =F*0.258Force (Wheel 2) =F*cos15 =F*0.966 Force (Wheel 2) =F*sin15 =F*0.258Force (Wheel 3) =F*cos90 =F*0.0 Force (Wheel 3) =F*sin90 =F*1.0 Total Driving Force =F*1.93
Total Driving Force =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
A natural consequence of the omni-directional design is that it costs more to implement
than a differential design, as omni-directional wheels are more expensive and requires an
additional motor.
14
2.2.1.3 Four-wheel omni directional system
This version of the omni-directional system has four wheels placed in a square-like
arrangement. The advantage of this design is that it has the manoeuvrability of an
omnidirectional system, yet has a larger net driving force in any direction (for a unit force
input F provided from each motor) than the other previously described designs. Table 2.2
illustrates the relationship between force provided by each motor and net driving force
Direction: Y-ref Direction: X-ref 4 Wheel Omni-directional System Force (Wheel 1) =F*cos30 =F*0.707 Force (Wheel 1) =F*sin30 =F*0.707Force (Wheel 2) =F*cos30 =F*0.707 Force (Wheel 2) =F*sin30 =F*0.707Force (Wheel 3) =F*cos30 =F*0.707 Force (Wheel 3) =F*sin30 =F*0.707Force (Wheel 4) =F*cos30 =F*0.707 Force (Wheel 4) =F*sin30 =F*0.707Total Driving Force =F*2.82
Total Driving Force =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
15
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.
2.2.2.1 Linear kicker mechanism
This is the most basic form of kicker. This utilises a solenoid that directly hits the ball
propelling it forward. This design is cheap, and accurate. The problem is that there is not
much room for error, since the pin from the solenoid may miss its target unless a groove
or notch is assigned to ensure the ball is in place. Figure 2.6 displays the layout of the
solenoid kicker used by the Cornell University 2001 team.
Figure 2:6: Solenoid kicker mechanism designed by 2001 Cornell University team
2.2.2.2 Solenoid with striker plate
This is very similar to the Linear Kicker Mechanism described above. It features a
solenoid attached to a plate, as used by the Team Canuck(8) from the University of
Alberta, Canada. This “striker plate” increases the surface area of the kicker, increasing
the chance of it making contact with the ball. This method is cheap, and but whilst it has
a high chance of hitting the ball, it is not as accurate as the Linear Kicker mechanism,
since the Striker plate acts merely like a “bumper” that propels the ball generally in the
desired direction.
16
2.2.2.3 Crossbow kicker mechanism
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.
Figure 2:7: Crossbow kicker design used by Australian RoboRoos team
2.2.2.4 DC powered pinball mechanism
This incorporates a pinball mechanism, retracted using a DC motor, with the energy
stored in a spring. A trigger than releases the mechanism. This design is simple, and
effective. The drawback is that a pinball mechanism can be quite expensive to purchase,
and may be difficult to construct if resources are limited.
17
2.2.2.5 Bending kick board
This uses a similar system to the kicker plate, except a motor is used to bend back the
kick board, storing elastic energy, and is then released to fire. This allows an increased hit
area, but may still lack accuracy. This design is cheap to implement, plus the kick board
will probably be easier to attach than most models, especially the striker plate.
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.
2.2.3.1 Fixed bracket
This has what generally appears to be a hemispherical shaped claw fixed at the front of
the robot, designed to “contain” the ball in this position. The robot cannot “grip” the ball,
thus the bracket must stay fixed. The advantage and disadvantage of this, is that whilst a
larger bracket has a higher chance of collecting the ball, it may bounce around in the
bracket area and may be missed by the kicker mechanism depending upon its design.
Conversely, a smaller bracket may be able to hold the ball precisely, guaranteeing the
kicker mechanism a hit, yet it will have a smaller chance of collecting the ball unless the
host software, vision and communications systems are calibrated precisely enough.
The design advantage of the bracket is that it is cheap to create, and can be designed
separately as an attachable component to the front of the robot that minimally affects its
overall design.
18
2.2.3.2 Rotating cylinder
This design typically has a rotating cylinder that causes the ball to backspin, drawing it
constantly towards the robot. This allows the robot to effectively keep the ball, and
prevents it from bouncing away from the kicker mechanism. There a varying designs, but
the trend is to use two cylinders with a gap between them to allow the robot to hold the
ball in the midpoint. Often a kicker mechanism may launch the ball through this gap. The
most efficient variant of these devices found was designed by the Australian RoboRoos
team, where a vulcanised rubber rotating cylinder containing a screw thread draws the
ball to the centre of the robot where it is caught by a gap cut into the cylinder, see Figure
2.8. A rotating cylinder system requires a motor, and uses up room, therefore it cannot
simply be attached as an additional component to the robot; the chassis design must
heavily factor in the rotating cylinder. Any variant of this design will need additional
power, a motor and will cost significantly more than the Bracket design mentioned above.
Figure 2:8: Rotating “corkscrew” dribbling device designed by Australian RoboRoos
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.
19
2.2.4.1 Colour based vision system
This design involves placing a unique configuration of coloured markers on the top of
each robot identifying its location and orientation, see figure 2.9 below. The coloured
markers are commonly the shape of squares, triangles, or circles for simplicity. A camera
then takes images of the field, identifying the ball, the field, the goals, and the position
and orientation of each robot, via their individual colour patterns. This is the nominal
system used by the majority of all RoboCup entrants.
Figure 2:9: Colour-based vision system in action
2.2.4.2 Micro switches as touch sensors
This involves using Micro switches to help the robot determine if is about to collide with
another robot or if it is in contact with the ball. This system is ineffective on its own
however, and is only useful to either compensate for a slow or imprecise vision system,
or to add additional accuracy to a vision system.
20
2.3 Literature Review Summary
When possibilities for soccer robot components are analysed, there is little dispute
regarding which designs are most effective. The literature review shows a trend that the
most desirable components for a soccer robot system are generally an omni-directional
driver mechanism, a rotating cylinder dribbler mechanism, and a colour based vision
system, with various types of kicker mechanisms being equally effective. Unless a team
either lacks the experience, or quality components to implement these systems
effectively, the design of their soccer robot will be almost always be dominated by
budget. This is apparent in the design of the Adelaide University 2003 Team, and the
design of the current 2005 team suffered from the same limitations. However, based upon
the literature we have reviewed, it is also acknowledged that paying twice as much for
better components does not necessarily provide twice the performance. Teams have been
successful in the past with high quality designs of the more basic components. It is upon
this premise that the 2005 design team have attempted to improve Adelaide University’s
current standard.
21
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.
3.2 Drive system
A feasibility study was conducted to determine the impact of an omni-directional drive
system on the project budget. The simplest omni-directional drive requires three omni-
directional wheels and three motors to run them whereas a differential drive requires only
two conventional wheels and two motors per robot.
A cost estimate comparison was produced with components available from national
supplier M-GEN(9). The results are displayed in Table 3.1.
3 Wheel Omni Directional Design, (Large Barrels), MGEN Stepper Motors
Part Type Cost Quantity Sub Total (AUD) Motors Small Stepper Motor, Step 35mm $8.00 9 $72.00 Wheels TRANSWHEEL, (OMNI-LIT) $17.50 9 $157.50
TOTAL $229.50 2 Wheel Generic Design, MGEN Stepper Motors
Part Type Cost Quantity Sub Total (AUD)
Motors Small Stepper Motor, Step 35mm $8.00 6 $48.00 Wheels Basic Cylinder Shaped Wheel $2.50 6 $15.00 TOTAL $63.00
Table 3.1: Omni directional vs. differential drive cost comparison
22
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 Newton’s second
law, expressed in equation 3.1.
amF ⋅= (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.
)(5.0 amFw ⋅= (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.
rFwT ⋅= (3.3)
)(5.0 ramT ⋅⋅= (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.
23
)(75.0 ramTd ⋅⋅= (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 mN·m.
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.
24
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 M-
Gen 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.
Figure 3:1: M-GEN M42SP-5 stepper motor
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.
Motor Supplier Torque (g.cm) Voltage (V) Mass (g)
Cost for Six ($)
H42S254001 Thomson ECN 1700 12 150 (US)101.7 M42SP-5 M-GEN 795 12 200 48.00 YM7251 Stepper
Jaycar Electronics 450 12 Unavailable 101.7
High Speed Torque Motor
Dick Smith Electronics 69.2 12 Unavailable 29.7
MO 0040 DC Wiltronics 320 12 Unavailable 59.4
Table 3.2: Motor torque specifications
25
Figure 3:2: Torque-speed characteristics for M42SP-5
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.
360)( rpsv ⋅⋅
= (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.
26
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 1.02 0.4 280 0.014 1.1 0.31 300 0.01 1.18 0.22 320 0.006 1.26 0.13 340 0.002 1.34 0.04
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 omni-
directional 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.
27
3.3 Kicking Mechanism
The kicking mechanism is required for passing the ball between robots and for taking
shots at goal. A number of options were considered for this system including the use of a
solenoid to simply propel the ball directly, a piston driven by a motor through a rack and
pinion system and the use of pneumatics.
The linear kicker mechanism using a push solenoid suffers from the fact that solenoids
available in the desired power range often have a very low stroke length (on the order of
millimetres). It is however relatively cheap and simple to implement. The addition of a
striker plate was considered to increase the area of the kicker that will make contact with
the ball, reducing the chance of glancing blows reducing accuracy.
The ideas of a crossbow kicker mechanism, pinball mechanism or bending kick board
were considered but rejected as they required expensive parts (such as gears and motors)
as well as comparatively complicated mechanisms. Although all are potentially very
effective, these types of mechanisms could not be accommodated in the proposed budget.
Therefore, a solenoid based kicker was be used. Most solenoids of reasonable
performance and power requirements are of a ‘pull’ type with quite low stroke length. A
proposed solution to both of these issues was the addition of a small lever. The solenoid
pulls from the top of the lever, above the fulcrum, and the kicker plate located below the
fulcrum projects forward as the solenoid retracts.
An advantage of this design is that no secondary mechanism is required to retract the
kicker plate after firing, as the weight of the plate alone is sufficient to bring the kicker
back to its original state.
In figure 3.3, the vertical distance between the point of action of the solenoid upon the
lever and the fulcrum is designated as ‘x’. The vertical distance between the fulcrum and
the approximate point of contact with the ball is designated as ‘y’. The angle through
which the lever rotates due to the solenoid stroke is termed ‘α’.
28
Figure 3.3: Design & action of the kicking device.
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.
Figure 3.4: Jaycar Electronics SS0901 solenoid
29
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.
3.4 Frame and dribbling mechanism
Having selected suitable motors, wheels and a drive system, the robot frame to house all
components was designed within the size constraint. Many other RoboCup entrants claim
that weight of the frame is a significant factor of their designs. The 2003 design team
used a plastic frame to take advantage of its lightweight and low cost. Aluminium is a
popular solution to negate weight concerns. It is just as inexpensive and light as plastic,
while providing extra strength and rigidity. Therefore, aluminium was selected as the
material from which the frame was constructed. The frame houses the motors, their
drivers and the kicker mechanism. Furthermore, the frame had to provide space to attach
the microcontroller and battery pack and incorporate a type of ball-trapping device. With
these requirements in mind, a frame was designed as a hollow cubical shell constructed
entirely of plate aluminium.
30
Figure 3.5: Frame design
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.
31
3.5 Power source
A battery pack was selected as the most appropriate source of power as batteries are
readily available and are reasonably cost efficient. The battery pack is a vital component
as it stores energy that can be consumed by the motors, solenoids, microcontroller and
circuitry. The motors require a supply voltage of 12 V. As each battery supplies 1.2 V, a
total of ten batteries are required in each pack. A choice had to be made between AA or
AAA batteries. The AA batteries featured a longer lifespan than the AAAs, however they
also weighed and cost more. In this application, lifespan was deemed of higher
importance than weight and cost. Thus, rechargeable AA Ni-Mh 1650 mAH Tagged Cell
Powertech batteries were chosen.
3.6 Mechanical design summary
Final diagrams of the completed robot can be seen in figures 3.6, 3.7 and 3.8. A parts list
is included in Table 4.4.
Figure 3.6: Assembled prototype
32
Figure 3.7: Assembled kicker mechanism
33
Table 3.4: Prototype parts list
Part Type Quantity Roof Plate Aluminium 1 Side Plate Aluminium 2 Base Plate Aluminium 1 Lever Arm Aluminium 1
Centre Column Aluminium 1 Kicker Plate Aluminium 1
Wheel Aluminium 2 Motor M-GEN M42SP-5 Stepper 2
Motor Driver Circuit Board Custom 1
Power Distribution Board Custom 1
Solenoid Jaycar SS0901 1 Microcontroller Wytec miniDRAGON+ 1
Receiver RLP434 1 Battery Powertech AA Ni-Mh 10
34
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.
4.2 Hardware Set-up
The Vision System consists of two main components:
1) A fire-wire camera (DFK 31 F03) 2) The vision software
The Imaging Source DFK 31 F03 fire-wire camera was mounted on a steel frame,
elevating it 1.8 metres above the soccer field. Design diagrams for the frame can be found
in Appendix D. Drivers for the camera were provided by Carnegie Mellon University.
Connected to the host computer via fire-wire cable, the camera’s fish eye lens provided a
94-degree angle of conical vision, supplying a view of the entire field. The imaging
toolbox allowed captured images to be analysed directly within MATLAB, returning the
results to the host computer for processing.
35
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 Capturing and processing the image
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 Colour identification system
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:
36
Figure 4.1: Colour Definition File: “Colors”
Figure 4.2: Colour Definition File: “Thresholds”
37
The first section labelled “Colors” includes four columns:
The first column consists of an RGB colour triplet defined by the user. For visualisation
purposes, all the pixels of a described colour detection range will be appear in the colour
described here.
The second column, containing a value between 0 and 1, is the Merge Density parameter.
This is a colour density limit, beyond which two individual clusters become merged as
one cluster. This value therefore controls the granular definition separating detected
clusters.
The third column has the colour ID, which allows clusters to be identified by their colour
quality.
The fourth column comprises the colour name (optional), which allows the user to
associate a name with a detected object.
The second section labelled “Thresholds” contains the RGB ranges used to detect each
cluster. Once the clusters have been identified, the command capProc() applies the
settings for a given cluster as described in “color.txt”, such as describing that cluster by
it’s assigned colour from column 1.
4.3.4 Initialisation and calibration
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.
38
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.
Figure 3.3: Vision system calibration
4.3.5 Image processing algorithm
Using the previously mentioned methods, the vision system will successively process
images according to the following algorithm:
39
Capture and process image
Firstly the vision system will receive an image from the camera and process it.
Identify objects
The vision system will then identify the ball and the robots based upon the respective
distinct colours of the ball and the coloured markers that represent the robots.
Determine relevant coordinates
Once the objects have been identified, their locations on the field can be determined using
the vision software and imaging toolbox. This provides coordinates for the centroid of the
ball and the centroids and orientation markers of the robots.
Return coordinates
As soon as the relevant coordinates have been obtained, they are then passed to the
motion control software.
4.4 Vision system summary
In summary, the vision system has been completed and is currently at a point where it
carries out all required operations with exceptional accuracy. It correctly identifies the
largest object of each colour that it has been specified to search for in the colour
definition file, and returns its centroid to the motion control software as required. The
camera itself is able to provide a much faster update rate of approximately 15 frames per
second. However, the computation speed of MATLAB is detrimental to the rate of the
vision system and improvements in this area may need to be considered in future projects.
40
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.
5.2 Vision system interface
The host software is required to receive object coordinates from the vision system in
order to continually update robot instructions. Because this has to be done continuously at
regular intervals, a timer object was created in the main program of the host software that
calls the vision system function every time the timer period elapses. Once invoked, the
vision system function returns a matrix of coordinates of the following format:
⎥⎥⎥⎥⎥⎥⎥⎥⎥
⎦
⎤
⎢⎢⎢⎢⎢⎢⎢⎢⎢
⎣
⎡
dd
dd
dd
bb
yxyxyxyxyxyxyx
33
33
22
22
11
11
Where xb and yb are the coordinates of the ball’s centroid, xi and yi are the coordinates of
robot i’s centroid and xid and yid are the coordinates of robot i’s orientation marker.
41
5.3 Navigation software
5.3.1 Mapping coordinates to motor instructions
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 robot’s
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:
⎥⎦
⎤⎢⎣
⎡−−
=11
11
yyxx
Vd
dd ⎥
⎦
⎤⎢⎣
⎡−−
=1
1
yyxx
Vs
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.
sd
sd
VVVV ⋅
=θcos (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.
ω⋅=
rdT (5.3.2)
42
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.
θ⋅= wl (5.3.3)
ω⋅=
rlT (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 1×2 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 Motion control software
In order to allow both the motion control software and the communications system real-
time 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.
43
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 m-
file can be seen in Appendix G.1.
5.3.2.1 Ball fetching algorithm
The ball fetching algorithm calls the function goToHere, with the ball’s coordinates as
the destination point. A constant value, possession, represents the distance between
the robot’s centroid and the ball, less than which the robot is deemed to be in possession
of the ball. The exact value was determined such that only when the ball was within the
robot’s catcher device would it be deemed as being in possession of the ball. The ball
fetching algorithm is summarised in the flowchart in Figure 5.1.
The program enters a loop wherein the robot is instructed to turn the angle supplied by
the goToHere function in order to face the ball. The motors are then pulsed a short
amount of time to move the robot closer to the ball. An update from the vision system is
then called and an evaluation of the current distance between the robot and the ball is
conducted. If the distance to the ball, dist2ball, is less than the constant value
possession, the loop is broken and the mode of play is changed to ‘ball in
possession’. Otherwise, the loop repeats with the robot readjusting its orientation and
moving closer to the ball.
44
Figure 5.5:1: Ball fetching algorithm
5.3.2.2 Goal kicking algorithm
Once a robot is in possession of the ball, indicated by their respective centroids being
within a specific distance of each other, the function goToHere is called with the closest
goals being the destination coordinates. A loop is entered wherein the robot is instructed
to turn and face the goals and commence moving towards them. At every data call from
the vision system, the current distance between the robot and the goal, distgoal, is
calculated and compared to a constant value, maxKick that represents the maximum
distance the ball can travel as a result of firing the solenoid. If distGoal is found to be
less than maxKick the robot is instructed to speed up and kick the ball.
45
Figure 5.5:2: Goal kicking algorithm
Speeding up the robot uses the ball’s 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.
46
5.4 Predictive Motion Software
Predictive Motion involves attempting to estimate the future motion of the ball over a
short amount of time by analysing the current trends in the ball’s motion. This is an
extremely useful technique as it provides an insight into the future state of the playing
field and hence the robots can be coordinated accordingly. Understandably, predictive
motion software eliminates a great deal of ball-chasing time, giving the robotic team a
sizeable advantage over its opponents. Unfortunately, the effects of the computational
speed of MATLAB on the vision system update rate limited the implementation of
predictive motion software. Despite this, some investigation into how predictive motion
would be realised was conducted and the main conclusions are summarised in the
algorithm shown in Figure 5.2.
Figure 5.5:3: Predictive Motion Algorithm
47
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.
)()( 22prevcurprevcur yyxxd −+−= (5.4.1)
Tdvcur = (5.4.2)
Tvva prevcur
cur−
= (5.4.3)
Taa
dTda prevcur −
= (5.4.4)
The angle of direction the ball is traveling in is also calculated from equation 5.4.5.
⎟⎠⎞
⎜⎝⎛
−−
=prevcur
prevcur
xxyyarctanθ (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 time-
step. This is then used to calculate the average acceleration and velocity expected over
48
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.
curnext aTdTdaa +⋅= (5.4.6)
curnextnext vTav +⋅= (5.4.7)
Tvd nextnext ⋅= (5.4.8)
Another assumption is made wherein the ball’s 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.
)()( 22curnextcurnextnext yyxxd −+−= (5.4.9)
nextprev
prevnext
xxyy
−−
=θtan (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’.
49
5.5 Control software summary
To sum up, the control software is currently at a point where only a few primitive soccer
manoeuvres can be performed. With object coordinate data from the vision system, the
control software can determine the closest robot to the ball and successfully instruct it to
fetch the ball. Once the robot has the ball, it is instructed to turn and face the goals, move
towards them and kick.
All control software is written in MATLAB and instantaneously passes an instruction
telegram to the communications system via a global variable vector. Game-play was split
into two modes of play in order to determine the most appropriate actions for the robots
at any given time. These modes are dependent upon whether or not any of the robots has
possession of the ball.
Predictive motion, while not implemented in the control software, still remains an
important concept in the game of robotic soccer. As a result, some initial ideas and
concepts on how to apply predictive motion have also been presented.
50
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 program’s strategies.
A communications protocol needs to be developed to ensure that these instructions are
communicated both accurately and efficiently.
6.2 Hardware setup
The communications system consists of a TLP434A Ultra Small Transmitter that sends
one-way wireless instructions to three RLP434 Receivers, each attached to a soccer robot.
The transmitter itself is connected by cable to the Host CPU, which sends the instruction
signals. The transmitter broadcasts instructions over three channels 0, 1 & 2, one channel
for each robot. The microprocessors on each robot then read the instruction signal from
the receivers and trigger the motors and solenoids accordingly. All robots listen for
transmissions on the same frequency and must therefore determine, via the channel
number, if they are the intended recipient of the information being sent. The physical set-
up is shown below in Figure 6.1.
6.3 Instruction telegram
The software sends information to the robots in a series of bytes. This requires that a
protocol be developed detailing what each ‘bit’ in a binary string represents. The
necessary information can be communicated in 8 bytes of information. The first 4 bytes
comprise a telegram header and the successive 4 bytes represent the robot instructions.
Since the transmitter can send 4800 bits per second and it is desired to allow for gaps in
between each transmission, a safe bandwidth of 2400 bits per second will be used.
51
Figure 6.1 Communications System Setup
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.
52
Byte 7: Solenoid instructions
The solenoid is only ever in one of two states: energised or de-energised. Therefore one
byte is sufficient for solenoid control. This byte is set to ‘1’ to energise the solenoid or ‘0’
to de-energise it.
Byte 8: Checksum
Errors sometimes occur in data transfer. For example a transmitted ‘1’ can become a ‘0’
on arrival due to interference or a lapse in CPU speed. By implementing a checksum
byte, incorrect transmissions can be identified and discarded. A checksum ensures that
for a given string, the sum of its transmitted bits match the sum of the bits received. Thus,
byte 8 is set to the sum of all other bytes in the telegram.
6.4 Robot programming
The code for the microcontroller is created using the RTMC9S12-Target Toolbox,
designed for use with the mathematical computer program MATLAB. This toolbox
allows all the necessary functions of the microcontroller to be accessed using customised
Simulink S-Function blocks, which are then converted to ‘C’ code by the toolbox to be
downloaded to the robots’ microcontrollers via the Metrowerks CodeWarrior application.
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.
53
Figure 6.2: Subsystem that calculates checksum of sent telegram
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.
54
Figure 6.3: Performing a channel number check in Simulink
Figure 6.4: Subsystem to perform checksum verification
55
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.
Figure 6.5: Motor power control
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.
56
Figure 6.6: Variable square wave subsystem
6.5 Risk analysis and contingency plan
Upon further development of the Communications System, it was discovered that the
signal sent to the receiver was corrupted by an unknown square wave oscillating at
approximately 4 Hz. This continuously occurring disturbance caused the transmitted data
to be immediately overwritten every time the leading edge of the square wave is
recorded. Due to the nature of the noise, the data in the transmitted telegram could not be
accessed by the microcontroller before it was overwritten, rendering the wireless
communications system useless. Testing with an oscilloscope proved that the telegram
was correctly transmitted, before being overwritten by the disturbance.
In the event that this noise cannot be ignored or filtered out, a contingency plan was
established to allow the project to continue. A custom serial cable featuring a one-head to
three-pin setup has been manufactured providing uninterruptible contact between the
robots and host computer. This cable will be used if the above-mentioned risk comes to
fruition and while it does not meet the terms of the original goals and ambitions of this
project, it does provide a means to satisfy the remaining project goals.
57
6.6 Communications system summary
The communications system was originally intended to make use of wireless radio
frequency transceivers to provide uninterruptible contact between the robots and host
computer. However, due to an unexpected interference that requires filtration, a tethered
serial cable design has been put in place as a contingency plan.
All robot instructions are contained within an 8 byte telegram that is instantaneously
passed from the motion control software to the communications software via a global
variable vector. A checksum has been implemented in the telegram to ensure any
corrupted data is disregarded. The communications software itself is written in Simulink
block diagrams.
58
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 Cost per unit Quantity Sub Total (AUD) Supplier Batteries AA Ni-Mh 1650MAH
Tagged Cell Powertech $2.15 60 $129.00 Jaycar Electronics
Solenoids SS0901 $14.95 3 $44.85
Jaycar Electronics
Motors M42SP5 High Torque Stepper Motor $8.00 6 $48.00 M-GEN
Bearings SSRBM080x0212SKT-C$6.58 3 $19.74
Small Parts & Bearings
Field Green Mat $40.00 1 $40.00 Spotlight Total Cost $289.59
Table 7.1: Cost Analysis
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.
59
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 multi-
agent 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.
60
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 year’s
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.
61
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
62
camera itself is capable of providing an update rate of approximately 15 frames per
second. However, this is severely restricted by the computational speed of MATLAB and
will require careful consideration when implementing a future vision system.
Currently, the electrical component boards mounted on the robot appear untidy. A future
team may find it convenient to have the motor drivers, power distribution board and
communications device mounted onto the same board.
In summary, for the Soccer Robot project to me the current competitive standard, a larger
budget must be incorporated with the project and the recommended upgrades be
incorporated into the design.
63
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 Universität 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 University’s Big Red Team Website: [Accessed 24/03/2005]
http://robocup.mae.cornell.edu/
6. University of Sweden’s LuckyStar Team Website: [Accessed 24/03/05]
http://www.ida.liu.se/ext/robocup/
7. Carnegie Mellon University’s 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/
64
15. University of Adelaide Robotics Website: [Accessed 18/03/2005]
http://www.mecheng.adelaide.edu.au/robotics/
[Accessed
16. Osaka University Team Website: [Accessed 12/05/2005]
http://www.er.ams.eng.osaka-u.ac.jp/robocup/osayans
10.2 Literature Resources
1. University of Adelaide RoboCup Team 2003, Development Preliminary Report.
2. Weber, Christian 2005. Constructional design of a Robot Soccer used in the
robotic soccer middle size league.
3. Heikkilä, J. "Geometric Camera Calibration Using Circular Control Points",
IEEE Transactions on Pattern Analysis and Machine Intelligence, Vol. 22, No.
10, pp. 1066-1077, Oct 2000.
4. Motorola, MC9S12DP256: Advanced Information. Dec 1, 2000 – Revision 1.1.
5. Wörnle, F. RTMC9S12-Target: A Simulink target for real-time control using
Freescale MC9S12DP256B/C microcontrollers, Manual V1.12, May, 2005.
6. Wörnle, F. TIS Vision tools: A simple MATLAB interface to the “The Imaging
Source (TIS)” FireWire cameras (DFK 31 F03). April, 2005.
7. The Imaging Source 2002, Dxx21F04 User’s Manual
65
Appendices
66
Appendix A RoboCup Rules & Regulations
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
93
Appendix B Design Calculations
Appendix B.1 Motor calculations
COMPONENT ESTIMATED MASS (Kg) 2 x H42S series stepper motor 0.3
Motor Driver 0.1 2 x Wheels 0.1
Battery pack 0.3 MiniDragon board 0.5 Aluminium Chassis 0.6
Total 1.9
Table B.1: Estimated mass of robot
Acceleration for a given torque (Equation 3.5 from §3.2.1)
)(75.0 ramTd ⋅⋅= (3.5)
Rearranging for acceleration yields equation B.1.
)(75.0 rmTda
⋅= (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:
pp 00393.048
06.0=
⋅π [m/s]
94
Figure B.1: Torque-Speed Characteristics for M42SP-5
According to figure B.1, the relationship between torque (T) in mN·m and motor speed
(p) in pps is roughly linear and can be approximated by equation B.2:
6719.0 +−= pT (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) 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 1.02 0.4 280 0.014 1.1 0.31 300 0.01 1.18 0.22 320 0.006 1.26 0.13 340 0.002 1.34 0.04
Table B.2: Robot speed and acceleration
95
Appendix B.2 Kicker design calculations
For these calculations, relationships between design quantities were established in a spreadsheet and the values altered to produce the optimum result. The SS0901 has a stroke of 1-6mm. STROKE LIMIT (m) STROKE MIN (m) 0.006 0.001 STROKE LENGTH (m) 0.006 0.005 0.004 0.003 0.002 0.001 Lever Slit Length and Angle Value of X in extended position: BASE X (m) 0.015 Angle of lever, α, at various stages of solenoid retraction. α (degrees) 21.80 18.43 14.93 11.31 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: X Distance from fulcrum when retracted: SQRT(X^2 + 6^2)
Distance pin moves relative to fulcrum: SQRT(X^2 + 6^2) - X
SLIT LENGTH 0.0012 m 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 0.025 0.025 0.025
96
Force exerted by the solenoid throughout the kick: STROKE FORCE (g) 255 370 485 600 715 830 STROKE FORCE (N) 2.5 3.63 4.76 5.89 7.01 8.14 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 4.88 KICKER STROKE DISTANCE (m) 0.0093 0.0077 0.0062 0.0046 0.0031 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.
97
ALPHA stroke 1 2 3 4 5 6x 4 14.04 26.56 36.87 45.00 51.34 56.31 5 11.31 21.80 30.96 38.66 45.00 50.19 6 9.46 18.43 26.56 33.69 39.81 45.00 7 8.13 15.95 23.20 29.74 35.54 40.60 8 7.12 14.04 20.56 26.56 32.01 36.87 9 6.34 12.53 18.43 23.96 29.05 33.69 10 5.71 11.31 16.70 21.80 26.56 30.96 11 5.19 10.30 15.26 19.98 24.44 28.61 12 4.76 9.46 14.04 18.43 22.62 26.56 13 4.40 8.75 12.99 17.10 21.04 24.78
Kick force FORCE (g) 828.7 714.4 600.1 485.8 371.5 257.2
y 21 197.31 170.10 142.88 115.67 88.45 61.24 22 188.34 162.36 136.39 110.41 84.43 58.45 23 180.15 155.30 130.46 105.61 80.76 55.91 24 172.65 148.83 125.02 101.21 77.40 53.58 25 165.74 142.88 120.02 97.16 74.30 51.44 26 159.37 137.38 115.40 93.42 71.44 49.46 27 153.46 132.30 111.13 89.96 68.80 47.63 28 147.98 127.57 107.16 86.75 66.34 45.93 29 142.88 123.17 103.47 83.76 64.05 44.34 30 138.12 119.07 100.02 80.97 61.92 42.87 31 133.66 115.23 96.79 78.35 59.92 41.48 32 129.48 111.63 93.77 75.91 58.05 40.19 x: 5 flap kick dist stroke y 1 2 3 4 5 6 21 4.2 8.4 12.6 16.8 21 25.2 22 4.4 8.8 13.2 17.6 22 26.4 23 4.6 9.2 13.8 18.4 23 27.6 24 4.8 9.6 14.4 19.2 24 28.8 25 5 10 15 20 25 30 26 5.2 10.4 15.6 20.8 26 31.2 27 5.4 10.8 16.2 21.6 27 32.4 28 5.6 11.2 16.8 22.4 28 33.6 29 5.8 11.6 17.4 23.2 29 34.8 30 6 12 18 24 30 36 31 6.2 12.4 18.6 24.8 31 37.2 32 6.4 12.8 19.2 25.6 32 38.4
98
Appendix C Component Data Sheets
Appendix C.1 MiniDRAGON+ development board
99
Appendix C.2 M42SP-5 stepper motor
100
101
Appendix C.3 SS0901 pull-type solenoid
102
Appendix C.4 RF transmitter and receiver
103
104
Appendix D Vision System Frame Diagrams
Pictured here are the CAD draft diagrams used to manufacture and assemble the vision
system frame.
1800
2050
105
Appendix E Vision system software This vision system software captures an image of the field and uses the colour definition file to
identify all relevant colours on the field. The imaging toolbox is then used to determine the
coordinates of the centroid of the largest instance of each colour found on the field. This information
is compiled in a 7×2 array labelled ‘data’ and returned to the host computer. %Uses getCoordinates() function[data] = robotFinal(); %Initialise scan4col = [1 2 3 4 5 6 7]; % define vector of colours to find (testcolors.txt) % data 1 = ball (pink) % date 2 = r1 centroid (yellow) % data 3 = r1 direction (blue) % data 4 = r2 centroid (red) % data 5 = r2 direction (light green) % data 6 = r3 centroid (orange) % data 7 = r3 direction (white) rgb = capImage(0); % cap rgb image out = imgProcSilent(rgb, scan4col); % display image, all processing has been done at this stage image(rgb); axis image ij; drawnow; %number of valid regions per colour nvr = [out(:).nRegions]; %any valid regions at all? if(any(nvr)) hold on; % declares the array as being full of -1's. data = -1*ones(7, 2); %loops through each region, ie blue, green, red for(j = 1:length(nvr)) %kk=number of objects/subregions in that region kk = out(j).nRegions; %col = the colour of that region col = out(j).Colour; %ID count starts at 0 colID = out(j).ColourID; largest = -1;
106
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 = currentRegion(1, kk); % centroid cy = currentRegion(2, kk); x1 = currentRegion(3, kk); % boundary box y1 = currentRegion(4, kk); x2 = currentRegion(5, kk); y2 = currentRegion(6, kk);
107
Appendix F Motion Control Software Code
Appendix F.1 Motion control software main program
This is the main program that continuously runs on the host computer, coordinating all robotic
movement. The program consists of two loops contained within an endless loop. The first nested loop
performs the ball fetching algorithm when the mode of play is ‘ball in dispute’. The second nested
loop performs the goal kicking algorithm when the mode of play is ‘ball in possession’. The loops are
interchanged depending on the relationship between the distance from the active robot to the ball and
the constant value POSSESSION. This program calls the vision system function (Appendix E) to
obtain object coordinates and utilises the goToHere function (Appendix F.2) and telegram editing
functions (Appendix F.3) to coordinate game play. global V; %Constant values POSSESSION = 50; GOALNORTH = [142 436]; GOALSOUTH = [150 381]; ROBOT_WIDTH = 70; %half robot width SPEED_AT_20 = 68.73; %Speeds in mm/sec SPEED_AT_30 = 113.67; SPEED_AT_40 = 148.15; MAX_KICK = 200; %Boolean variables to indicate state, initiated to false gotBall = 0; ballShot = 0; %Initialise Motors setChannel(0); stopMotors(); setChannel(1); stopMotors(); %Loop forever while(true) while(ballShot == 0) while(gotBall == 0) %Re-initialise Possession POSSESSION = 50; %Retrieve coordinates from vision system data = robotFinal();
108
%Initialise Robot Coordinates %roboti holds the coordinates of robot i's centroid %robotid holds the coordinates of robot i's orientation marker ball = data(1, :); robot1 = data(2, :); robot1d = data(3, :); robot2 = data(4, :); robot2d = data(5, :); %robot3 = data(6, :); %robot3d = data(7,:); %Vectors to hold robot data robots = [robot1; robot2]; robotsd = [robot1d; robot2d]; %Only execute code if vision system returns logical robot %coordinates if((robot1(1,1) == -1)||(robot1(1,2) == -1)||
(robot1d(1,1) == -1)||(robot1d(1,2)==-1)) stopMotors(); elseif((robot2(1,1) == -1)||(robot2(1,2) == -1)||
(robot2d(1,1) == -1)||(robot2d(1,2)==-1)) stopMotors(); %elseif((robot3(1,1) == -1)||(robot3(1,2) == -1)||
(robot3d(1,1) == -1)||(robot3d(1,2)==-1)) %stopMotors(); else %Get individual coordinates bx = ball(1,1); by = ball(1,2); r1x = robot1(1,1); r1dx = robot1d(1,1); r1y = robot1(1,2); r1dy = robot1d(1,2); r2x = robot2(1,1); r2dx = robot2d(1,1); r2y = robot2(1,2); r2dy = robot2d(1,2); %r3x = robot3(1,1); r3dx = robot3d(1,1); %r3y = robot3(1,2); r3dy = robot3d(1,2) %Determine distance between ball & robots centroid d1 = sqrt((bx-r1x)^2 + (by-r1y)^2); d2 = sqrt((bx-r2x)^2 + (by-r2y)^2); %d3 = sqrt((bx-r3x)^2 + (by-r3y)^2); d = [d1 d2]; %Determine distance between ball and robots origin marker d1o = sqrt((bx-r1dx)^2 + (by-r1dy)^2); d2o = sqrt((bx-r1dx)^2 + (by-r1dy)^2); %d3o = sqrt((bx-r2dx)^2 + (by-r1dy)^2); do = [d1o d2o]; disp(d1); disp(d2); %determine which robot is closest to the ball if(d1 < d2)
109
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)
110
%Increase possession constraint %Retrieve data data = robotFinal(); %Initialise Robot Coordinates %roboti holds the coordinates of robot i's centroid %robotid holds the coordinates of robot i's orientation marker ball = data(1, :); robot1 = data(2, :); robot1d = data(3, :); robot2 = data(4, :); robot2d = data(5, :); %robot3 = data(6, :); %robot3d = data(7,:); %Vectors to hold robot data robots = [robot1; robot2]; robotsd = [robot1d; robot2d]; %Only execute code if all markers have been captured if((robot1(1,1) == -1)||(robot1(1,2) == -1)||
(robot1d(1,1) == -1)||(robot1d(1,2)==-1)) stopMotors(); elseif((robot2(1,1) == -1)||(robot2(1,2) == -1)||
(robot2d(1,1) == -1)||(robot2d(1,2)==-1)) stopMotors(); %elseif((robot3(1,1) == -1)||(robot3(1,2) == -1)||
(robot3d(1,1) == -1)||(robot3d(1,2)==-1)) %stopMotors(); else %Get individual coordinates bx = ball(1,1); by = ball(1,2); r1x = robot1(1,1); r1dx = robot1d(1,1); r1y = robot1(1,2); r1dy = robot1d(1,2); r2x = robot2(1,1); r2dx = robot2d(1,1); r2y = robot2(1,2); r2dy = robot2d(1,2); %r3x = robot3(1,1); r3dx = robot3d(1,1); %r3y = robot3(1,2); r3dy = robot3d(1,2); %determine distance between robot and ball d1 = sqrt((bx-r1dx)^2 + (by-r1dy)^2); d2 = sqrt((bx-r2x)^2 + (by-r2y)^2); %d3 = sqrt((bx-r3x)^2 + (by-r3y)^2); d = [d1 d2]; %Determine distance between ball and robots origin marker d1o = sqrt((bx-r1dx)^2 + (by-r1dy)^2); d2o = sqrt((bx-r1dx)^2 + (by-r1dy)^2); %d3o = sqrt((bx-r2dx)^2 + (by-r1dy)^2); do = [d1o d2o]; %determine which robot is closest to the ball if(d1 < d2) i=1;
111
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);
112
%pause(2); else gotBall = 0; disp('I have lost the ball :('); end; end; stopMotors(); end; end; stopMotors(); ballShot = 0; pause(5); %Do a celebratory dance centre = [470, 480]; [dist ang] = goToHere(centre, robot1, robot1d); arc = ROBOT_WIDTH*abs(ang); T = arc/SPEED_AT_20; if(ang > 0) setMotors(-20, 20); pause(T); stopMotors(); else setMotors(20, -20); pause(T); stopMotors(); end; setMotors(20, 20); T = dist/SPEED_AT_20; pause(T); stopMotors(); for i=1:5 setMotors(-30, 30); pause(3); setMotors(30, -30); pause(3); end; stopMotors(); end;
113
Appendix F.2 Function goToHere
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % Function to make robot move to coordinates supplied as parameters % Michael Shanahan 1078748 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 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 [dist, theta] = goToHere(destination, centroid, orientation) % @param destination: coordinates of the point where the robot must go % @param centroid: coordinates of the robot's centroid % @param orientation: coordinates of the robot's direction marker %Retrieve coordinates only if vectors supplied are of length 2 if((length(destination)==2)&&(length(centroid)==2)&&(length(orientation)==2)) xdest = destination(1,1); ydest = destination(1,2); rcx = centroid(1,1); rcy = centroid(1,2); rdx = orientation(1,1); rdy = orientation(1,2); %Vector from robot centroid to orientation coordinates V1 = [(rdx-rcx);(rdy-rcy)] %Vector from robot centroid to destination coordinates V2 = [(xdest-rcx);(ydest-rcy)] %Angle between these vectors theta = acos(dot(V1, V2)/(norm(V1)*norm(V2))); %Distance robot has to travel dist = norm(V2); %Determine which direction to turn robot Vperp = [V1(2,1), -1*V1(1,1)]; prod = dot(V2, Vperp); if(prod < 0) theta = -1*theta; end; else disp('Invalid Coordinates supplied'); end;
114
Appendix F.3 Telegram editing functions
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;
115
Appendix G Communications System Block Diagrams
Appendix G.1 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.
Figure G.1: Transmitter model
116
Appendix G.2 Receiver model
The receiver model, shown in figure G.2 on the next page receives the telegram from the
transmitter model via the ‘FreePortComms_RX’ block. The channel number of the
telegram is checked to determine if the receiving robot is indeed the intended target. This
is accomplished using the blocks shown in figure 6.3. The checksum of the telegram is
also verified via the subsystem labeled ‘calculate checksum’, shown in figure 6.4. If both
tests are passed, the motor and solenoid instructions are retrieved from the telegram by
the block labeled ‘retrieve instructions’. The block labeled ‘motor power control’ tests if
both motor pulses are zero, and if they are cuts power to the motors to preserve the
batteries. This is shown in figure 6.5. Otherwise, the motor instructions are used to
generate a square wave via the ‘variable frequency square wave’ block shown in figure
6.6. The resulting speed and direction pulses are then sent to the appropriate
microcontroller pins via the pin access ports. The solenoid instruction is relayed in the
same manner.
117
Figure G.2: Receiver model for robot 0
118