1 / 25

Acceleration Based Pedometer

CSE 237B Project by Vladimir Ermakov. Acceleration Based Pedometer. Agenda. High Level Problem description Hardware Used/Resources Available Design Implementation Conclusion. Problem Description. Accelerometers today do not measure distance accurately.

noma
Download Presentation

Acceleration Based Pedometer

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CSE 237B Project by Vladimir Ermakov Acceleration Based Pedometer

  2. Agenda • High Level Problem description • Hardware Used/Resources Available • Design • Implementation • Conclusion

  3. Problem Description • Accelerometers today do not measure distance accurately. • They measure the number of steps traveled, and multiply it by some constant step length. • This approach is not good for complex exercise sets, and hiking trips where step length varies.

  4. Goal of The Project Come up with a pedometer that does a better distance approximation.

  5. Two Approaches • Use instantaneous acceleration of the foot to get instantaneous velocity and calculate exact distance traveled. • Use the acceleration of the foot to figure out the mode/style of walking and provide different step lengths for different modes.

  6. Why Approach 1 Failed • The accelerometer I had available is too coarse. • Error gets multiplied by t(10ms) added up 100 times a second and multiplied by t again. • This makes the error multiplied 10000 times for each second • With a regular pedometer the error is only a couple of centimeters a step.

  7. Can We Do Better? • Yes, use modes approximation approach. • Have different modes (My implementation has 2 modes) to measure different step lengths. • Mode1 can be Walking • Mode2 can be Running • Use foot acceleration to decide which mode to use.

  8. What is the Hardware Available • MMA3201D Accelerometer (+-40g) • Two Micro-controllers: • Atiny26L performs A2D on the accelerometer • AT89C5131(32 KB programmable flash) user interface and algorithms. • Connected through a serial interface(UART) • ES13BA0FR LCD display

  9. Design • Two parts: • Sensor • Gets mounted on shoe • Atiny26L performs A2D conversion on Accelerometer output • Sends it to the processing unit upon request • Processing Unit • User interface: LCD, Keypad • Step counting/distance calculation algorithms • Sends requests to the Sensor via UART

  10. More Details • Pressing GO turns on the processing unit. • After displaying the Splash Screen the system enters MAIN state. • From here one can enter the menu by pressing SELECT or start counting steps by pressing GO. • The menu exposes multiple parameters that control the sensitivity of the pedometer.

  11. Parameters • Step Length – distance traveled in a step • Threshold – minimum acceleration to register as a step • Step Time – minimum number of measurements to be above threshold before a step is registered • Recoil – duration of a step. A new step will not be registered during this time.

  12. Illustration of Parameters

  13. States of the System • Stopped • Counting • Paused • Auto-configure

  14. What is Auto-configure • Asks the user to walk 10 steps and uses that as a sample of the mode of walking. • Finds average maximum acceleration of the ten steps, and uses that as a guide when deciding what mode of walking one is in.

  15. Implementation • No OS, just compiler supported interrupt handling • main() with a while(1) loop. • Scheduling is of tasks is performed using timers. • No preemption except for interrupt handling.

  16. Timing • An interrupt handler timer0_irq() gets called every 10 milli-seconds. • Its job is to decrement counters and to read in the current state of the keyboard register. • Several important counters: • power_off_timer • sensor_timer

  17. Serial Communication • The protocol is simple, byte based. • First byte is a start of packet indicator. • Its followed by 6 bytes of data – X, Y, Z • Actually each data parameter is only 10 bits, so 6 bits are wasted per parameter. • Not a bottle neck.

  18. pkt_processSensor() • Responsible for data processing. • Sensor data has to be centered and normalized • Filter out the noise using the threshold specified by the user (High noise to data ratio) • Check step counter • After step gets registered set the recoil timer.

  19. The Menu • Menu is implemented as a key driven state machine • Special cases are the Auto-configure, and Counting states where a special key(KEY_NONE) had to be generated in order to fit the model.

  20. Real Time Issues • LCD updating is done synchronously and is very slow. • First I tried updating the screen every half a second – problems over/under counting steps. (Diagram on next slide) • Solution – to only update the display when a step occurs.

  21. Timing Problems

  22. Testing • Testing was performed by running/walking around the house and block • Did very well counting steps. • Problems with determining modes, actually it barely works.

  23. Reasons for Error • Acceleration does not differ that much between walking and running, so a more accurate accelerometer is needed to perform the job. • Possibly the approach with taking the maximum acceleration can be replaced with taking the average acceleration instead.

  24. Conclusion • Instantaneous acceleration approach is not a feasible option. • Modes of walking approach has good potential, and could be made more reliable if more time and hardware resources were available

  25. Questions? The End

More Related