Servo Calibration and Timing Considerations
To calibrate the accelerometer, we measured the reading when the board was positioned vertically for all four positions (forward, backward, left, right); see images below. We then used these values to map the instantaneous accelerometer readings to a pwm value. The servos we used have a period of 20ms, and according to the data sheet, a 1ms on time corresponds to 0 degrees and a 2ms on time to 180 degrees. However, when working with the servos, we realized that the servo range was actually from about .8ms to 2.3ms.
The accelerometer readings were very sensitive, with the numbers containing fluctuation up to the hundreds decimal place, which created very obvious jitter in the servos and made the game unplayable. To accommodate this, we implemented a low-pass filter on the readings, and used the filtered values in our pwm calculations. We updated the accelerometer readings in a thread with a 1ms yield time, and updated the PWM signals in an ISR that triggered every 20ms. These values were chosen through experimentation since we wanted the servos to respond quickly to changes in the accelerometer position, but also did not want to interfere with our other threads, which utilized polling to detect button presses. The restart button and finger sensor threads both had a yield time of 30ms; this value was based on human reaction time with an additional margin of error, since we aren't physically capable of completing two button presses within such a short period of time. Especially for the finger sensors, we wanted the response time to be as fast as possible so that the trapdoors could be toggled quickly, and we found that these values worked well.
Our calculations to convert the accelerometer readings to PWM involved adding an offset to bring the most negative accelerometer reading to 0, then multiplying this by the number of clock cycles corresponding to our desired servo range (1ms), and finally adding the minimum pwm on time. To further calibrate the servos, we added two different offsets to the x and y servos to make sure that the maze was perfectly horizontal when the accelerometer was placed flat on the table.
Changes in the IR sensor readings were detected using interrupts. As seen in the image below, when a ball falls through, the signal only goes low for about 25ms; if we were to implement IR detecting using a polling thread, it would have to run very frequently in order to ensure that change are consistently detected. We concluded that this would likely interfere with the timing of reading the MPU and updating the servo pwm values, and impact the responsiveness of the finger sensors. In addition, this change in signal is very clean and does not contain any oscillation or debouncing like the buttons that would necessitate polling. Utilizing interrupts also enabled us to capture the port value when the interrupt triggered, making the detection logic for determining which pin caused the interrupt very straightforward.
Our design did not contain any dangerous elements, but because the servos tended to behave quite unpredictably when uploading new code, we always made sure to unplug the power when making any modifications. In addition, since the finger sensors involve the user making an electrical connection with their hand, we made sure that they would be protected from any harm by selecting an electrically insulating glove and using low voltages. Regarding usability of our product, we acknowledge that this would be an even more difficult game to play for those that lack fine motor control in their hands, as well as those that are left-handed. However, this is unfortunately the nature of the gameplay, so we were unable to make accommodations for this.