Goalkeeper

Robot

Prof. B. Vassilicos

Mei Lang Xiong

Elnaz Ghavanlou (EE3 class only)

Birat Khadka (Scientific Writing class only)

Pawan Adhikari

Taran Chhantyal

Sudip Khadka

Ponnapat Watjanatepin

2nd BAC. Group 223E





December 13, 2013

Team: Syntax Error | Table of Content 2



Table of Content

TABLE OF CONTENT I

LIST OF ILLUSTRATIONS II

ABSTRACT III

INTRODUCTION 1

1 MATERIALS AND METHODS 3

1.1 MECHANICAL ASPECTS 4
1.2 ELECTRONIC ASPECTS 6
1.3 LABVIEW ASPECTS 9

2 RESULTS 11
2.1 MECHANICAL IMPLEMENTATION 11
2.1.1 PERFORMANCE OF THE DESIGN 11
2.1.1.1 Theoretical Design 11
2.1.1.2 Actual Performance 11
2.1.2 PROBLEMS ENCOUNTERED AND SOLUTIONS TAKEN 12
2.2 ELECTRONIC IMPLEMENTATION 13
2.2.1 PERFORMANCE OF THE ELECTRONICS ASPECTS 13
2.2.1.1 Theoretical Design 13
2.2.1.2 Actual Performance 13
2.2.2 PROBLEMS ENCOUNTERED AND SOLUTIONS TAKEN 13
2.2.2.1 Problems Encountered 13
2.2.2.2 Solutions Taken 14
2.3 LABVIEW IMPLEMENTATION 15
2.3.1 PERFORMANCE OF THE LAB VIEW PROGRAMME 15
2.3.1.1 Theoretical Design 15
2.3.1.2 Actual Performance 15
2.3.2 PROBLEMS ENCOUNTERED AND SOLUTIONS TAKEN 15
2.3.2.1 Problems Encountered 15
2.3.2.2 Solutions Taken 16
2.4 FINANCIAL IMPLEMENTATION 17
2.4.1 COST CALCULATION 17
2.4.2 ANALYSIS OF THE COSTS 18

DISCUSSION 19

REFERENCE LIST 20

i EE3: Goalkeeper robot | Team: Syntax Error

List of illustrations


Figure 1: Shooter

Figure 2: Goalkeeper Hand

Figure 3: Circuit 1

Figure 4: Circuit 2

Figure 5: FSM

Table 1: Research and Engineering Team Cost

Table 2: Manufacturing Process Cost

Team: Syntax Error | List of illustrations ii



Abstract

Football is of course one of the most well-known sports in the world that is worth billions of
Euros. Due to the fact that every national team is aiming to be number one on the world ranking,
each country has to train its player such that they can compete and win as many matches as possible.
However, the main key to success relies heavily on the training of the team members. Therefore, the
team of authors would like to introduce the Goalkeeper Robot as one of the methods that could be
implemented to train players. Moreover, accompanying this goalkeeper robot is a shooter robot so
that a clear demonstration can be made. The two robots have been constructed using Fischertechnik
pieces as the main mechanical components, the sensors as the main link in the electronic
components and the Lab View programme as the programming medium. In the end, the two robots
are able to communicate together perfectly, however, with a few delays, but the desired features
that were intended are still achieved.

iii EE3: Goalkeeper robot | Team: Syntax Error

Introduction

Sports are one of the most common forms of leisure one could find. In addition to that,
sports industry is valued at billions of Euros. One of most played sports is undoubtedly football.
Football is one of the worlds most famous sports that is known and played by millions around the
world. It can be said that football has an immense effect in regards to the worlds society. One need
not to be reminded that the winner of the FIFA World Cup would be remembered by millions for
years to come and is, for many people, become a common knowledge like knowing the conversion
between kilograms to pounds. Consequently, it is no surprise that many countries have a common
goal of becoming the worlds best team and each country spend a significant amount of money to
aim for that success.

Of course one of the key factors that contribute to the success in football is practice. Because
a team is as good as its weakest player, each player should take his or her time to improve his or her
abilities to the highest level. This means that a lot of time would have to be spent on the whole team.
With that being said, we decided to introduce our prototype of the goalkeeper robot. For instance,
players who are weak in doing free-kicks, penalty kicks, corner-kicks or any other set-piece tactics
could use this goalkeeper to be his or her personal trainer. Therefore, the teams training would
achieve much more in the same period of time than a team that uses every single player for one type
of practice. Since in football each player has a position that is unique in function than others, it
means that each position will have some special focus that is needed to be practiced individually.
With our goalkeeper robot, one can assign strikers to train penalty kicks, and wingers and attacking
mid-fielders to train the free-kicks and corner kicks thus increasing the teams efficiency.

