There were two versions of the soccer playing robot, version 1.0 and
version 2.0. From what our group understood from the project, since version
2.0 is an advanced and enhanced model of version 1.0 we tried to focus more
on building and developing version 2.0.

There were some issue to be considered and those were mainly about the
design to have the reasonable speed, lest friction, and easy accessibility
to the robot.

     For the basic programming of the robot we tried to first define the
major function that is had to perform. Firs thing was to determine which
type of system had to be used (e.g. close or open loop systems). It was
clear the "open loop" system would not work for our purposes and the reason
for that was because mainly the robot was designed to perform the task by
judging and choosing the task in advance. For "open loop' systems there
should be an initial input and then it will be a certain fixed procedure to
be followed regardless of the output. Basically the output will not have
any effects on correction of the procedure for more desired output. We can
say that 'open loop" system could be used for version 1.0 since the input
remains constant and the output is only one procedure (speed and the
direction of movement of the ball are fixed and constant). For version 1.0
we could program the robot in a way that as soon as it received the
information from the sensors which detect the movement of the ball, turns
on the motor and runs it for certain time and distance so that the ball
would hit the ball and go into the goal. However, for version 2.0 it would
not be possible to follow such a procedure since the time and speed of the
ball varies. To solve the problem for the new version 2.0 we used "close
loop' system which would follow "feed forward" task. The reason that we did
not use a "close loop" system, which would follow the "positive/negative
feed back ", was because we did not want to correct the function after the
output has been produced but more we want it to prevent the wrong output by
prejudging.


     We were aware of the derails, which were a bit more complicated and
advanced than what we would have to make for version 1.0, in both the
software and the hardware section of the project. Since we did not actually
intended to build version 1.0 and started with the advanced model, we did
not have to adjust the robot's structure and body to be able to perform the
task of kicking the ball at different speed. We focused on the best and
most efficient design for the robot, which would serve both for version
1.0, and version 2.0 purposes and we could get the maximum output from it.

 The major inputs for the robot would be from touch and light sensors
that we installed on the pathway, which was designed for the ball to
be released from. The sensors would feel the movement of the ball and
then information would be sent to the RCX, which was programmed to
react to different information coming in as inputs. RCX was connected
to the robot via set of wires and it was not designed to be on the
robot for couple of reasons. First to let us to be able to access it
easily for reprogramming, and secondly for the robot to have less
weight to carry with it. If the robot would carry less weight then it
would be an advantage for it because it could move faster and the
speed could be adjusted much more easily since there would be less
friction produced. Moreover, not having the RCX on the robot would
allow us to be able to use more space for the wheels, and also for the
motors and gears.  Then we would not have to face the problem of
having the plane surface of RCX which would limit us from having big
wheels or large gears and having the motors to be arranged in and way
desired.


     In the early stages of development of our Soccerbot, we experimented
with many design ideas. Through much collaboration between all members of
our group, we all unanimously decided to have a robot with an external RCX.
We decided on an external RCX design mainly for two reasons. Firstly, by
having the RCX external, we would eliminate all difficulties with respect
to changing the batteries by maintaining easy access to the battery access.
In previous demos of the Lego Mindstorms system, our group ran into the
problem of having our batteries run out in the middle of the demonstration.
In order to change the batteries, we had to spend costly time in
dismantling our robot to gain access to the battery panel on the internal
RCX and then reassemble the robot again to continue with the exercise.


----- UNUSED LINE --------

 We can
say that 'open loop" system could be used for version 1.0 since the input
remains constant and the output is only one procedure (speed and the
direction of movement of the ball are fixed and constant). For version 1.0
we could program the robot in a way that as soon as it received the
information from the sensors which detect the movement of the ball, turns
on the motor and runs it for certain time and distance so that the ball
would hit the ball and go into the goal. However, for version 2.0 it would
not be possible to follow such a procedure since the time and speed of the
ball varies. To solve the problem for the new version 2.0 we used "close
loop' system which would follow "feed forward" task. The reason that we did
not use a "close loop" system, which would follow the "positive/negative
feed back ", was because we did not want to correct the function after the
output has been produced but more we want it to prevent the wrong output by
prejudging.


DESIGN
     The soccerbot can be defied as a man made robot, which is able to
thinks towards solving a specific problem and executing a certain function
by comparing the input with all the stored data each of which is related to
a certain function.

DESIGN
DESIGN
     In order to produce the 'close loop,' with "feed forward" function in
our robot we used the MindstormŽ software to programs the RCX using the
"check & choose" commands which in the programming language does the same
function as "If-Then" commands.

DESIGN
     We added some certain steps to the program where it allowed the robot
to be able to received the information and then compare the input to what
it has been programmed to decide when it finds that certain kind of
information. So we added some certain "chained" commands where at each step
it would check the information and if was the same as it was programmed to
do then it would perform the specific give task to that step.

DESIGN
That means it would start to move forward after certain amount of "wait
time" to the certain number of "rotation" of the wheel.

DESIGN
So far we were able to use the "feed forward" concept, which basically
means that the robot would have a chance to receive information and have
time to decide its action before it is required to execute that action.


     This kind of programming would allow the robot to prevent making
mistakes where in the other systems (e.g. feedback, etc.) that is not the
case and they are more designed to be able to correct the function after
the output has been produced.

HARDWARE

**Picture of Soccerbot from underside showing tricycle design**

**Show Ramp Design-smooth side up!**

 

**Picture of Entire System-RCX is hub**

Aside, the ideal orientation for the Soccerbot on the playing field is as
depicted below:

**Picture of Soccerbot...30cm X 30cm X 30cm**