Harvey Mudd College
Computer Science 154 -
Robotics
Assignment A
Building Keanu
Lab #1 write-up
SooYoung Jung
02/05/01
Part 1 - Stateless reactive control -- Survivor!
As mentioned in the introduction, the first test we'll be putting the
simulator to is building Keanu-level intelligence. In particular, you should
write a function
int computeRotationalVelocity()
that maps the sonar values (the input) to a rotational velocity (the
output), so that the robot (whose speed is fixed) survives as long as possible
without hitting the walls or obstacles in various environments. The return value
of computeRotationalVelocity is an integer, because that is the type
expected by the velocity-setting call, vm. (A prototype function is
provided in the test file, /cs/cs154/as/A/survivor.cc .
You may use the current rotational and translational velocities of the robot
in your computeRotationalVelocity function -- they are accessible as
State[39] and State[38], respectively.
Test Worlds
Two worlds in which to test your robot are included in
/cs/cs154/as/A. They are shown here. Note that not all angles need be
right angles
Survivor Map 1
Survivor Map 2
In the write up, below, explain your approach and include the text of your
code either in the HTML or as a link from it. Also, include the results of your
algorithm run at a variety of different speeds on the above two worlds and at
least one world of your own devising.
Results
My approach to survivor:
First of all, the program checks the front sonar and if the robot is closer
than the minimum distance from the block, which is made by me and determined by
input speed, then the robot should turn. To make a right direction turn, I
read the forward right (18) and forward left (32) sonars and turn the robot to
the direction whichever the value is high, which means it is seeing more
room.
Second, the program checks the infrared sensors. If the only one or two
infrared sensors see something very close and others do not see, it means the
robot is close to or will be close to the edge of the block. As a result,
the robot will turn to the opposite side.
Lastly, if the previous sensor checking is passed and infrared sensors read
the block is close, then the robot will turn to the direction, which has more
room to move. Therefore, program will add up the value of the quarter of
upper right side infrared sensors and the quarter of upper left side infrared
sensors. Then the robot will make turn to the direction whichever the
add-up value is bigger, which means the robot is seeing more space.
The algorithm for survivor program was quite good with slower speed such as
50 and 100, but not with faster speed such as 150 and 200 in both test
worlds.
Here is the link to the source code : survivor.cc | only
computeRotationalVelocity function in txt
Test World 1
|
|
|
|
Speed 50
|
Speed 100
- Program seems working fine without any problem in test world 1 with
speed 100, too.
|
|
|
|
|
Speed 150
- The robot crashed when the it saw the corner. It seems fine
but when it sees the corner, the robot cannot turn completely because of
fast speed.
After the first crash, it seemed working well, but when
it saw the corner, then it crashed again. |
Speed 200
- The robot did not seem so good with this speed. Whenever the
robot saw the corner, it crashed.
|
Test World 2
|
|
|
|
Speed 50
|
Speed 100
- Program seems working fine without any problem in test world 1 with
speed 100 until it saw the hole that the robot cannot go through.
|
|
|
|
|
Speed 150
|
Speed 200
|
After I run the program with the test world 2 with speed 100, I just realize
that if the robot sees the hole with speed 50, it would also go toward to the
hole. As a matter of fact, if the robot hits the block, it will turn and
if the robot is towarding to the hole and the diagonal of block is toward to the
hole, then the robot will keep toward to the hole. The robot will never be
able to escape from the hole. To work with this situation, the program should
contain whether the robot is seeing the hole or not. If so, the robot should
turn back without checking sensors and keep going.
Part 2 - Wall/corridor following
Wall-following and corridor following are low-level behaviors essential for
higher-level navigation and helpful for just wandering around. (This may have
been a technique you used in the previous part of the assignment.)
There is no restriction on how you design your wall-follower, i.e., you need
not use purely reactive control. Also, you may stop and start the robot as you
see necessary -- there is no requirement to go a particular speed. However, just
as survival times measure the fitness of algorithms in part 1 of this
assignment, for the wall-followers, running time will determine their fitness --
the faster they can circumnavigate an obstacle, the better, but even a slow
moving successful wall follower is better than one which wanders away from the
wall or continually crashes into it. (See the "robot pentathlon" note, below.)
Test Worlds
Two worlds in which to test your robot are included in
/cs/cs154/as/A. They are shown here. For this part of the assignment,
you can assume angles will be right angles (or at least close to it). The intent
is to build a left-wall follower, but you may intersperse corridor-following
(examining sonars on both sides) and right-wall following if you'd like.
Wall following Map 1
Wall following Map 2
In writing up this part of the assignment, be sure to include the
following:
- link(s) to your code
- a general explanation of your strategy
- an evaluation of how well your wall-following works
- several example traces of the robot
- how fast your robot can completely navigate around the environments
(presuming it makes it at all!) wallfollow_map_1 and
wallfollow_map_2
Feel free to add examples in your own
environments, too. Also, (optional, but appreciated) please comment on anything
that would make this assignment better in the future... !
Results
My approach to wall following
First of all, the program will check three front infrared sensors and add up
three values. If this add-up value is less than certain amount, 23, which
is close to the wall, then it will make turn. Even if this add-up value is
not less than 23, the robot can hit the wall: when it is turning the edge,
the value will be bigger than 23, so, we gotta check whether there is a block or
not.
If one of the 3 front sensors is less than 5, there is something in front of
the robot but cannot detect by add-up value. Also, check the sensor #15 so
the possible crash with edge can be avoided.
Also, if the robot only see the block from
the quarter of bottom left side, the block is end, so the program will make the
robot turn.
Here is the link to the source code : wall.cc | functions related to wall
following and while part in txt
|
|
|
Wall following Map 1
|
|
|
|
Wall following Map 2
|
When the wall gradually decreases as follow, it will hit the edge. As a
result, I added another function called isClose() because when the robot see the
edge, it will make a turn to avoid.