The goalkeeper robot must be able to track the ball and rotate accordingly to save the ball.
The trajectory of the ball is tracked by two sensors, which send information to the main programme
(sub VI in Lab View). The program calculates the speed and position of the ball and predicts the angle
through which the robot (keeper) has to turn. Provided a very precise tracking system, the robot
presents a very little space for the player to score. The goalkeeper robot must be able to perform as
close to a real goalkeeper as possible therefore the response time must be within the desired
timeframe. For this project, we have also introduced a user-controlled shooter, as a substitute of a
real player, to strike the ball. For the sake of our demonstration, the user can control the trajectory
of the shooter via the user-interface on our Lab View programme that will in turn send commands to
the shooter itself.

With this prototype further researched and enlarged, they can be implemented into the
sports industry. A football team might use one robot per player and let each player works on his or
her own flaws one-on-one so as to improve the performance of the whole team. In addition to that,
further research can be made into this robot so as to increase the possible field of application. For
instance, researchers can make use of the tracking system (via motion or colour) and apply it to help
catch people in a burning building (for emergency response team application) or even use it to catch
people in construction accident (for construction safety).

With these possible applications in mind, many benefits can be received from the use of this
technology either directly from using the robots or by indirect process of further research to make
use of the existing systems by improving its performance to have a desired effect. In conclusion, the
process of the makings of our prototype is recorded within this report. The three main aspects:
mechanical, electronics and Lab View will give the reader a general idea of the procedures being
done to obtain the prototype. The results and discussion will further explore the problems
encountered and the solution taken to solve those problems.

Team: Syntax Error | Introduction 2



1 Materials and methods

In this Engineering Experience 3: Computer-based Control project, our team takes on the
challenge of building a robot. The robot we are designing works on the principle of a finite state
machine. According to Jan Daciuk (1998), the principle of finite state machine or finite state
automata is as follows A finite-state automaton is a device that can be in one of a finite number
of states. In certain conditions, it can switch to another state. This is called a transition. When the
automaton starts working (when it is switched on), it can be in one of its initial state.

The mechanical, electronical and Lab View components function together to bring the
goalkeeper robot into action; in short: the mechanical part of the robot is the moving parts, the
electronics part serve as the medium of connection between the two parts (mechanical and Lab
View) and the Lab View part serve as the brain of our robot. Failure in one of these aspects leads
to failure of the robot itself.

Every components of the robot is controlled by the Lab View program. The program
calculates the position and velocity of the ball and predicts where the ball will pass based on the
choice of the user. The keeper receives a signal from the program and rotates accordingly.

The mechanical components of the robot mainly include the Fishchertechnik blocks and
motors. These blocks are assembled together to give different structures (say keeper and shooter),
which are rotated or moved by the motors. These motors are connected to PCB, an electronic
component, through which they receive a necessary signal and power.

The National Instrument Data Acquisition box (DAQ) and the Printed Circuit Board (PCB) are
the most essential electronic components for the robot. The DAQ is able to send and receive the
signals to and from the computer. The PCB, connected to DAQ, has different ports for mechanical
components like motors, switch, etc. Therefore, in general, the electronic components serve as a
medium of communication between the computer program and the mechanical components.

Once the ball is shot, 2 sensors (electronic components) track the trajectory of the ball and
send a signal to the Lab View program, which calculates the velocity and the position of the ball. The
program sends a reaction signal to the keeper via DAQ and PCB and it reacts as per the signal.

When the ball has been stopped, the robot returns to its initial starting condition as assigned
via the finite state machine schema.

3 EE3: Goalkeeper robot | Team: Syntax Error

1.1 MECHANICAL ASPECTS

The Goalkeeper Robot has two main structures: the keeper and the shooter. The keeper part is
our main focus of this robot. This part includes the mechanical keeper hand, the camera sensor and
also the tracking-system programme written in Lab View. The second part is the shooter. The shooter
is made for the sake of our demonstration. The robot that we make is small-scaled therefore it needs
a specific shooter that is able to deliver the required kick.

