## Building Keanu

### 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 Program seems working fine without any problem in test world 1 with 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 Program seems working fine without any problem in test world 1 with 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 Very fast to find the hole.  Not really working with this speed. Speed 200 As same as speed 150. Very fast to find the hole.  Not really working with this speed.

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:
• 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 The program seems working well with the test world 1. Wall following Map 2 The program seems working well with the test world 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.