Project Overview

Our project is a smart pedometer with more features. StepWise can keep track of the user’s step count and display it on an OLED screen with animation depicting whether you're standing still or walking. We also use a GPS module to keep track of the physical route of the user in real time. Once the user is done walking, they can commit the route, where the recorded GPS data will be processed in AWS and converted into a visual route displayed on Google Maps. The step count and a link to the mapped route will be sent to the user's email for convenient access and sharing. We ensured that the route starting/committing/resetting workflow is quick and easy.

Functional Specification

StepWise enables you to keep track of your route when walking, continuously counting your steps, and periodically storing your current GPS coordinates. You can continuously monitor your current step count and see whether you're currently walking or standing, all displayed through the OLED. Once ready, you can press the SW3 button to start or commit the route. Committing sends you an email showing you your step count and a link to Google Maps showing your route. Pressing SW1 resets StepWise.

System Architecture

Each component/service will fit together as shown on our system architecture diagram above. The user can give 3 different inputs (location for GPS, walking for accelerometer, and any button press for starting/committing/resetting a route). The CC3200 Board takes those 3 inputs (with I2C, UART, GPIO) and handles all the state logic, outputting to the OLED (with SPI) for user feedback. When the user commits, the CC3200 Board sends to AWS, which then handles the Google Maps link generation and sends an email to the user.

Implementation

1. GPS Module

We used the RYS352A GPS module to collect the location data for route tracking. Once the module is powered on and with a clear view of sky, the module will acquire satellite signals and begin outputting location data in form of NMEA (National Marine Electronics Association) sentences. These strings contain various types of GPS information, including latitude, longitude, altitude, and time.

The communication between the GPS module and CC3200 is established by UART. The GPS module continuously sends NMEA sentences through its TX pin and we use UART RX pin in CC3200 to read.

To extract information from the GPS module, we program CC3200 to decode the NVEM sentences, extract latitude and longitude values, and store the coordinates into json files for later mapping.

2. Step Count (accelerometer)

To count the number of steps, we use the accelerometer in CC3200 via I2C protocol. Allows the CC3200 to read the acceleration data from the sensor in regular intervals.

Our step detection algorithm operates on acceleration data from a single axis because it most clearly captures the pauses of foot during walking, creating distinct patterns in horizontal acceleration data.

We have a sliding window of recent 50 acceleration readings to create a dynamic baseline. We calculate the average acceleration and range of the values. Allow the system to adapt in real time to different walking intensities and sensor noise.

To detect a step, we monitor whether a new data point exceeds:

average + 0.2 x range
average - 0.2 x range

Such deviations indicate a significant change in the movement - likely caused by a leg pausing. Additionally, for every 10 steps, we record the GPS location for later mapping.

3. Button presses

We use the GPIO protocol to detect whether SW3 is pressed to start a route if on the start screen, or commit a route if already tracking it. For the reset feature, we didn't have to implement anything since we took advantage of SW1's existing functionality to reset the currently flashed program, which in our case sends the user back to the start screen where they can start a route again.

4. OLED display

We used SPI to display various screens to the user. On the start screen, we welcome the user and prompt them to press SW3. On the tracking route screen, we display the current step count and also a stick person depicting whether you're currently walking or standing still. On the committing route screen, we display feedback showing whether the CC3200 board successfully sent the AWS POST request, and we also prompt user to press SW1 to restart.

5. AWS

We took advantage of AWS Lambda, a web service that allows you to run code based on certain triggers. For StepWise, our trigger was our thing's shadow update. Once triggered, it parses the thing shadow for the step count and GPS coords, which are stored in 2 lists: a list of latitudes in decimal and a list of longitudes in decimal, where both lists have the same number of elements.

Parsing the lists, we dynamically create a Google Maps link by getting the origin (first coords), destination (last coords), and waypoints (in-between coords), then passing them into the url.

After that, it publishes to an Amazon SNS topic where all subscribers of that topic receive an email telling them how many steps and the Google Maps link.

Challenges

1. At first, we used a static threshold for step detection, but it did not work well - every time when the position of the board changed, we had to adjust the threshold inside the program.

We then tried using other methods like standard deviation-based detection, but the results were still unreliable and inconsistent.

Finally, we developed our current algorithm using a dynamic average and range from the latest 50 horizontal acceleration readings. After many adjustments, we found this method worked surprisingly well - not by detecting the leg movement, as we originally intended, but by picking up the pause in leg motion during walking. It turned out to be a more accurate indicator of step, so we decided to keep it.

2. When selecting the module for our system, we have to consider power voltage, communication protocol, and physical connection. Many modules either required extra components or did not provide stable output.

Once we chose the RYS352A, we faced another problem in decoding the GPS data. The other problem is the module outputs data in NMEA format, which requires us to write a custom parser to extract the information like latitude and longitude. This process involved handling noisy or incomplete data and ensuring the parse was accurate for CC3200 to handle in real time.

3. Another challenge we faced was the CC3200 Board's limited computational power. It can only do so many things at once (updating the OLED, step detection, GPS coords, AWS requests, etc). We went through a lot of trial and error, even trying to use a threading library to improve performance. Eventually, we simplified things by not using threads (since they showed no visible improvement) and instead optimized our system's workflow. We only send to AWS at the very end when committing a route instead of a request for every GPS coordinate. We also removed overly complex OLED animations, which vastly improved our step detection's performance.

Future Work

For future improvements, we want to display the user’s real - time GPS location on an on board OLED screen, allowing the user to see their position on a simplified map during their walk or run.

Additionally, we aim to enhance the accuracy of step counting during long - distance walking or running. While the current method works well for regular walking, it may lose precision with faster or more continuous motion. Improving the algorithm to better handle these cases - possibly by incorporating multi-axis analysis - will be a key focus.

Bill of Materials

Note: This bill of materials is general for anyone, not what we actually paid (since we got most of these components for free for EEC 172), so we included general market prices/sources. We did pay for the RYS352A GPS module through Amazon.

Page updated

Google Sites

Report abuse