The Fischertechnik blocks (of different types) are the basic building stones of our robot. The
blocks are assembled together to provide mechanical structures to each mechanical components of
our robots. These components are moved by the help of motors, which are controlled by the
program (Lab View).

The shooter is constructed using mostly parts from the Fischertechnik. However, due to
additional requirements for our prototype, we also used some of our own materials. The additional
materials we used were a plastic pipe and a rubber wheel obtained from a toy car. The rubber wheel
is connected with the motor so that it can provide us with the kick. We also cover another rubber
layer for the wheel so that there is even more traction for the kick. The motor-wheel connection is
mounted on the Fischertechnik models that we had built in the initial phase. There are in total three
motors implemented to the shooter. Two are used for direction (right-left and up-down) and one is
used to deliver the kick. The shooter model rests above two turn plates, which are placed
perpendicular to one another. Two turn plates mean two motors are used to rotate them. These two
turn plates allow the shooter to turn into any direction. Another minor detail, we also connected two
metallic rods so that the balls trajectory is controlled.

The keeper also comprises mostly of the Fischertechnik parts. The keeper is constructed with a
turn plate and a supporting block that acts like an arm for the keeper. The turn plate gives necessary
rotation to the keeper by means of a motor (9 V). The motor is only activated after it gets a signal
from the program. The video camera is installed perpendicular to the keeper hand so that it could
track the movement with a wide-panoramic view. Here, only one motor is connected to this part.
This motor is then connected to the PCB such that the polarity of the motor is reversible through the
use of Lab View programme. We also connected gears to one of the turn plate so that it is possible
for the keeper to be able to freeze mid-air even when there is no power applied thus creating a
special feature. One turn plate is also used for the keeper so that it can turn 180 degrees. The
goalpost was constructed behind the goalkeeper and there will be a camera attached to the bar so
that it can track the movement of the ball.

Both components will be constructed in a box-like structure. The reason we need such a
structure is so that the definite distance between the two robots (goalkeeper and striker) is defined
and the specific point of the camera can be mounted. The box is constructed from five pieces off
MDF wood that are 60 till 30 mm long and 4 mm thick. The box will then also be coloured and
personalised into such a way that it maximise the use of our sensors and also provide the most
realistic condition as much as possible. The box is then covered with a black paper so that our
background is black as we want.

Team: Syntax Error | Materials and methods 4



In total, we used four motors. Each of these motors is connected to the PCB, which in turn is
connected to a DAQ. The DAQ and PCB allow communication between the computer program and
these motors. Hence, we are able to control the actions of the robot (or motors) by the computer
program.

Figure 1: Shooter

Figure 2: Goalkeeper Hand

5 EE3: Goalkeeper robot | Team: Syntax Error

1.2 ELECTRONIC ASPECTS

It can be said that the electronic aspects is the medium that connects the two parts of our
project, the mechanical part and the Lab View part together. The rough overview of our design is as
follows: the ball would be detected via the sensors or cameras. The signal would be sent to the Lab
View programme. The programme carries out its instructions and controls the mechanical part of our
project, the goalkeeper robot. Therefore, it can be concluded that we rely heavily on the concept of
data acquisition. In short, data acquisition is the process, in which the real-world data, such as
temperature, motion or pressure, is communicated to the computer via various components such as
the transducer, printed circuit board (PCB) and the DAQ box (containing analogue to digital
converter).

In the early phase of our project, the electronic aspect was also one of the topics that were
researched. Some articles we found have pointed us into the direction we took today. In accordance
with Vicenzo, Multiple cameras are used to determine the position and velocity of the ball in space.
To track the ball more precisely, multiple cameras with high frame rate are preferred. Using just a
single camera with the same rate also works but the information sent from it is 2D. With multiple
cameras the 2D information from each camera is computed to make it 3D. This makes our prediction
more accurate (Vicenzo et al, 2013). Another article that provided us a bigger picture of our possible
prototype is in reference to Jamzad Basically the goalkeeper is equipped with three cameras, two
rears and one at the front. When the ball is at the front position, the front camera comes in use for
the detection of the position of the ball. However, when it moves farther away, either left or right,
then the two rear cameras calculates the position (L or R). At any positions if the distance detected
seems to be the minimum one, the robot hits the ball with its slidinghand% (Fuady et al, 2010)

