OVERVIEW
Design and Implementation
The main goal of this project is to detect motion and trigger an audible alarm to prevent the theft of a bicycle. While it is imperative that the system accurately detects positive theft events, another important aspect is filtering out false positives. Minimizing when the system triggers when there is no theft event is equally important to detecting an actual theft event.
HARDWARE
We implemented the MPU 9250 IMU into our device. While this IMU is capable of much more than simply detecting motion, our requirement of detecting motion was well within the abilities of the sensor. The MPU9250 IMU was connected to the Tiva TM4C123 via an I2C communication protocol. For I2C communication, only the clock (SCL) and data signals (SDA) were connected.
For the alarm sound, PWM ports on the microcontroller were used to feed the first stage of the amplifier. Next, the four PWM channels were fed into a 74LS126 tri-state buffer. The combined audio signal was supplied to the input of the PAM8403 breakout board which powered the 3W speaker.
​
Power for the entire system is provided via a 5V USB battery bank. This allowed the device to be completely portable and alleviated the need to be tethered to a power source.
SOFTWARE
The software that was developed for this system utilized the open-source FreeRTOS program which creates tasks that run on the microcontroller. This program allowed the system to read a converted midi file and output the correct frequencies for each corresponding note of the audio file. A separate program was used to convert a midi file into a .c file that contained a struct which held the information pertaining to each note with its timing and frequency characteristics. A free-use midi file containing the alarm sound was downloaded and converted using this program. Finally, the microcontroller software, utilizing FreeRTOS would create a task that would play through the converted midi and output the correct sound.
To achieve the functionality of detecting motion, the MPU9250 IMU sensor was initialized upon system boot and a separate function collected the baseline average readings. Upon detecting a motion event that was deemed to be a theft, the function returned a value triggering the alarm to sound. Upon initialization of the necessary components, the system would enter a state that would wait for an arm signal provided by the onboard switch SW1. Once the system had entered the armed state, the IMU would be polled for accelerometer data. If the system detected a motion event that passed the specified threshold, the alarm sound would be played over the speaker. To avoid false positives, it would ask whether or not the distance moved in the x, y, or z direction was greater than a static buffer value. If it was, the motion detect function would return true.
EXPERIMENTS
To test the real-world performance of the integrated system, we ran the device through a series of trials. Beginning with small movements and incrementally increasing to physically shaking the device. The device was fine-tuned to filter out noise that the sensor detected. By testing this way, an accurate threshold value was determined and the performance of the device resulted in normal behavior. Volume of the speaker was another important aspect to this device. Volume of the device was tested using a phone application that displayed the decibel level of the speaker.
​
A typical alarm speaker achieves a decibel level between 90 and 100 decibels. Our speaker reached a maximum of 82 decibels. Further refinements could increase the output of the speaker and will be looked into for future improvements.
RESULTS AND DISCUSSION
Initially, we found difficulty implementing the accelerometer with the Tiva C board. At first we weren’t able to find a reading from the board itself but after much research and testing sample files to gain an idea of how to construct our code, we were able to code a basis for our program that would tell whether or not the accelerometer changed positions from when it last recorded its position.
The speaker results were a lot more simple in terms of checking if it was working properly. When connected to the power and turned on, the speaker will play a static sound or feedback which indicated that it was powered. Initially in our research, we found what was most compatible with our design, was an existing project that was directed toward playing full compositions of songs, but found that we could keep a digital signal to send through the system to play a sound. The project we researched used midi files as well to play music and it did not require much modification to be able to implement it on our device. The dual stage amplifier implementation we took allowed for the 1W speaker to output the maximum volume and came very close to comparable devices on the market.
For how to handle the threshold and grace period of the arm state of the device. Code was implemented to use the sprintf() function to display a message to identify movement. The motion_detect() function we used to determine whether or not the device was moving, has a delay every iteration. When debugging using Tera Term, about one second is measured between each motion check.
​
We initially thought that triggering a consecutive three truth positive checks would be sufficient enough to activate the play_note() function for the PAM. This would be fulfilled by using an integer counter to keep track of how many times the motion_detect() passes true. But for the sake of minimizing the memory allocation for our microprocessor and to reduce the amount of clutter in our program, we opted to implement task functions to handle the delay and organize the functionality of the device.
CONCLUSION AND FUTURE WORK
This project was to design and create a fully-functioning bicycle alarm that provided extra deterrence against thieves. The final product accomplished these tasks and provided insight into areas for improvement going forward. For example, in the current iteration of the software, the IMU sensor is being read more often than it needs to be in most cases. For future iterations of the project, code would be implemented to enable the interrupt pin on the IMU with supplemental interrupt handling. This would allow for the system to essentially enter into a low-power state and conserve the power supplied by the battery bank. Our project allowed for a deeper understanding of the TM4C123 microcontroller and other Arm-based microprocessors.
