A large aspect of our early testing was ensuring each element of our project worked independently, then integrating each aspect one at a time.
We first ensured the mobile robot could move in all directions, writing simple movement functions to go forward, backwards, left and right when powered with the external power supply. We ran into some difficulty as we were using the PT_GETTIME_us() function in our movement functions to keep track of how much time was spent going forwards. However, our functions were not protothreads so this line halted our movement. We also found errors in declaring the PWM mask, where we must use a logical OR between the left and right motor slice numbers.
As discussed earlier, we ran into an issue where one frequency was more detectable than another and found this was a problem with the frequency sampling rate when swapping the code on both Picos and seeing it was not a circuitry problem. Increasing the sample rate allowed the 5000Hz frequency to be detected.
Our debugging techniques was to analyze the sound emission and response without yet involving movement. We were finally able to get a suitable call-and-response for our needs.
Call-and-Response Demonstration Video:
Lastly after all code has been written and aspects worked independently, it was time to debug the state machine. Through lots of test runs and seeing the usual movement of the mobile robot, we made improvements to state machine as follows:
- When first entering a new case, we must first take a time difference measurement, and then always move forwards (backwards if that is the default, seen later in the state machine) to take a new time difference measurement and compare to see if the robot is moving in the correct direction
- The mobile robot moves after receiving a time difference, and then emits its response. Otherwise, we saw that the response sound was being calculated during the movement, which we only want to happen after movement when the mobile robot is at a new location.
- When the state machine ends, i.e. the mobile robot believes it has found the stationary speakers, the microcontroller on the mobile robot will turn on the onboard LED - this helped with debugging to know when the state machine has complete
- As shown in the image below, the time differences were on the order of 10^5, and approximately one-third of the time the recorded time differences were on the correct magnitude. Due to the vast impact an incorrect time difference calculation has on our state machine, we decided to take the median of 3 time difference values (following 3 call-and-responses between the mobile and stationary circuits). This vastly increased our state machine accuracy.
- If the stationary robot did not send a response or the mobile robot did not detect a response, we have a timeout where the mobile robot will send its signal again and wait for a response. In the case that background noise was louder than the response, our execution time increased as many back-and-forth clicks would be sent before movement was observed
To allow full mobility of our robot, we decided to battery power all elements of the circuit. We had a 9V battery for the speaker, 2x1.5V batteries for powering the microcontroller, and 4x1.5V batteries for supplying voltage to the motors. To avoid confusing each battery inputs/outputs, we recorded the location of each battery input and ground and checked our connections before connecting any power. This maximized our safety as well as prevented frying our circuit elements.
To start and restart the mobile robot, the user must simply connect the microcontroller to the 3V power source. This makes it easy for others to begin the robot’s motion through the state machine.