In the electronic aspects of our project, our goal was to conform to the model requirements
of the Engineering Experience 3 document that was posted on TOLEDO. We have, in total, 12 digital
inputs/outputs, 8 analogue inputs and 2 analogue outputs on our DAQ box interface. The DAQ box
we used was National Instruments USB-6008. The function of the DAQ box is to communicate
between the digital and the analogue world. Another important electronic component in our project
is the printed circuit board or PCB. The function of PCB is to perform signal conditioning so that the
prototype can perform normally.

One of the key electronic components that we need for our robot to receive real-world data
is the transducers. One of the most important electronic components used in our project is
transducers or sensors. From Hans-Petter Halvorsens Data Acquisition in Lab View, one can
conclude that the role of sensors in our prototype is as follows: the sensor would capture the
physical quantities in the real world such as temperature, light intensity or pressure, and convert
them into definite electrical quantities like voltage or current (H. Halvorsen, 2013). We receive our
sensors and cameras from Group T, namely from module 10.

The first implementation we made was with a video camera but due to the concurrency
problems arising during the tests, we decide to shift the approach and use infrared distance sensors
instead. For more details of this problem and solutions we took to achieve our robot, please refer to
our results section.

Team: Syntax Error | Materials and methods 6



The two types of sensors that we used are NPN-Silicon Phototransistor model SFH 309 FA
and GaAIAs Infrared Emitter (880 nm) model SFH 487. The amount of resistance for each circuit has
been determined by us. The calculations are as follows below.

Two distance sensors were used and each distance sensor consists of 1 IR-Phototransistor
and 1 IR-Emitter. We used therefore 2 different types of each. For the first distance sensor (Figure 3:
Circuit 1), we used an IR-Phototransistor SFH-309fa (black) and the IR-Emitter SFH-487 (white).
Therefore the following circuit was built.

Figure 3: Circuit 1

For the emitter SFH-487, it was given Vf = 1.5 V and Imax = 100 mA. This means that:

5 1,5
= /01
,

, = 35

In order that Imax is not higher than 100 mA, we took as resistor 1 = 68 .

The voltage of the phototransistor SFH-309fa is the voltage that is measured when an object
is coming into contact. Out the information of the data sheet of the transistor, it states that if the
input voltage is 5V combined with a resistor of 1 k, we would get a current change of 1 mA. We
took a resistor 6.8 k so that the change in voltage more noticeable because = . From V = IR, if
we want to really see a change in the current, we will have to take a higher value of resistance to
achieve the same number of voltage.

7 EE3: Goalkeeper robot | Team: Syntax Error

 For the second distance sensor (Figure 4: Circuit 2), we used 1 transistor TEFT-4300 and an
emitter TSAL-7400.

Figure 4: Circuit 2

For the emitter, TSAL-7400, it was given that Vf = 1.35 V and Imax = 100 mA.

5 1,35
, = = 36,5
0.1

For the transistor, we also took the same amount of resistance which is 6.8 k for the same
reason as in the first case.

The first distance sensor can be recognised with the blue, green and yellow wires. The
second sensor is recognised with the colours: orange, red and brown. The first sensor is implemented
at the shooters launch pad. The purpose of this installation is so that the sensor can detect whether
the ball has left the shooter or not. Once this sensor is triggered, the Lab View programme will read
the signals and relay it to the goalkeeper hand.

The second sensor is implemented on the goal post behind the goalkeeper hand. The reason
for implementation is so that the user and Lab View programme can know the initial position of the
goalkeeper hand at all times.

Now that the electronic parts are implemented, the mechanical part can now communicate
with the users and/or the computer via the PCB and DAQ box.

Team: Syntax Error | Materials and methods 8



1.3 LABVIEW ASPECTS

The Lab View programme is, generally speaking, the brain of our goalkeeper robot.

During the brainstorming period, prior to the execution part, we came up with our
goalkeeper robots Finite State Machine (FSM). In our FSM, we have five states, 6 outputs and 5
inputs. The brief explanation and overview of the FSM diagram has been included below. (Figure 5:
FSM)

Components

Figure 5: FSM

Legend

a) Motor 1: motor with wheel

b) Motor 2: motor horizontal movement (shooter)

c) Motor 3: motor vertical movement (shooter)

d) Motor 4: motor attached with goalkeeper

e) Sensor 1: IR Sensor (shooter)

f) Sensor 2: IR Sensor(Goalpost)

9 EE3: Goalkeeper robot | Team: Syntax Error

 In the early stage of our prototype development, we did some research on existing Lab View
