Lab Report
Results / Conclusion:
While the wimp mode may seem to be a very simple program, it still has many factors that need to be considered when attempting to replicate it. A part of the lab consisted of simply playing around with and testing the robot to see what its preset Wimp Mode actually did.
While the coding for the Wimp Mode didn’t involve any complex functions or advanced-level coding, it did involve a good deal of logic. Furthermore, there were many different possible approaches that one could have taken to program the Wimp Mode. The approach I took can be seen in my Flow Chart.
The Wimp Mode that I programmed worked fairly well, and was a close replication of the actual wimp mode, with some minor differences. One difference, or sort of an extra feature I implemented, allowed the Create to automatically resume running the Wimp program when it was in safe mode without waiting for user input (i.e. it would stop running when you lift it up, but when you put it back down, it will go back into Wimp Mode).
Lesson Learned: Debugging
The one important thing this lab has taught me is the use of proper debugging. We really would have no idea what the robot was thinking if we didn’t use proper debugging tools. Debugging also allows us to identify what part of the code the robot is currently running. With this, debugging is an essential programming tool that comes in handy especially when your robot is encountering a problem.
Personally, I used the LED’s as well as sound to debug the Create. For instance, whenever one of the bumpers was hit, I would use the LED’s on either side to indicate that the Create had sensed a bump hit and was turning in the opposite direction. Furthermore, I used sounds to signify that the Create wasn’t in Safe Mode and should stop running.
FlowChart
Attach:MananWimp.jpg Δ
