Datasheet

Page 208· Applied Robotics with the SumoBot
Slow motion debugging leaves out one crucial element: the actual conditions the
SumoBot experiences during a round. This is where datalogging comes in. The
SumoBot can be programmed to save all the Debug Terminal information it displayed to
EEPROM. After the round, you can play it all back, and match what the SumoBot saw
and did to its problem behavior.
The Scientific Method
The five steps in the scientific method are:
1. State the problem
2. Make observations
3. Form a hypotheses
4. Do an experiment
5. Draw a conclusion
Following these steps may involve several iterations, with the first few conclusions being
"the hypothesis does not explain the SumoBot's behavior." Even so, combined with the
programming concepts introduced in this chapter, these five steps will serve you well.
ACTIVITY #1: USING THE LED TO SIGNAL AN EVENT
The LED can provide you with a number of quick tests to determine whether or not an
event occurred. For example, let's say that the SumoBot has stopped responding to
objects on its right side The problem could be with the wiring, or it could be somewhere
in your modified program.
Ruling out the wiring is easy. Just run TestSideIrObjectDetectors.bs2 from Chapter 3,
Activity #5. Then, simply waving your hand in front of the LED in question with the
Debug Terminal running will tell you whether or not the circuit is working.
Assuming the wiring checks out okay, the LED can then be used to test and find out if the
program is doing what it's supposed to. This activity demonstrates how you test for
potential problems in the program by inserting LED code into key locations.
LED Bug Testing Examples
There are a lot of potential coding problems that can come up as you modify the program.
For example, did the
irRF bit get accidentally cleared somewhere in the program? If
not, is there a problem with the looping code inside the
Track_Side_Right_Object
subroutine? Is there a problem with the program's branching?