implementation as well as existing methods and results on robot goalkeeper. Our main goal at that
time was to find the way to write a programme that will track the movement of the ball. According to
Jamzad The flow of the direction is predicted by comparing two coordinates of the ball; latest
coordinate with the previous one. As every coordinate can be located with two numbers (X-axis and
Y-axis), the program need to compare four numbers separately and according to the result it can
predict the direction of the ball (Stepney, 2013). This was the article that gave us an idea of how to
proceed and initiate our draft of the programme.

The programme used for this project is Lab View. This is by far the most time consuming part
of the three aspects. In general, the application of Lab View and our robot is so that the robot can be
monitored by the Lab View programme. The Lab View programme provides the user interface where
a person could monitor and see how the robot is working.

The Lab View programme that was used is from the 2013 version. From our research, we also
found some extensions that could be implemented in our design criteria. The Lab View extension we
used was NI-IMAQ 4.6.4 for Windows and Vision and Motion Extension Module 2013. The reason we
chose to work also with these Lab View extensions is because it contains more functions that can be
easily implemented without starting from scratch. Such modules are the Vision Acquisition and
Vision Assistant. With these two modules, the connection between our sensors and cameras to the
computer has been greatly simplified.

The programme that we made with Lab View contains two main components. The first part is the
counter part and the second part is the execution part. The counter keeps track of the number
of clicks for the duration of the project. The execution part is the part that control whether the
goalkeeper is moving left (2) or right (1). The execution part was derived the main driver from that
was available on TOLEDO. The two parts work together simultaneously as follows: the counter
indicates the number of clicks for the executor and vice versa.

Vision and Motion Extension that was installed is then connected with the sensors we have
from module 10. The sensors are able to track the movement of the ball when the ball is launched.
The sensors, when sensed the position of the ball, will then send the appropriate response to move
the mechanical part of the goalkeeper so that it can prevent the ball from going into the goal.

Team: Syntax Error | Materials and methods 10



2 Results

In this section, the performance of the design, both theoretical and the actual is being
compared. Then the problems we encountered during the project will be addressed alongside the
possible solutions and the solution we actually implemented. All the three main aspects from the
previous section will be discussed. In addition to that, the financial implementation will be calculated
and showed as well. The financial implementation will include the total cost of the production as well
the possible analysis of the cost of the product.

2.1 MECHANICAL IMPLEMENTATION

The mechanical implementation includes the goalkeeper and the striker. In addition to this,
the other physical structures like the field and the goalpost is also included in the mechanical
implementation.

2.1.1 Performance of the Design

2.1.1.1 Theoretical Design

Two mechanical implementations have been built. The first part is the striker. The job of the
striker is to shoot the ball into the target as accurate as possible. The striker is controlled by the user.
The user could adjust the aiming of the striker in a way that he or she prefers. Then the user could
shoot out the ball by using the controls that was written on our Lab View programme. The striker
was made for the sake of our demonstration.

The second part is the goalkeeper. For this, we want the goalkeeper to be able to stop all the
balls coming its way. Once the ball is launched from the striker, the sensors on the football pitch will
keep track of the possible trajectory and will make the goalkeeper hand move in such a way that the
ball could be stopped. The goalkeeper hand should have as little a delay as possible.

2.1.1.2 Actual Performance

The mechanical aspects we achieved are as what we had planned. In general, the shooter is
able to turn (horizontally and vertically) on all direction. The motor that create the kick for the striker
is also strong enough to launch the ball but also not too hard so as to mess up our design. The
goalkeeper hand itself is also able to move 180 degrees in any direction to defend the goal post. The
keeper is also able to follow the movement of the shooter so that the goalkeeper hand as a very fast
reaction time.

11 EE3: Goalkeeper robot | Team: Syntax Error

2.1.2 Problems Encountered and Solutions Taken

The design of the robot, both the goalkeeper and the shooter, has been transformed couple
of times during the whole building process according to different problems encountered. Every
problem was solved keeping in mind that solution for one might be the problem for the other.
Therefore, the main objective during this process was to find a common ground for both the
goalkeeper and the shooter.

Problems and Solutions: Goalkeeper

Mechanically, there were very less problems with the robot primarily because the structure is
built in a very simple manner as discussed in the mechanical aspects. The main problem encountered
with the keeper was its precision. Since the keeper had to stop at different angles, a mechanism to
know the angle it has rotated through was necessary. For this purpose, we used a counter (switch),
just behind the goalkeeper, in front of the motor. For every 1 count from the counter, the motor
rotated the goalkeeper arm through certain angle. In that way, the goalkeeper was calibrated, and
was found that it only needed to be in 12 different positions to turn around 180.

