Authors: Stefano Barbier (sab388) and Ian Cloutier (iac28)
For the ECE 4760 Final Project we created a wearable fall detection device that autonomously senses a fall using a carefully calibrated tri-axis accelerometer and contacts emergency services using a built in wifi chip and the Internet of Things.
This product is an independent device that attaches to your belt loop that can detect potentially dangerous falls and autonomously contact emergency services. When the accelerometer senses a fall, using a carefully calibrated detection algorithm, the wifi chip sends an HTTP GET request to the Internet of Things website ifttt.com. A recipe created on that website automatically sends a phone call to the user's phone asking if the user is ok. If the device initiated the call accidentally or the fall was not harmful, the user can cancel the emergency contact by pressing the built in push button within ten seconds. If the user does not press the "cancel" button, a second call is sent out to emergency services. Accelerometer parameters and the fall detection algorithm are programmed onto the PIC and WiFi connectivity is programed onto an Adafruit Dev Board using Arduino IDE. This project is appropriate for the final project of ECE 4760 because it builds on the PIC32 platform used in previous labs, while also integrating new hardware (accelerometer, wifi chip) and adding network connectivity.
Life Alert was the inspiration for this project. This device is a necklace you wear around your neck with a button, that when pressed, contacts emergency services. We realized that an inherent flaw in this system is that if the fall is serious, the victim may be unable to physically press a button. The device we've developed autonomously registers a fall and contacts emergency services. In order to address this problem we decided to emulate the motive behind Life Alert, but to add autonomous functionality and mutliple failsafes. Because the baby boomer generation is appraoching retirement and old age there is an expanding market for safety devices such as our product, so effort and time spent on research and development is justified because of the possibility of large demand once the product is launched.
There is no background math for this device.
The logical structure of this device was two split the development and design into two parts: detection and connectivity. By separating the two it was easier to debug issues which led to a faster development process. The majority of the functionality of this device is in the software and careful accelerometer calibration. The hardware is a PIC32, an Adafruit Feather M0 with WiFi Module, and a Kionix KX122 3 axis accelerometer.
We decided to write all the accelerometer code onto the PIC and all the WiFi connectivity onto the Arduino Dev Board. Because the Dev Board had both a WiFi chip and a processor which was compatible with Arduino IDE, it made sense to code the WiFi code in Arduino.
There really were no standards involved in this project. The only standard was to build a device that can have a positive impact on the user.
This device does not infringe on any intellectual property, or patents. Although similar devices exist, none of them are clothing integrated.
The software for the PIC32 begins by initializing the SPI, this was done almost identically to how it was done in Lab 2, however we had to change the mode to 8-bit mode since the accelerometer has 8-bit registers, the InitSPI() function took care of the SPI peripherals and initializing the chip select pin. Next all the appropriate input and output pins are initialized for the external interrupts and Arduino communication respectively. The external interrupts are then initialized and enabled, with the interrupt corresponding to the button set to trigger on thee falling edge and the free fall interrupt set to trigger on the rising edge.
Then the accelerometer is set up using the SPI functions written to write a value to a certain register and read a value from a register. The accelerometer is set in low power mode, where only the high 8-bits for each axis are measured. It set the range of measurement to +-4g, which in low power mode corresponds to a resolution of about .03g. The system would have no use for data above 4g, which is why it was set to that. It is also set to low power mode averaging for 8 samples, so 8 samples are averaged for each read value. The ODR of the accelerometer is set to 12.5 Hz, its lowest value to conserve power. Next all of the appropriate registers are set to enable the freefall interrupt and attach it to the INT1 pin which is wired to the External Interrupt 0 pin on the PIC. The interrupt is also set to unlatched mode where the accelerometer keeps the INT1 line high while the accelerometer is still reading accelerations under the threshold after the freefall triggers. This prevents multiple freefall interrupts happening during a single “fall”. If the INT is in latched mode, the line needs to be cleared via an SPI read after each interrupt. The g threshold and timing for the freefall interrupt are set to be +-.3g and 160ms. These were determined through our testing to be alright values that worked well enough, but as mentioned elsewhere, proper testing was hard to do, and the system could benefit a lot from proper testing. Protothreads is then set up with the main thread initialized. There is then a small delay to allow everything to set up. Then the program schedules the thread and the system begins operation.
The main thread runs 100 times a second waiting for freefall to be detected or the failsafe button to be pressed. The two flag variables FF (freefall) and FS (failsafe) that are set to one in their appropriate ISR’s are crucial to the systems functioning. If either are detected, the flag variables are cleared and the thread spawns the fall thread. The fall thread first waits for 2 seconds to see if there is another freefall. If there was another interrupt then the thread exits, as multiple successive freefalls is usually indicative of an activity such as jogging. If there are no successive freefalls, the system brings pin 10 high (which tells the Arduino to make the check call) and waits for either a 35 second timer to run out or for the failsafe button to be pressed. The user would receive the call and if it was a false trigger, the button could be pressed with the second call being made. If the 35 seconds runs out with no button press, the PIC bring pin 11 high which signals the Arduino to make the second call, after which it exits the thread. At any point where the thread exits, the system ensures all interrupt flags and signal pins to the Arduino are cleared. The software algorithm is set up so that in the case of a false trigger, EMS is not called accidentally and the user can cancel the call. It also allows the user to jump immediately to the check call state if they fell and the system did not trigger, in which case it is acting similar to the product LifeAlert.
The accelerometer chosen for the project was the KX122-137 3 axis accelerometer made by Kionix here in Ithaca, NY. We chose this accelerometer for a couple of reasons, one of the important ones being we were able to get them for free from the company. The KX122 has a built in free fall engine which detects when the device is in free fall and triggers an interrupt, this can then be attached to one of the 2 interrupt lines and connected to a PIC external interrupt pin (in our case INT0). The free fall engine works by detecting when all three axes of the accelerometer are below a certain g threshold for an amount of time. This works because the accelerometer measures acceleration by measuring relative displacement of a nanoscale mass to the casing of the part and using Hookes law to calculate the acceleration. When in free fall, both the mass and casing are experiencing the same acceleration and the displacement goes to 0. Both the threshold and amount of time are programmable by writing to certain registers. More detailed information and figures about the free fall engine can be found on pages 69-70 on the KX122 datasheet linked on this page. The accelerometer also has many other customizable features such as programmable ODR, sample averaging, g range, and an available low power mode which bring the current draw down to around 10 µA. In low power mode, the measurements only update the high byte of each axis, reducing the resolution of the measurements from 16 to 8 bit.
Adafruit Feather M0 board w/ WINC1500 WiFi
This board was chosen for 2 reasons. It acts as a translator for the WiFi chip, because all of the WiFi commands and writing has easy to use functions in the Arduino libraries. Writing the required C commands to do all the WiFi tasks would be a truly daunting task, and this board allowed that section of functionality to be written in Arduino language. The board also acts as a voltage regulator since it outputs a reliable 3.3 Volts from the 3.3 pin which supplies the PIC. The board itself is powered with a LiPo battery, enabling the whole system to be powered by a single LiPo. The board uses standard digital I/O and interrupt functionality, which is how it gets signals from the PIC. This board also has a special built in power saving mode which powers down the WiFi chip when it is not used.
For the device to be wearable, the PIC had to be standalone and soldered onto a solder board. In order to make the PIC programmable, capacitors, resistors and headers were soldered into place so the PICkit3 could be connected as described on the ECE 4760 PIC standalone page. For SPI communication with the KX122, SCK2 and the rest of the SPI pins were connected to the appropriate pins on the KX122 breakout board. We used RPB5 as SDO, RPB13 as SDI, and RPB4 as the chip select pin. For the freefall interrupt, the pin INT1 is connected to the external interrupt pin 0 on the PIC (RPB7).The failsafe button is connected in a simple switch/resistor setup as pictured below to pin RPB9. The pin goes low when the button is pressed.
For Arduino communication pins RPB10 and RPB11 are connected to pins 13 and 11 on the Adafruit feather board respectively. Pin RPB10 (which is connected to the feather pin 13) was brought high for the first call, and pin RPB11 (pin 11 on feather) was brought high for the second call. Pin 13 on the feather board is also connected to the red LED on the board, which was useful for debugging because it lit up when the pin was brought high.
A key component of the system is its low power usage. If this project were to be taken further to a product stage, one of the most desirable qualities for the product would be the infrequency in which the battery would have to be recharged or replaced. Currently, the system draws around 22 mA average during operation. With the small 150 mAh LiPo we used for this prototype, the system could be powered for about 5 hours.
Speed of Execution:
In the end we achieved all the goals we set out to reach before beginning the project. We designed a device that would autonomously register potentially dangerous falls and contact emergency services, while integrating safety measures and cancellation procedures. The device's speed of execution was acceptable for our first implementation; however, if this product were to be released as a product it would be important that certain parts activated faster. For example, the phone call after the fall detection takes about fifteen seconds to come, which is a long time when you are in pain on the floor. It is difficult to analyze the speed any farther because there are no quantitative results for this device, only qualitative ones.
Whenever the device registers a fall there is; however, a noticeable 100% success rate in phone call received from the internet of things service. It is difficult to test this device because we did not implement a repetitive procedure for testing, such as a falling dummy, that would allow us to carefully change parameters - we tested this device wrapped around our body. Because it was attached to one of us, it was difficult to actually replicate a potentially dangerous fall because that might cause harm to one of us. This inability to test accurately made it complicated to debug; however, through extensive testing we were able to resolve some issues. Furthermore, during the falls that we did test the device registered a fall, so it was accurate during these tests. The device is 100% accurate and fully functional once the trigger has been called on the communication side.
There are no real safety considerations in this design because this device is inherently a safety device in itself. The device is wrapped in a 3-D printed case to separate the electrical components from the user. Future designs will be waterproof in order to prevent electrical problems when there is rain or high humidity.
Interference with other designs:
There is no interference with other people's designs because our device only connects to the internet. The network assigns a unique IP address to our WiFi chip and because it is a unique host there are not connectivity or interference issues. Furthermore, the phone calls are sent to a specific and personal phone number.
This device is designed to be ergonomic and as user friendly as possible, especially because the target demographic is elderly people. The device is extremely easy to use and only requires a cell phone. The elastic belt can be custom fitted to a users belt size and the plastic casing only reveals one button. The learning curve is shallow steep.
This device met all of our expectations. Because the most important part of this device in terms of accuracy is the fall detection algorithm, further testing and development would improve the functionality of the device. If we were to work more on this device we would design and implement a testing strategy that could recreate testing environments over and over allowing us to carefully modify the algorithm. An example would be a test dummy dropped from the same heigh over and over again. This way we could also adjust physical characteristics, such as placement of the body, strap tightness etc.. as well as software parameters. We did not infringe on any intellectual property considerations. We did not reuse anybody's code except for some Arduino libraries that were imported to help with WiFi connectivity. We did not reverse engineering any designs; however, we did draw inspiration from Life Alert. There are patent opportunities for our design. If we decide to pursue this project we would need to get a utility patent in order to protect our intellectual property.
We made sure we followed the IEEE Code of Ethics throughout this project - all the following were followed.
1. To accept responsibility in making engineering decisions consistent with the safety, health and welfare of the public, and to disclose promptly factors that might endanger the public or the environment
3. To be honest and realistic in stating claims or estimates based on available data
5. To improve the understanding of technology, its appropriate application, and potential consequences
6. To maintain and improve our technical competence and to undertake technological tasks for others only if qualified by training or experience, or after full disclosure of pertinent limitations
7. To seek, accept, and offer honest criticism of technical work, to acknowledge and correct errors, and to credit properly the contributions of others
The group does not approves this report for inclusion on the course website.