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.