Problems and Solutions: Shooter

The main problem with the shooter was the way how to kick the ball. Two different ideas
were tried and tested before we finalized one. The two ideas were kicking the ball with a foot like
structure and using a motor-rotated wheel to kick the ball. The former one couldnt shoot the ball
fast enough, so we stick with the later one, which provided enough speed that could also be tracked
by the cameras.

Distance between the goalkeeper and shooter was also one of the problems. When the
distance was too close, the camera didnt get enough time to track, and when far, the ball did not
reach the goalpost. Different distances were tested for this. Finally, 60 cm distance was the best,
when the camera could track and the motor could provide enough speed.

The above discussed problems are the major ones. Time and again, there were problems
concerning the stability and positioning of both the goalkeeper and the shooter. So every now and
then, different Fischertechnik blocks were added and replaced to make the goalkeeper and the
shooter more stable. Tackling these obstacles has given a new and different design for the robot.
These encountered problems have led to better construction, stability and positioning of the robot
itself.

Team: Syntax Error | Results 12



2.2 ELECTRONIC IMPLEMENTATION

The electronic implementation includes the sensors, the PCB components as well as the DAQ
box.

2.2.1 Performance of the Electronics Aspects

2.2.1.1 Theoretical Design

In theory, we want to design the perfect data acquisition system so that the communication
between the mechanical aspects (the robots) and the Lab View programme is with the least delay
possible. The sensors should be able to recognise the ball fast enough that the ball could be stopped.
The approach taken in this robot is that infrared distance sensors are implemented on the football
pitch so that the balls motion could be detected once it has been launched from the striker.

2.2.1.2 Actual Performance

The actual performance of the electronic aspect was as expected. The sensors that were
installed on both places were able to detect the ball when launched and send the response to the
goalkeeper hand within the appropriate time. The keeper hand is now able to defend the goal within
the specified time limit.

2.2.2 Problems Encountered and Solutions Taken

2.2.2.1 Problems Encountered

The problem with the electronic implementation is mainly with the sensors. During our
discussion, we came up with a design to implement the video camera as our main tracking device.
The video camera is installed adjacent to the goalkeeper hand, namely perpendicular to the hand so
as to provide our system with a clear panoramic view of the balls motion. The other end is then
connected to Lab View via Vision and Motion Extension. The camera works by tracking the orange
colour of the ping pong ball we used for the trials. When we performed tests on the tracking
capability of the camera, the outcome was perfect.

However, the problem of concurrency arises when we connect every components of our
robots together (mechanical, electronics and Lab View). The video camera also keeps track of other
orange-coloured objects in the environment. Therefore, huge amount of data is then relayed to the
computer and this takes too much space on the computer. Consequently, the response time of the
goalkeeper hand is too long. The camera and the Lab View programme cannot communicate within
the desired timeframe thus, compromising the robots ability to defend the goal.

13 EE3: Goalkeeper robot | Team: Syntax Error

2.2.2.2 Solutions Taken

The delay caused by the camera from our previous trials was solved. Now the response time
from the goal keeper hand is reduced to a very fast reaction. The solution we took was to change
from using the camera to distance sensors. Two distance sensors were implemented. One is
implemented at the launch pad of the shooter and the other is at the centre of the goalpost behind
the goalkeeper robot. The first sensors job is to detect whether a ball has been launched. After the
ball has been launched, the sensor is triggered and a signal is sent to alert the Lab View programme.
The other sensors function is to detect the position of the goalkeeper hand. It will let the Lab View
programme knows the actual position so that calculations of response can be made. After this has
been implemented, the response time is much faster and the ability to catch the ball for the robot is
accomplished.

Team: Syntax Error | Results 14



2.3 LABVIEW IMPLEMENTATION

The Lab View implementation includes all the Lab View components and its subsequent
programmes. The Lab View programme that we designed also includes some derivatives from the
template available on TOLEDO as well as some other National Instruments extensions.

2.3.1 Performance of the Lab View Programme

2.3.1.1 Theoretical Design

In theory, we want our programme to be able to read the incoming signals from the camera
so that the Lab View programme can make calculations which in turn will generate a response to
activate the goalkeeper to keep the ball out of the goal as fast as possible. The programme, upon
receiving signals from the sensors implemented in the electronics aspect, should have as little delay
as possible so that the goalkeepers hand could have a very realistic reaction time.

