There were many attempts made at getting the Wimp Mode to work. Problems were encountered such as the robot not responding to bumps while driving, the robot not responding to bumps at all, and the robot not driving at all. Through these problems I learned about ways to solve them in more ways than one.
In the case of the robot not responding to bumps while driving, I had written a “checkbump()” function, which checked the bumpers of the robot and responded accordingly as the Wimp Mode would. As it turns out, my function was overcomplicated and had to be significantly simplified until it was eventually simplified into one loop. Instead of reducing my code to only a fraction of what it originally was, there is another way to solve the problem.
This was called recursion, which is when a function refers to itself in its code. This is effective when you need something to be constantly checked, like the state of a bumper, but it uses too much memory: memory the iRobot Command Module does not have. In the end, I resorted to simplifying my code.
Also, I learned how to avoid using two variables when I don’t have to. One problem I was having was with the negative angles generated by a right turn. If the angle has been initialized to 0 and the robot turns right, say for example, one degree. The angle changes to 359 degrees, but the revolutions turn to -1 revolution. This causes problems. In order to avoid this, one can initialize the robot’s angle to 180 rather than 0. This will prevent a need to delve into negative angles and revolutions so long as the robot is not turning more than 180 degrees to the right. In the end, the robot worked almost exactly the same as it does in the Wimp Mode Demo.
Attach: main.doc Δ
Attach: Wimp Mode Flow Chart Δ
