"A Step in the Right Direction"

Contents

• Introduction
• System Overview
• Video
• System Description
• Testing
• Resources
• Work Distribution

Introduction

We designed our board to be both a pedometer and a compass that can interact with a python script running on a separate computer. Using the accelerometer, the number of steps are counted and recorded. In addition we initially turn on the red LED, and gradually change the color to yellow and then green as more steps are taken. Lastly, if you push the button on the top left corner of the board (SW2), the pedometer will flash your total number of steps in morse code on the LED and output the number of steps.

For the compass, we utilize the onboard magnetometer to determine orientation. The on-board LED should be blue when pointing north, red when pointing south and a purple gradient in between.

The python script interacts with the board and can both read and write. When reading, it outputs the current number of steps. For writing, it allows the user to change between pedometer mode, compass mode, and compass configuration mode.

Over the course of this project, we become much more familiar with communication protocols such as UART and I2C and how to implement them to create a smoothly running system. We also expanded upon our knowledge of interrupts to make our project interactive through buttons on the board. By putting this all together, we were able to make a tool that not only works well and is easy to use, but has a real functional purpose for everyday people.

System Overview

Video

Click Below!!!

System Description

Pedometer

After finding out the hard way that our previous project proposal (ethernet communication) was far too ambitious given the timeframe, we decided to use the UART and accelerometer code that we had expanded upon to implement a pedometer and compass using the FRDM Board. This project does not require any additional hardware.

The first thing that we implemented on the board was the pedometer. The board keeps track of the number of steps that the user takes by comparing the acceleration value to a certain threshold; if the measured acceleration exceeds the threshold for a certain amount of time (empirically determined to be 100 ms), a step is counted. To determine the acceleration threshold, we plotted the acceleration data using MATLAB and observed the acceleration values when we took steps with the board in hand. Upon closer inspection of the data, it appeared that the x- and y-axis data was fairly unreliable, but the spikes in the z-axis data clearly indicated that steps were taken. Therefore, we simply opted to use the z-axis data to determine when a step was taken, although this requires the user to hold the board parallel to the ground for best results; in future iterations, the board’s orientation could be determined by fusing the accelerometer and magnetometer data and we could use all three axes to help determine whether a step was taken. Given a longer timeline, we could have expanded upon this prototype-like design and implemented this functionality. To prevent a single step from being counted multiple times, the acceleration must be maintained for at least 100ms and there must be a minimum of 100ms between steps; these thresholds were determined by looking at the data using MATLAB and by considering human limits (10 steps a second is not physically possible!). To keep track of time, we use the realtime clock from Lab 5 that uses the PIT1 interrupt to update the current_time struct every millisecond.

In addition to simply recording the steps that the user has taken, we also use the onboard LED to display the user’s progress to their target number of steps for the day (more on how this is set later!). To provide a visual display of the data, the LED is initially red and slowly turns to green as the user takes more steps to reach their goal; the color displayed is a linear interpolation of red and green that corresponds to the percentage of the goal reached. Because each color LED (red, green, blue) can only be on and off at a given time, we display colors in between red and green by flashing each very rapidly; similar to PWM, the amount of time that each is on is proportional to the percentage of each in the color. To achieve this, we used the FlexTimer module to generate interrupts very frequently. One cycle of the LED PWM corresponded to 256 such interrupts; the LEDs were turned off at the beginning of each cycle and then turned on at certain points so that they were on for the desired percentage of the cycle. By varying the amount of red and green in each cycle as the step count increased, we were able to show progress. In addition, the current number of steps is flashed in Morse Code when SW2 is pressed; this is done by calling the appropriate function from our Lab 1 Assembly files. Pressing SW3 switches the board to compass mode.

Compass

The compass utilizes the on-board magnetometer to determine North and South. We viewed the magnetometer data points by outputting them serially using UART and then viewing these data points in PuTTY. We determined empirically that when the board is oriented northward (the side with the LED is facing north), the magnetometer data is at a minimum. When the board is facing south, the values are at a maximum. Then, like the pedometer, we utilized the FlexTimer to gradually transition from a blue LED when facing northward to a red LED when facing southward. We ran into a slight issue with the compass when we realized that although our boards are the same model, the magnetometers record different values. For example, one board had a minimum value of 180 when pointing north and a maximum of 280 when pointing south while the second board had a minimum of 1 when pointing north and maximum of 160 when pointing south. To account for this, we set up a configuration mode that records the average values of the magnetometer when it is facing north and south. This calibrates the code specifically to your own board so that the LED transitions from blue to red correctly as you rotate it. When in compass mode, the buttons SW2 and SW3 have the same functionality as in pedometer mode; SW2 displays your current number of steps and SW3 switches you to the other mode (the pedometer). It should also be noted that the board should be removed from any nearby metal when using the compass as this affects the magnetometer.