2.3.1.2 Actual Performance

The Lab View programme performed much better after we have implemented the sensor
instead of the camera. However, there are still some issues with the performance. The accuracy of
the shooter is not as well as we would like it to be. Because of this problem, some shots were able to
surpass our goalkeeper. Nevertheless, the goalkeeper is able to defend the goal to an extent that we
are satisfied with.

The Lab View programme receives the signal from the sensors (electronic aspect) and then
calculates the appropriate response for the goalkeeper hand. After that, the goalkeeper hand is able
to move and catch the ball before it enters the goal.

2.3.2 Problems Encountered and Solutions Taken

2.3.2.1 Problems Encountered

The main problem that we have encountered during the implementation phase of the
goalkeeper robot is that the programme slowed down significantly when every components of the
robot is connected, namely when we connected the video camera with the Lab View programme, the
video camera has some delays when viewed from the Lab View programme. This means that the
robots are too slow to do the assigned task. The other problem we had was with the Lab View VIs of
the two robots. With two robots, we have two programmes and this make communication between
the two parts simultaneously a bit more difficult.

15 EE3: Goalkeeper robot | Team: Syntax Error

2.3.2.2 Solutions Taken

Now that the sensors had been established in place of the cameras, the response time is now
much faster. The sensors take up much less memory space in the computer because the sensor does
not try to detect everything like the camera therefore the computer can send back the response to
the goalkeepers hand in time. This means that the goalkeeper hand is able to perform the tasks that
want.

Team: Syntax Error | Results 16



2.4 FINANCIAL IMPLEMENTATION

The financial implementation mainly includes two parts. The first part is the cost calculation.
This part gives the general overview of the cost that would be required in order to make one
prototype. The second part is the cost analysis. The cost analysis is mainly materials that we have
seen from the Management II: Financial Management class. This section will give us a general idea of
what the price of the product might be if it enters the market.

2.4.1 Cost calculation

When performing the cost of calculation, we found out that it is more clear and easier to
understand to divide the calculation into two parts. The first part would be the cost that would be
required to come up with a prototype whereas the second part would be the actual manufacturing
process cost when this product is being introduced into the actual market.

Research and Engineering Team Cost: The research cost is calculated based on the amount of the
teams input and the hard work we made per hour. In real company, we would be representing a
team of engineers performing research and implementing the design. The cost is calculated for the
whole team, namely for 6 persons. This is the cost of the prototype to be introduced to the company
board. This cost is made in the assumption that the company has full-access of physical and
technological resources. In addition to that, these costs are only a rough estimate.

Table 1: Research and Engineering Team Cost

Components Quantity Price/ Unit Total price

FischerTechniek
* Motors 2 21.00 42.00
* Power motor 2 31.00 62.00
* Gearbox 1 4.50 4.50
* Switch 3 5.00 15.00
* base plate 3 3.00 9.00
DAQ Interface Model: USB-6008 1 150.00 150.00
Soldered PCB 1 40.00 40.00
Sensor
* Motion 1 15.00 15.00
* IR phototransistor 2 0.55 1.10
* Camera 2 / /
Labour 285 50.00 14 250.00
Sum 14 588.60

17 EE3: Goalkeeper robot | Team: Syntax Error

2.4.2 Analysis of the costs

Manufacturing Process Cost: The manufacturing costs are calculated based upon the actual
fabrication of the robot in an ideal factory. These costs are approximated by the single individual
worker that is responsible for the building of the product. This price is the whole-sale price that is
found on the market.

Table 2: Manufacturing Process Cost

Components Quantity Price/ Unit Total price

FischerTechniek
* Motors 2 21.00 42.00
* Power motor 2 31.00 62.00
* Gearbox 1 4.50 4.50
* Switch 3 5.00 15.00
* base plate 3 3.00 9.00
DAQ Interface Model: USB-6008 1 150.00 150.00
Soldered PCB 1 40.00 40.00
Sensor
* Motion 1 15.00 15.00
* IR phototransistor 2 0.55 1.10
Extras
* IR emitter 2 0.34 0.68
* wooden plank
4mmx30cmx60cm 1 1.50 1.50
* wooden plank
6mmx30cmx60cm 4 2.00 8.00
* Ping-Pong ball 1 0.90 0.90
* grass 1 12.95 12.95
Labour 2 10.00 20.00
Sum 382.63

