(see also this site)
Speed optimizations.
Since speed is very important in a game like soccer (both the robot and the
human version), we
have implemented the following features:
Bigger wheels. Since we used the Fisher-Technik motors, gears
and
framework, we were forced to attach the (smaller) Fisher-Technik wheels.
This is already a big disadvantage compared to the LEGO constructions,
because the LEGO wheels are much bigger. LEGO wheels are also wider,
so they have a better grip to the floor. Our solution is to combine the best of
both worlds: We removed the inner part of a big LEGO wheel and replaced
it with a small one from Fisher-Technik.
Small gearing. We used a minimal number of spars in our gearing
box,
resulting in a maximum speed. The disadvantage of this modification is that
the robot will have more difficulties to push the ball (or an adversary). This
didn’t result in any problems, however, since the ball proved to be light
enough to move around.
Small, compact robot. This modification is perhaps not so
important, but
a smaller design has a smaller weight, because fewer parts are used to
build the framework. The less a robot weighs, the less power it consumes
while driving around.
Size optimisations.
As mentioned in the previous part, one of our goals was to reduce the size of
our robot as
much as possible. While trying this, we had to cope with a lot of difficulties,
such as:
The SMBII board. The length (16 cm.) is the biggest problem.
The only
way to reduce the size of the robot, is to tilt the board a bit. The robot be-
comes higher, but this is not a problem because we place the batteries as
low as possible. This way, the robot remains pretty stable, but is reduced in
size.
Motors and gearing boxes. These two elements must be attached
to
each other. This becomes an even bigger problem if one bears in mind that
the castor wheel also needs to be attached behind this. The best solution
seemed to be placing the motor-gearing box part vertically under the SMBII
board. This didn’t add to the height of the robot, since there was enough
free space underneath the tilted SMBII board.
The stability of the robot.
The robot has to be able to make quick turns or to accelerate as fast as
possible. This
means that high, unbalanced designs are out of the question. Here are our
efforts to com-
ply with these demands:
Symmetric design. It is very easy to place the bulky parts
(wheels, mo-
tors, gearing boxes, SMBII board, …) symmetrically, so that turning left or
right will be pretty much the same.
Location of heavy parts and wheels. As explained before, the
height of
the robot could end up in a shaky robot when making quick turns. This
would certainly be the case if any heavy object (like the batteries) would be
placed on top of the robot. We placed the batteries as low as possible and
divided all the weight between the two wheels and the castor wheel.
The front.
The front of the robot is shaped to ‘capture’ the ball as easy as possible
without using real
grippers. The ball is ‘directed’ towards the middle bumper via the one of the
two other ball-
bumpers ( see next part about the sensors ).
Used sensors.
Bumpers (binary sensors).
The ‘soccer arena’ has four corners and is rather small, so it seemed obvious
to supply
the robot with as many sensors as possible to avoid becoming stuck in a corner
(or an-
other robot). This means that the robot should have at least one bumper-sensor
on each
side. On the back, two bumpers are necessary, so that the program can see if the
robot is
stuck with its back to the wall or just partly.
In front of the robot, two bumpers ‘sense’ whether the robot has crashed into
a wall,
and three others try to detect whether it has the ball and where the ball is
exactly located.
So, there are in total 9 bumpers connected to the SMBII board, which have two
main
functions: detecting where the ball is (3 in front), and detecting if the robot
is stuck or not.
Light sensors.
To detect the ball (and where it is located) from a distance, we also added
two white
light sensors. These are attached at the same height as the LEDs on the ball, to
detect as
many light as possible. The sensors are located in the front on the left and
right side. This
is necessary because it enables the software to detect how the robot is facing
the ball. The
sensors are covered with red transparent plastic, to block other light as much
as possible.
The green light from the adversary is detected by two other LEDs that were
placed
next to the ball sensors. To make the distinction between the green light from
the other ro-
bot and the red light from the ball, the adversary sensors are covered with red
and green
plastic. This way, it receives only the infrared part from the green light. By
comparing these
values to the results of the other sensors, we get a notion of where both
adversary and ball
are located.
Connections from the SMBII board to the sensors:
Analog input:
two ball-sensors: 0 (LeftModLight) and 1 (RightModLight)
two adversary-sensors: 2 (LeftLight) and 3 (RightLight)
Binary I/O:
three ball-bumpers: 1 (LeftFrontBumper), 2 (RightFrontBumper) and 5
(TopBumper).
two front-bumpers (left and right): 6 (Bin6) and 7 (Bin7).
two side-bumpers (left and right): 0 (Bin0) and 4 (RightBackBumper).
two back-bumpers: both at 3 (LeftBackBumper).
Pause-switch: 15.
Reset-switch: 14.