Serial Commands

To allow the user to set certain parameters for the pedometer and compass, we run a python script on our laptops that communicates with the board via UART. In the C code run by the board, we enabled interrupts to be triggered whenever the board receives information via serial. The data read by the C code is taken from the UART input register and placed into a dynamically allocated character array. We also utilize the realloc function to increase the size of our character array as more characters are read in and we run out of room. To differentiate between commands, the interrupt handler checks the last character of the data being transmitted - ‘c’ changes the board to compass mode, ‘p’ changes it to pedometer mode, and ‘x’ enters the board’s configuration mode. In configuration mode, the user can type in a target number of steps in the python script. This mimics the idea of having a step count target that a person is trying to achieve each day. The LED color gradient is adjusted to this target number of steps so that the LED becomes entirely green only once this target has been reached. Alternatively, the user can enter nothing and the target number of steps remains the same. After this, the python script asks if the user would like to calibrate the compass. If the user inputs the character ‘y’, they can calibrate the compass by specifying the orientations of north and south; this is done by pointing the board north, pressing SW3, then pointing the board south and pressing SW3 again to exit the configuration mode. A cyan LED will blink if North is calibrated correctly and a blue LED for the south. In addition, whenever the user presses SW2 to display the number of steps taken, the number is also written out to serial for easy debugging.

Testing

As we developed our project, we continually tested the functionality of the board as we went along. When debugging, we often sent data to the computer via serial to mimic print commands so we could easily see if something went wrong.

To start, we developed and tested the functionality of the pedometer; first, we simply blinked the blue LED to indicate that a step was taken. After walking around with the board for a bit, we were able to adjust the acceleration and time thresholds so that the board recorded our steps with relatively few miscounts or false positives. Once we verified that the pedometer recorded our steps to a satisfactory degree of precision, we then wanted to test if our visual displays of the data worked properly. To test if the number flashed in morse code was accurate, we used PuTTY to read the number of steps via serial communication and saw if that matched up with the number being flashed by the LED. To check if our visualization of how close the user is to their step goal, we simply walked around with or shook the board to see if the LED changed color from red to green (corresponding to the percentage of the goal that has been completed) as the number of steps increased; we also checked the number of steps periodically to check if the color made sense (i.e. red for 0%, yellow for 50%, and green for 100% of the goal, colors linearly interpolated between these). We also checked the “boundary cases” in which 0 steps were taken or the number of steps exceeded the goal; in these cases, the LED was red and green (respectively), as expected.

Once all of the features of the pedometer were thoroughly tested, we decided to add and test compass functionality. To check if this was even a possibility, we read the magnetometer data via serial and displayed it on our laptops using PuTTY; by looking at the values on each axis, we saw that the magnetometer’s y-axis value was minimum when the board was pointing north and maximum when the board was pointing south. After setting up the magnetometer using the y-axis values, we tested the compass by pointing the board in a known direction and observing the color of the LED; when the board was facing north, the LED was blue, and it was red when the board was facing south (all as expected!). When testing the board, we noticed that the magnetometer was very sensitive to nearby metal objects and magnetic fields; while bringing magnetic objects near the board obviously made the compass unreliable, even normal metal objects like a spoon or set of wires affected the measured values to a noticeable extent. We also noticed that the values read by the magnetometers on our boards were quite different - this inspired us to create the calibration mode in which the user can set the min and max values. In the future, it may be useful to create a more precise calibration function but we simply did not have enough time to complete it.

Resources

• We often consulted the FRDM K64F manual when writing our code for necessary register names
• To set up the FlexTimer, we found this NXP forum post to be very useful
• The FXOS8700CQ accelerometer/magnetometer datasheet was also very helpful in setting up the magnetometer functions
• Provided 3140_i2c files were used in our lab - 3140_accel and 3140_serial were very useful in working with serial and accelerometer data

Work Distribution

Throughout the course of the past two weeks, we met quite frequently over Zoom to work on the lab together. We both went to office hours if needed and worked on the project on our own time as well. Work distribution was spread equally among both of us - each of us worked on every file that was turned in and would consult each other with ideas before making changes to the code. The only issue that we encountered was that the internet would occasionally crash during our Zoom calls. While we each worked on every part of the project to some extent, Jade focused on the pedometer and editing the video, and Eric worked a lot on the website and getting the serial commands to work. Overall the work distribution was equal and we both understand every aspect of our system.