Remark: the total amount of hours worked on the project is 285 hours. If we want to know the cost of this
labour, it is equal to 285*50 = 14 250. In the table we mentioned only 2 hour that cost 10/hour. This is
because we assume that our robot is made in mass production.

As you can see here above, these are the costs to make the robot. We add 10 % profit to the
sum and therefore should be the asking price of the robot is at 420.

The profit will even grow larger because of the mass production of the robot. The materials
cost will go down and our workers will get faster hence a larger profit margin. Because football is one
of the most well-known sports in the world and the industry is worth billions of Euros, this robot is
therefore not only technologically possible as we have demonstrated but also possible to
commercialise in the real world as well.

Team: Syntax Error | Results 18



Discussion

In conclusion, the goalkeeper robot that was made achieved the desired features of the
design criteria. The goalkeeper robot is able to track and defend the goal from the ball that is
launched from the shooter. However, there are still some minor problems that are related to our
robot. One of the problems is the inaccuracy of the Lab View programme which results in the
inaccuracy in the calibration between the goalkeeper hand and the striker. This in turn leads to some
misses on the goalkeeper part.

Upon looking further at the application prospective of the goalkeeper robots tracking
system, one can see that this study could lead to further applications in many fields including sports
industry, emergency rescue industry or even military industry. These goalkeeper robots could be
used for sports team once it is mass produced. The tracking system could be further implement to
help identify, locate and catch people from a burning building or provide safety response for
construction industry. Moreover, the tracking system could also be applied to military use like
making an improved anti-missile system.

This project has been a really unique and impressive learning experience for us. Every
members of our group has completed the first year in GroupT therefore it is quite clear for us to see
that all the subjects that we have done from the first year like Electronic Circuits, Computer
Systems and Electricity and Magnetism has provided us with some basic knowledge for the
brainstorming part of the project. The classes in the second year up to and including all the seminars
of EE3 provided us with the specific pointers that allow us to finalise the design and implement the
robots. The experience of working together as a time through lots of obstacles in mechanical,
electronics, programming and management aspects has given us some taste of what the career in
engineering is offering us in the future.

19 EE3: Goalkeeper robot | Team: Syntax Error

Reference List

Ahmad Fuady, Indra Adji Sulistijono, and One Setiaji. Flow Direction Prediction of The Ball Movement
for Humanoid Robot Soccer Goalkeeper

http://repo.eepisits.edu/1236/1/Flow_Direction_Prediction_of_Ball_Movement_for_Humanoid_Rob
ot_Soccer_Goalkeeper.pdf

Daciuk, J. (1998). Incremental Construction of Finite-State Automata and Transducers, and their Use
in the Natural Language Processing. Technical University of Gdask via

http://www.eti.pg.gda.pl/katedry/kiw/pracownicy/Jan.Daciuk/personal/thesis/node12.html

Halvorsen, H. (2013).Data Acquisition in LabView. Telemark University College. (pg. 10)

http://home.hit.no/~hansha/documents/labview/training/Data%20Acquisition%20in%20LabVIEW/D
ata%20Acquisition%20in%20LabVIEW.pdf

Hidetoshi S. (1998). General management topics: Problem solving

http://www.mediafrontier.com/Article/PS/PS.htm

Stepney S. (2003). Programming languages. University of York, UK

http://www-users.cs.york.ac.uk/susan/cyc/p/prog.htm

Vincenzo Lippiello, Fabio Ruggiero, Bruno Siciliano (2013).Robotics and Autonomous Systems 61 via

http://www.sciencedirect.com/science/article/pii/S0921889013001176

Team: Syntax Error | Reference List 20



Acknowledgements
Upon the sincere guidance of Prof. Wei Wei, we were able to accomplish our project
Goalkeeper Robot successfully in the targeted time frame. Thus, we would like express our deep
gratitude to her for the complete support towards our project. We would also like to extend our
great appreciation to Prof. Basil, Prof. Janssens, Prof. Gorik and some of our fellow students who
provided us their valuable suggestions and help while planning and development of our project.

Since this was our first genuine engineering project, we had to go through various expected
and unexpected challenges. But with a good teamwork and support from our teachers and
colleagues, we were finally able to engineer our proposed robot with a great success. For this reason,
we would also like to thank each and every person who had contributed with their smallest help
directly or indirectly in our project.

21 EE3: Goalkeeper robot | Team: Syntax Error