This week I worked on several tasks:
- Testing and verifying the training mode of the user experience
- Integrating more interrupts from the RPi with Ashwin
- Modifying the state machine
- Starting to move from the breadboard to the more final Pi Hat PCB
I tested the training mode in the user experience, and I showed it off working correctly during the 3 demos this week. This is significant because it is an MVP for the embedded system. The only issue I ran into was an assertion mysteriously failing when the training mode finished. I will need to debug this.
Now that I am starting to integrate my embedded software with the RPi, I worked more closely with Ashwin and discussed, in detail, how we expect the user to use the system and what that means for communication between the RPi and Teensy. We realized a single pause interrupt can pause the system (when the pause signal rises) and resume (by checking when the pause signal falls). Ashwin implemented the pause interrupt on the RPi, and we tested to ensure the Teensy could respond to the interrupt.
We realized some incorrect and missing transitions in my state machine, so I added those in. The main changes were to the PAUSED state:
- Adding transitions from WAIT_FOR_STRUM and USER_EXPERIENCE to the initial WAIT_TO_START state upon receiving a restart interrupt. Previously, the only way to restart the state machine was to enter the PAUSED state and then transition to the initial state vis a restart interrupt, but this added an unnecessary visit to the PAUSED state; the state machine should reset to the initial state from any state upon receiving the restart interrupt.
- Redirecting the transition starting from the PAUSED state and ending in the WAIT_FOR_STRUM state to instead end in the USER_EXPERIENCE state. We realized the previous way involved an unnecessary intermediate state transition, which would interrupt the user experience.
- Leaving the paused state based on the resume condition (pause signal falls) instead of based on a strum
This is the state machine before the changes:
After the changes:
Since Owen was able to finish the Pi Har PCB, I could use it to test if it can properly relay signals between the RPi and Teensy. I moved the Teensy from the breadboard to the Pi HAT, changed some pins, and got the Teensy receiving interrupts from the RPi. This is a good step towards integration.
This progress is on track. The main tasks left for me are:
- Testing the continuous part of the user experience
- Computing statistics on the user’s performance and sending that to the RPi
- Writing code for the buzzer
ABET #6 says … An ability to develop and conduct appropriate experimentation, analyze and interpret data, and use engineering judgment to draw conclusions
Now that you are entering into the verification and validation phase of your project, provide a comprehensive update on what tests you have run or are planning to run. In particular, how will you analyze the anticipated measured results to verify your contribution to the project meets the engineering design requirements or the use case requirements?
I plan to write unit tests to verify the embedded software to ensure small modules work correctly. So far, I have been manually testing the interrupts to ensure the state machine works, but this is time-consuming, and having an automated way to test this would be nice.
Also, to verify strum detection and note detection, I plan to strum the guitar several times and have the system count how many times it believed a strum occurred. Same for note detection. On top of what we already mentioned in the design review, I realized there is another important test to run besides testing for the system detecting the correct note – we should also play the wrong note and ensure the system can tell that it is a wrong note. That way, we can test for false positives and false negatives.