There’s a simple question asked by runners, walkers, joggers, and anyone who moves. How fast am I going? Runners want to pace themselves, athletes are trying to train for events, and even on a day to day basis you might wonder how far you are travelling. There are various existing methods of measuring pace, including step counters, GPS units, and smartphone applications. Pedometers are a common method of tracking physical activity. However, many pedometers are self-contained units that are often out of sight and out of mind. Our wireless pedometer not only records steps, but sends this information wirelessly to a wrist-mounted module. This wrist unit provides users with easily accessible information about the number of steps they’ve taken, their pace, and the timing of their steps. The tracker also calculates and displays the speed at which the user if moving, given an average stride of the user.
High Level Design
Rationale and Source of Our Project Idea
Our team has an interest in running and walking, and we have noticed that existing systems make it difficult to actively monitor your number of steps as well as your pace. Applications on your phone may only work in environments with cell phone coverage, and may not be practical for longer runs that require extended battery life. Pedometers placed on the waist are difficult to check quickly. There are some pedometers, like the Nike FuelBand, which are placed on the wrist, but these suffer in accuracy due to their placement. Our idea was to take the best of both worlds: create an easily read, low cost pedometer that displays its information on the wrist while still accurately measuring the number of steps with a detector placed near the foot.
Background Math
The mathematical grounding of our project are Newton’s equations of motion as well as the acceleration equations.
Using Equation 1, we know that taking the derivative of acceleration with respect to time results in the jerk of the system. By looking at the zero crossing of jerk from a positive to a negative value, we recover the peak acceleration of the accelerometer. This peak in acceleration corresponds to a foot hitting the ground or a foot rising very quickly from the ground. However, depending on our threshold, we may not be able to catch all steps if we have the accelerometer on one ankle. This is because the acceleration on a step up is oftentimes less than the acceleration on a step down. An example of this behavior is included in the section Software Design: Step Detection Algorithm. Because of this, it is also helpful to consider the jerk, as upward foot movements still have a unique jerk signature. We can look for these upward foot movements by scanning for data with high absolute jerk, and then processing them with a lower peak acceleration threshold. By finding appropriate peaks in acceleration on a single foot, we can accurately measure the number of steps that a person has taken using one single-axis accelerometer. More information about existing footstep detection algorithms can be found in the References Section.
Using equation 2, we can extract the user’s velocity directly from an accelerometer orientated parallel to the direction of motion. The initial velocity and initial time are set by the detection of a footstep using the jerk scheme described above. Until the next footstep, the acceleration readings are summed. Then, upon detection of the next footstep, that accumulated acceleration is divided by the change in time, resulting in the final velocity in the direction of motion. We were able to implement this functionality in our system. However, our accuracy was extremely low because we were using a one-axis accelerometer. In order to get decent accuracy, the accelerometer would have had to been perfectly aligned and oriented. Had we used a three axis accelerometer, we would have been able to recover the user’s velocity, among other benefits. This extension will be discussed further in the Conclusions section. Our current system discards this x-axis information, and uses the user configured step length to give an accurate estimate of the user’s pace.
Logical Structure
At a high level, our system has two main logical and physical units:
- Foot Module
- Wrist Module
The foot module uses an accelerometer to measure the acceleration and deceleration of the foot in the z-axis. It does light processing of the data, then packages this information and sends it over Bluetooth to the wrist module. The wrist module uses information received from the foot to calculate whether a step has occurred. It then displays this information to the user on an LCD screen. The wrist module also takes inputs from the user to set the desired pace and stride length. Both modules contain an ATMega1284P microcontroller running on the Tiny Real Time (TRT) Kernel and an HC-05 Bluetooth master/slave transceiver.
The user interfaces with the device using the wrist module. The wrist module powers up in a configuration mode. In this mode the user can use the two push buttons to adjust his or her stride length and also the desired speed. An enter button allows the user to enter into pace display mode. At any point the user can re-enter configuration mode by toggling a switch on the wrist module. In configuration mode, the wrist module is still capable of collecting and processing data. It is only the information that’s displayed on the LCD that has changed.
Hardware and Software Tradeoffs
There are several important software and hardware tradeoffs in our system. When dealing with the accelerometers, there were a few occasions when we had to decide between implementing a feature in hardware or in software. The accelerometers have the option of a self-test to recover from hardware errors and verify that the chips are functional. The self test results are output on pin 4 of the accelerometer. Should this result be high, as it is upon power-up, the accelerometer is compromised and the self-test must be run. This self-test involves setting and resetting a pin on the chip. We could have done this with software in our initialization code, or set-up an interrupt handler to reset the accelerometer when needed, but we chose to implement it in hardware using LEDs and switches. This is because various hardware events cause the accelerometers to malfunction and require a reset – power cycling, wire shorts, popping out of the breadboard, and many other malfunctions more probable in prototypes than a polished product. A hardware reset alerts us to a possible hardware malfunction so that we can address it, rather than continuing to receive potentially faulty data.
We also chose to use accelerometers that output an analog value rather than a pre-converted digital value. The reasons for this include: cost, ease of use, and transparency in functionality. First off, accelerometers that output an analog value corresponding to acceleration are cheaper and more widely available from vendors. Furthermore, as we were going through the implementation process, it is much easier to hook up an oscilloscope to an accelerometer outputting an analog value. Had we used a digital accelerometer, we would need to use pulse width modulation in the MCU or some similar scheme in order to visualize the changes in acceleration during human motion. Also, when connecting the accelerometer to the board, we can simply attach the output to an internal A/D converter in the MCU. A digital accelerometer would need to communicate over some serial communication protocol – SPI, I2C, or UART – to name a few. Finally, by using an analog accelerometer, our MCU get’s to control exactly how many digital samples it receives and at what accuracy. We are the ones who actually get to control how we take in data.
Lastly, we chose to use 1.5g accelerometers simply because they were the most appropriate range of parts that were free for us to use, and because we did not have the time in our schedule to sample some parts we were interested in. The class of accelerometers we ended up using are only available as 1-axis components.
There was a major tradeoff within the software as well. To maximize the number of readings that we get from the accelerometer, the foot would ideally only be running the A/D conversion. However, this raw acceleration information must be processed to calculate jerk and detect a step. To do this, we chose to send the information over Bluetooth to the wrist module. The wrist module does not have that same A/D computation constraint. It can take its time doing the long jerk calculations and determining when a step has occurred, leaving the foot module to focus on just grabbing the analog acceleration data, converting it, and sending it over Bluetooth.
The foot module, in order to both read and write the measured A/D value, must protect this variable with semaphores. Because of this constraint, we chose to run the multitasking TRT kernel on the foot module. Although some cycle time is lost in order to run TRT, this is offset by the ability to execute atomic reads and writes of a shared variable. The wrist module also has several tasks that it must run at once with shared variables among those tasks. For this reason, we run TRT on the wrist module as well.
Finally, there is a software tradeoff in choosing when to send the acceleration information from the foot to the wrist. If we sent all of the information from the z-axis and x-axis accelerometers, the wrist starts to spend more and more time in the task that receives the data, leaving little room for other important tasks like calculating jerk and updating the LCD. Furthermore, as the load increases on the Bluetooth channel, the latency increases as well, and at a certain point, packets are dropped. To mitigate this slowdown we do some preprocessing on the foot module to determine what data actually should be sent. We carefully balance doing pre computations on the foot that reduce the wrist’s amount of receive work with the need to avoid excessive computation on the foot that prevents the A/D conversion from running as much as possible. The details of this are described further in the software design portion.
Standards
The Bluetooth HC-05 boards that we purchased follow the Bluetooth standard as set by the Bluetooth Special Interest Group (SIG) and connect to the MCU via UART. There is no packet structure standard to follow, so we implemented our own. The Bluetooth protocol is described in detail in Appendix D: Bluetooth and HC-05 Bluetooth Configuration and Usage.
While testing our modules we used the RS232 protocol via a MAX232 converter to probe Bluetooth communication on the PC. However, we removed all traces of the RS232 probe from our final board to reduce our hardware footprint and to make the unit fully wireless and mobile.
Relevant Copyrights
Both of the MCU’s that we use in our project are running the Tiny Real Time kernel developed by Dan Henriksson and Anton Cervin at Lund University. TRT was originally a kernel developed for the Atmel AVR Mega8 microcontroller. The version we use has been modified by Bruce Land, ECE 4760 instructor, to run on the Atmel AVR Mega1284.
We use a modified LCD library and header from scienceprog.com to initialize and communicate with the LCD screen. Modifications were made and documented by ECE 4760.
To help develop the step algorithms of our project we looked at an ECE 4760 final project: “Intelligent Wireless Pedometer” by Andrew Chin and Ping-Hong Lu. This project was reviewed for its information about how to find speed from acceleration information, a feature that we ended up not including in our final product. We also looked at the ECE 4760 project “A Wireless Programmable Pace Clock” by Paul Swirhun and Shao-Yu Liang for their implementation of a Bluetooth module. However, in our project we chose to use a much different, much cheaper Bluetooth module than this project. Finally, we looked at various A/D converter code examples on the ECE 4760 website to implement A/D conversion. Further discussion of relevant existing patents, copyrights, and trademarks is included in the Conclusions Section.
Hardware
Hardware Overview
As mentioned in the high level overview, our project consists of two main hardware units: a foot module and a wrist module. The electrical schematics for our design are included in Appendix A: Schematics. A table of all ports used on both microcontrollers is included below. We will now examine the hardware on each module in detail.
Hardware Design: Foot Unit
The foot unit connects to a 1.5g accelerometer orientated with its positive measurement axis pointed away from the center of the Earth. This direction will now be referred to as the z-axis. The implementation or our original idea uses an additional accelerometer oriented with its measurement axis pointed perpendicular to the z-axis parallel to the plane of the solder board it is mounted on. This axis will now be referred to as the x-axis. The figure below illustrates these axis.
The analog acceleration data from either accelerometer is very noisy. To filter out this excessive noise, the accelerometer data passes through a low-pass filter with a cutoff frequency around 33 Hz using a 10kOhm resistor and 470 nF capacitor on the z-axis accelerometer. The x-axis accelerometer, when still evaluated, was passed through an identical low pass filter. However, after we decided not to use this data, an extra 110kOhms were added to the filter due to confusion of accelerometers in an attempt to clean up noise. Since the addition of this resistance has no effect on the system and due to time constraints, they were not removed. Additionally, to fully utilize the 10 bit range of the internal A/D converter we drop the voltage across a 20kOhm resistor. There are also various indicator LEDs and a hardware switch on the foot module to reset the accelerometers as needed. This reset functionality was described in detail in the hardware/software tradeoffs section of the high level overview.
Once the MCU takes in acceleration information, it uses software to determine what to package up and send to the wrist unit over Bluetooth. The Bluetooth chip on the foot unit acts as a slave device. It can both send and receive information from the master Bluetooth device located on the wrist. The Bluetooth transceiver is attached to the MCU through USART0 and pairs with the master Bluetooth device prior to use. The Bluetooth module we use, the HC-05, communicates via UART lines that can be directly hooked up to the RX and TX ports of the MCU. A detailed description of the Bluetooth protocol and instructions on how to start up, set-up, and configure the HC-05 Bluetooth modules are included in Appendix D: Bluetooth and HC-05 Bluetooth Configuration and Usage. To attach the foot unit to the user, we use state-of-the-art duct tape.
Hardware Design: Wrist Unit
The wrist unit connects to a 16×2 LCD display, a number of user input buttons/switches, status-linked LEDs, and a Bluetooth transceiver. Two of the buttons on the board are used to raise or lower a number that is displayed on the LCD screen when the wrist module is in configuration mode. The user is first prompted for their stride length — the average length of one step — then their targeted speed in minutes per mile. The interface task can be triggered at any time by toggling the one switch on the board. The user must press the enter button twice to exit configuration mode.
In pace display mode, the LCD displays the user’s pace in minutes/mile, desired pace in minutes/mile, and cumulative step count. Additionally, we have a red LED on the board that toggles every time a step is detected. The software on the MCU manages all of these tasks.
Software
Software Overview
To facilitate timing and concurrent processes, we use the Tiny Real Time (TRT) Kernel developed by Dan Henriksson and Anton Cervin at Lund University on both microcontrollers. This kernel allows us to schedule and run several tasks at once. It also implements semaphores to protect shared resources. The figure below shows the flow of data through our system and what information each module sends to the other.
Below is a table of all of the functions in both the foot and the wrist modules. The important ones will be explored in further detail.
Software Design: Foot Unit
The foot unit has 2 main tasks. First, the MCU reads the result of the A to D conversion once every approximately 1 ms. We control the polling of the ADC by setting the ADSC bit, which kicks off an A/D conversion, only when the poll ADC task is scheduled. That task is put to sleep for 1 ms after every execution, which is plenty of time for the 13 instruction conversion to run. The A/D conversion itself is set to have a prescalar of 128. That means that if it were running continuously we would start a new conversion every 8 us:
However, the scheduling of the ADC task slows this down so that we have better accuracy on our step detection. We utilize two ADC channels, one for the z-axis acceleration data and one for the x-axis. The x-axis channel is an artifact of our original implementation, and the data it produces is not actually used in our final product. We left it there as a proof of concept and to preserve our original timing and scheduling, around which our hard coded thresholds were determined. We were reluctant to remove the x-axis channel due to its unknown effect on our thresholds, and our time constraints. So effectively, we poll the z-axis accelerometer roughly every 2 ms.
After polling the z-axis data, if we determine that if it is above a certain threshold, we package the z-axis acceleration and send it over Bluetooth to the wrist module. After polling the x-axis data, we add it to an accumulator variable that holds the sum of all accelerations seen since the last footstep. It also contains an overflow variable that increments every time the accumulator overflows.
The second task is to scan the Bluetooth channel for any packets received from the wrist unit. In particular, the wrist unit sends a packet to the foot for every step it detects. Should the foot unit see this acknowledgement, it sends the accumulated x-axis acceleration and resets the accumulator variable. The packet structure for z-axis and x-axis data are show in the figure below:
Software Design: Wrist Unit
The wrist unit software can be divided into three concurrent tasks. First, we have a configuration task. This task runs on power up and interfaces with the user via buttons, switches, and the 16×2 LCD screen. It sets global variables as needed that are used later by the update LCD task.
Our next task is to scan the Bluetooth channel for packets arriving over the USART interface. Because we are scanning for a certain input pattern, our task will hang indefinitely if we do not see the correct packet structure. This problem is an area of improvement that is expounded upon in our conclusions. Once a correct packet is received and unpacked, we analyze the received data to detect steps, as described below in the Step Detection Algorithm section. If a step is detected, we save relevant data to global variables and then continue to process more packets.
The last task managed by the wrist unit is printing to the LCD screen. This task is decoupled from our Bluetooth receive task. The shared variables between the tasks are protected by semaphores for atomic reads and writes. By decoupling the tasks the wrist unit can both continuously receive packets from the foot and also process those packets to calculate velocity. The velocity calculation algorithm is described below in Velocity Calculation Algorithm. After calculating the pace in minutes/mile, that value is displayed on the LCD. Additionally, the LCD update task takes raw data from the global variables updated by the configuration task to calculate and display the desired speed. Finally, the LCD task displays the step count as calculated by the Bluetooth receive task.
Step Detection Algorithm
Our step detection algorithm is based on the physics of human movement. Z-axis acceleration spikes when the foot hits the ground and rises up again: both sudden changes in velocity. For reference, we have included below the low-pass filtered output of our z-axis and x-axis accelerometer data. Note that approximately, 0V = -1.5 g, 2.5V = 0g, and 5.0V = +1.5g.
When a step “ends”, i.e. a foot lands on the ground, the z velocity changes from negative to zero. The z-axis accelerometer is oriented such that this velocity change produces a positive acceleration spike. Thus, the MCU observes a large positive spike in acceleration. The low pass filter on the Vout of the accelerometer removes high frequencies and produces a smooth acceleration spike.
We isolate values of interest on the foot unit by only transmitting acceleration values that exceed a hard-coded threshold, which is set to slightly above +1g. If we achieve +1g, we are likely to have taken a step. We also need to collect large accelerations around the maximum acceleration to calculate jerk. So, we send all accelerations above that threshold. In this manner we capture the “tops” of the peaks in acceleration, which are the areas necessary to compute the local acceleration maxima. Values of interest also include periods where the jerk is high in magnitude. This is to capture the non-dominant leg steps, or steps using the leg on which the foot unit is not attached, as explained under our Background Math section. Each z-axis acceleration sent from the foot to the wrist also includes a timestamp, as determined by the TRT kernel running on the foot.
On the wrist side the Bluetooth receive function does further processing to detect a step. If the jerk crosses x= 0 from positive to negative, then we have found a local maximum in acceleration. We then run another set of tighter thresholds and check if the acceleration point we’re claiming to be a peak is actually high enough to be a peak. We set this tighter threshold based on empirical data collected from the user. Next, we debounce the peaks. When testing our unit on an actual person, we noticed that there would often be a “double bounce”, where on one footfall there were two peaks that exceeded the threshold we had set. This possibly occurs due to the construct of the accelerometer, or the low-pass filter on the accelerometer output. So, we empirically determined that any two peaks within about 200ms of each other would only count as a single step. Finally, if an acceleration data point passes all of these constraints, the wrist determines that a footstep has indeed occurred. It increments the global step count variable and records the timestamps from that packet as the time of the last step.
Velocity Calculation Algorithm
We implemented two velocity calculation algorithms. Our original algorithm utilizes the x-axis accelerometer as well as equation (2) in background motivation to calculate the velocity. However, this approach did not yield accurate results for reasons described in the Conclusions section. So, we decided to implement a different velocity calculation based on the user-defined length of stride.
In our original algorithm, the wrist unit alerts the foot that a step has been detected. The foot has been continuously accumulating the x-axis accelerations. When it knows that a step has occurred the foot sends over its accumulated acceleration data along with the time since the last footstep. The wrist unit receives this data in the Bluetooth receive task and places it in a global variable. In the LCD update task, which has less strict timing constraints, the wrist unit does a float division of the accumulated acceleration data by the time difference along with several unit conversions to determine the final velocity. We fully implemented this algorithm. However, after extensive testing and adjusting of parameters, we concluded that with a one-axis accelerometer it simply was not possible to accurately measure the x-velocity using this technique. We then decided to rethink our approach.
With our second velocity algorithm, in the Bluetooth receive function every time a step is detected the function shifts in the timestamp associated with that step into a sliding window averager with four slots. The LCD update function checks this sliding window and calculates the time difference between the first entry in the sliding window and the last entry. It then performs a speed calculation by multiplying the user’s input stride length by four and dividing by the total time between those two steps. A couple unit conversion later and we have an average velocity over four steps ready to be displayed on the LCD. The size of the sliding window averager is a tradeoff between resilience to outliers (large window size) and fast response to new data (small window size). Through testing we found that a window size of 10 tended to take too long to initialize and update with new velocity information. A window size of 1 was far too susceptible to variation in footstep timing. Thus, we settle on a window size of four. The average can eliminate small variations while still responding quickly to new data.
Testing and Results
Testing and Development Process
At every point in the development of our project we unit tested both hardware and software. We had an incremental approach to design. We began by getting the accelerometers working. It is at this time that we realized that the datasheet pinout diagram for the MMA2260D is incorrect. To incrementally verify the operation of the accelerometers, we initially looked at just the analog output with an oscilloscope. We then connected the accelerometers to the A-to-D conversion channels of the MCU and printed the converted digital values to a UART debug terminal on the PC. Once we verified that digital values corresponded to analog values, we began the process of implementing Bluetooth communication. We utilized the stdio library to send and receive Bluetooth packets through a file stream. We directly probed the MCU-Bluetooth wired and wireless interactions using a separate RS232 with MAX233 converter connected to the Bluetooth and/or USART channel. This probe does not affect the timing nor operation of the MCU and allows us to debug without modifying the state of the system with costly fprintf statements. After successful implementation and verification of the Bluetooth link, we began experimenting with different footstep detection algorithms. Concurrently, we began implementing the user interface: LCD, pushbuttons, and switches. This was an easy hardware task to test as it was our primary user interface and therefore easily accessible.
We initially encountered problems due to conflicting stdio library definitions caused by a mismatch between AVR studio versions 4.15 and 4.19. This error was marked by the board resetting upon any print statements. to get to the root cause of this error, our debug strategy was to remove functionality until the problem disappeared. We then isolated and analyzed the segment of code where the bug originated, which ended up being any print statements. Because print is an imported function, we rightly suspected the libraries as the source of the problem, and asked our peers for suggestions and insight as to why a problem might arise. Another debug strategy, especially important in the presence of synchronization semaphores and concurrent processes, was to stress test our system. For example we made the foot send data as quickly and as frequently as possible to stress the Bluetooth link. Using this strategy in conjunction with RS232 probes, we discovered an unprotected fprintf statement from the foot unit that caused hangups on the wrist unit.
Speed of Execution
The clock frequency of both boards is 16MHz. The Analog to Digital Converter completes one conversion per channel approximately every millisecond, and we are using two of the eight channels. Our LCD is updated approximately every 300 ms with the newly calculated pace, desired pace, and number of steps. We chose 300 ms arbitrarily to give the function more time to process incoming packets from the foot unit and because it is not crucial for the LCD to update exactly at the human reaction speed.
We also tested and measured the latency between sending the acceleration data from the foot to receiving and processing the data on the wrist. The table containing test data from Ellen, one of the team members, lists the average latency from the last step to the last update of the LCD display. When about 90 steps were detected there was a latency of 6 seconds from the last executed step to the last update. When 15 steps were detected there was a latency of 3 seconds. Our latency is on the order of seconds. This could be due to the time it takes the foot unit to send a packet being significantly smaller than the time it takes the wrist unit to process a packet.
Accuracy
The tables below show test data taken for distances of 100 ft., 200 ft., and 300 ft. with a stride length of .74-.75 meters on Julie Wang. Julie is a female team member who is approximately 5’8”. All tests were done with a normal walking gait. Actual steps were counted by the test subject. Actual pace was calculated by measuring the time needed to traverse the appropriate distance. The time was converted to minutes, the distance converted to miles, and the two were divided. Stride length was calculated by dividing the distance by the actual number of steps.
As seen here, the step accuracy is reasonably accurate and the average error among all test trials is about 2.3% error. Pace accuracy is a different story and is very likely related to differences between the user’s estimate of his or her stride and the user’s actual stride length when moving. Subsequent tests when Julie tiptoed or stomped around resulted in low accuracy in both pace and step detection. The wrist unit correctly detect approximately 50% of steps. This was due to our hard-coded thresholds that were optimized for a walking gait and misalignment of the foot unit.
We have also included below the data of the normal walking pace of Ellen, a female member who is approximately 5’4”. in order to detect Ellen’s footsteps we had to use different thresholds on jerk and acceleration, as well as carefully align the z-axis accelerometer parallel with the direction of gravitational acceleration.
One thing to note about the pace calculation is that in reality, someone’s stride length varies over time, especially when they are initially beginning to move and when they are slowing down. Because the speed calculation depends on user input, it is important to properly measure and input one’s stride length as the accuracy of the speed calculation depends on it.
Safety
Our design does not currently have electrical components that are in direct skin contact, nor do we expect high current draw beyond a few microamps. Should we further our implementation, however, we will likely compress the size of and encase the leg and wrist unit in electrostatic discharge (ESD) resistant material, as friction from movement may cause ESD. We would also encase both units in water and mud proof casings. Many times running or walking weather conditions can take a turn for the worse, or there may be puddles, water, or mud on the ground. To avoid harming both the user and the actual devices, it would be important to properly encase the wrist and foot modules.
There is a risk of the foot module falling off and potentially tripping or otherwise impeding the user. To mitigate this risk we rebuilt the entire foot module on a specialized PCB. All components are soldered down and the unit itself is firmly harnessed. Better harnessing practices that could be used include securing the device to the ankle with a strap or even securing the foot unit to the top of the shoe, the tongue of the shoe, or on the shoe laces.
Another possible risk is that the user, while looking down at their wrist unit, would not be paying attention to his or her surroundings and could either run off the road or impact another object. Unfortunately this is an inherent risk with any devices used while running or walking. However, we believe that our device is actually less prone to cause harm in this way than devices like a waist pedometer or a phone app. Rather than having to bend down and look at one’s waist or dig up one’s phone, it is pretty quick and easy to glance down at a watch unit on the wrist.
Interference with Other Designs
Our module utilizes Bluetooth to transfer data between the foot and wrist units. However, there is little risk of interference between our module and other Bluetooth enabled devices. By design, the Bluetooth protocols employs frequency hopping, which means that the transceiver automatically scans, finds, and utilizes unused bandwidth to avoid RF interference with other modules.
Usability
This system is optimized for use on or near the foot. It is capable of detecting steps for normal walking gaits. However, as seen in our test results, hard-coded thresholds are very finicky and must be calibrated specifically to a person, and it is very possible for the system to fail from person to person and even on a day to day basis. When the system was working for one team member but not the other, lowering the acceleration threshold allowed us to accurately detect the second team member’s footsteps. However, this isn’t really a practical way to go about calibration.
If a user is unable to place the device on his or her foot, our “foot” module is sensitive enough to still work on the hip or thigh of a user. However, the accuracy will be diminished due to missed footsteps as the step signature will have changed. At the hip level, we expect a diminished but still large acceleration spike on the dominant leg, and a much more diminished spike on the non-dominant foot. These changes in acceleration are smaller than the changes when the foot unit is placed on the foot, and our pedometer may not be able to detect steps. Also, due to the nature of our step detection algorithm, if the user is unable to move in a bipodal manner, our system will not function properly for him or her.
Conclusions
Accomplishments and Further Extensions
Our goal for this project was to design a wireless pedometer and speedometer for keeping track of a user’s walking or running pace using microcontrollers. We have met these expectations. we have implemented two algorithms for detecting pace, one that measures the average walking pace reasonably accurately and a one that is a full proof of concept. Though we did not reach the level of accuracy that we wanted, we are pleased with what we have accomplished. There are several things we would do differently given more time.
Through the testing process we discovered that our use of the fscanf function included in the stdio library would sometimes cause the wrist unit to freeze. Even though we had semaphore protection on the foot’s packet sending, improper formatting of Bluetooth packets would halt our system. We suspect that when packets were sent very quickly, a value in the transmit buffer was overwritten. Decreasing the send rate also decreased the frequency of hang ups in fscanf. However, a more robust and complete solution would be to build a receive function that can recover from these send errors.
In order to accurately measure a runner’s pace without assuming a stride length, we need a 2- or 3-axis accelerometer. This is because in order to remove the requirement for a calibrated stride length, we need to know the lateral velocity instead. This velocity can be isolated from a 3-axis accelerometer, but not from a 1-axis accelerometer. Using a 3-axis accelerometer, we would first determine the gravitational acceleration vector using the z-axis data. Once we have this, we can calculate the acceleration vector in just the forward-moving direction. The crucial difference is that using a 3-axis accelerometer, we do not have to worry about alignment issues of the foot with the user’s direction of motion. We know all three axis, so we know the exact position of the foot in space. Using some vector calculations, we can extract just the forward moving velocity vector. When using a 1-axis accelerometer, the only information we have is the acceleration in a single direction, which may or may not correspond to the user’s actual direction of motion. Unfortunately we came to this realization late in the design cycle. Our hope is that future students who may attempt a similar project will read our report and not make the same mistake.
Perhaps the difference that would create the largest impact would be implementing dynamic acceleration and jerk thresholds. We currently hard code thresholds for step detection, and these values need to be re-tuned given different environments. As seen in our test data, our algorithm differed from person to person, day to day, and could possibly differ on a chip to chip basis. Hard-coded threshold values are quite sensitive, must be carefully measured and tuned, and are in general too specialized to be of much use. One thing to note about dynamic thresholding is that we need to anticipate the difference in acceleration data between a step with the dominant leg (the leg with the foot unit attached) and a step with the non-dominant leg. Although these accelerations differ, we can still capture both footsteps by looking at the jerk over time. This is because even though the acceleration on a nondominant leg step is not greatly positive, there is a large change in acceleration, which corresponds to a measurable jerk.
We would also have liked to reduce the footprint of our design. Due to the fact that our final design does not use one of the accelerometers on the board, we could scale down both the hardware footprint and the size of our code to better fit onto a leg/ankle and wrist. We would also have liked to have a better harness than duct tape. As versatile as duct tape is, it is not the best harness, and we encountered some hardware problems and connection shorts that probably would not happen if we had a better method of mounting the board. Lastly, it would be nice to have been able to clean up our user interface. We would remove unnecessary LEDs and implement an optional LED system to notify users how their current pace is matching up to their desired pace. We could the devote the second row in the LCD display to show the number of steps.
Some extensions that could be explored include implementing a stop watch/watch function and linking the pedometer to a smart phone. A stop watch could easily be implemented using timers on the MCU and some extra user interface to switch between a ‘stop-watch mode’ and ‘normal mode’. We could also extend the stop watch into an actual watch that displays the time. After an initial set of the time, we could track the time of day using an external crystal that is always powered. As for linking to a smart phone or even laptops, we deliberately chose to use Bluetooth as a means of wireless connection to allow connection with other Bluetooth devices. The pedometer could collect data and sync to a phone or computer application for long-term step and pace tracking.
Did Our Design Conform to Standards?
The HC-05 Bluetooth module is a Class II Bluetooth device that operates in the 2.4-2.485 GHz Industrial, Scientific, and Medical frequency band. As a licensed Bluetooth device, this module complies to Part 18 of FCC standard. It also employs a UART link for its host controller interface, the details of which are entailed in Appendix D: Bluetooth and HC-05 Bluetooth Configuration and Usage. Communication in AT mode (configuration mode of the HC-05) was conducted at 38400 baud. Functional communication of data was conducted at 9600 baud.
Intellectual Property Considerations
Our code is built upon the Tiny Real Time kernel developed by Dan Henriksson and Anton Cervin at Lund University in Sweden.
The LCD library source and header files are from Scienceprog.com.
Our uart code for communication with the Bluetooth modules was edited from general code developed by Joerg Wunsch and modified by ECE 4760 course staff for use in the TRT kernel.
Our pedometry algorithm was inspired by various papers (See References) and previous pedometry projects in ECE 4760 such as Exercise Monitoring System by Tim Hu and Aaron Ho (we especially liked the inclusion of jerk) but the details of our particular implementation were our own design.
The rest of the code is our own.
Ethical Considerations
We adhered to the IEEE Code of Ethics throughout the development of our design. In particular, and most applicably, we made every attempt to be “honest and realistic in stating claims or estimates based on available data” by sharing our unedited test data. If our test data shows an area of improvement for our design, we address and publicize our errors on this site rather than making false claims on the performance of our pedometer. Similarly, we “seek, accept, and offer honest criticism of technical work, to acknowledge and correct errors, and to credit properly the contributions of others.” This project would not have been successful without critiques and suggestions from ECE 4760 staff and peers. Throughout the development of our design, we sought advice from the ECE 4760 staff. We discussed tradeoffs of different implementations such as our proof of concept, where to put our foot unit, how to communicate to Bluetooth, our pedometry algorithm and more between ourselves and with other ECE 4760 project groups. For example, when determining where to place the “foot unit” we consulted Bruce Land, instructor of this course, about the optimal placement to get the highest accelerations and de-accelerations. When faced with the software tradeoff of doing algebraic computations or A/D conversion, we consulted Cameron Glass, a teaching assistant in this class, about how to count cycles and squeeze in useful work between conversions.
We also strove 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” by teaching, evaluating, and asking ECE 4760 staff and peers best practices. For example, we learned a lot about good soldering practices through talking to the qualified people around us, and were able to share that knowledge with other people learning to solder. Lastly, we “assisted colleagues and co-workers in their professional development and to support them in following this code of ethics.” When a project doesn’t quite meet up to full expectations, it is tempting to want to edit out bad test data and present a fully successful project, as all members in this group have experienced. However, that would also be incredibly unethical, as we would be outright lying about our performance. We encouraged each other to remain ethical in our conduct and to provide as accurate a report as possible for anyone reading this right now.
Read more: Wireless Pedometer