Footprint Detection

8/3/2019 Footprint Detection

1/29

Our ECE 4760 design project integrates three differentkinds of sensor measurements to track a user s movement speed, regularity of gait, force on impact,pronation of foot, as well as other information that may beuseful to a podiatrist. We believe there is a need for acheap metering tool that can be used to log long-term datafor later interpretation by a podiatrist.

Rationale and Sources of Inspiration:During normal walking motion, our feet absorb the shock of impacting the ground by rolling inwards towards the centerof the body, distributing weight evenly across the entire

foot. Unfortunately, only a quarter of the population areconsidered "neutral" footed, without any noticableproblems with their gait. Half the population suffer fromover-pronation, where the feet roll too far inwards causingundue stress to the arch of the foot. The remaining quartersuffer from the opposite problem, supination. Problemsassociated with incorrect walking form include knee/ankleinjuries and foot pain. We hope our project will help

podiatrist analyze the problems associated with over-pronation/supination by providing an affordable datameasurement/logging device. Using an integrated SD card,each patient would be able to provide weeks worth of datato the podiatrist, capturing the many activities weencounter throughout the day. Treatment and customothropedics can then be personalized. We imagine ourproject would also have sports applications, as the data can

help improve the form of the user.Inspiration for this project came from many directions. Theoriginal idea was conceived of during a lapse in productivityin a brainstorming session. One group member curiouslyasked why the outside edge of the other member's shoewas much more worn out than the inside edge. Wikipedia


2/29

quickly provided the answer, and soon we had a workingproposal. Further motivation came from the fact that thegroup member suffers from knee pain, one of thehighlighted symptoms of supination. Our professor, BruceLand, supported our idea and provided further ideas thatextended off our basic premise.

Sources: http://www.runwashington.com/archive0209/features/brieforthoticsquestion.html

High Level Design

Our project consists of three main functions1. Data Measurement2. Data Processing3. Data Storage/Output

Data MeasurementOur data measurement function primarily replicates theabilities of an inertial measurement unit in a more specifiedmanner. We considered purchasing IMUs directly fromSparkfun, however we decided to save on costs bysampling accelerometers and gyroscopes separately andimplementing signal processing in the microcontroller.Since the ATMega644 has eight channels of analog-to-digital converters, we were able to include force-sensitive-resistors (FSRs) to our project. These resistors greatlydecrease in resistance when a force is applied to thesurface. By placing the sensors in strategic locations, weare able to figure out relative force distributions across thefoot. Initially we sampled a digital output gyroscope fromAnalog Device. We had great difficulties with soldering thetiny packaging to a breakout board, and once it wassoldered we could not get the device to interface via SPI.
http://www.runwashington.com/archive0209/features/brieforthoticsquestion.htmlhttp://www.runwashington.com/archive0209/features/brieforthoticsquestion.htmlhttp://www.runwashington.com/archive0209/features/brieforthoticsquestion.htmlhttp://www.runwashington.com/archive0209/features/brieforthoticsquestion.html


3/29

Because we had room in our budget and to save on time,we ordered an analog output gyroscope from Sparkfunbecause we had already successfully set up multiple ADCreadings with the accelerometers and FSRs.

Data ProcessingData processing conducts multiple functions to sense usersteps, detect the pronation of a user, log their angularmovement of the foot as it moves through the stride, aswell as output curves of the user. By using the network of sensors embedded in the shoe, a basic model of how theuser moves about can be generated.

Data Storage/OutputWe began our design with a simple writing to EEPROM tostore data values after shutdown, however we quicklyrealized that this would not be an acceptable solution sincereading from EEPROM requires AVR studio and moreimportantly, our dataset would be limited to around 2000values. With a sampling rate of 100 ms, this turns out tobe about four minutes worth of values for just oneaccelerometer. After examining past projects, we decidedthat an SD card interface would be the best way to storelarge amounts of data and easily transport it from the shoeto a desktop computer. Once on the computer, the valuescan be parsed by MATLAB or some other custom programand the dataset can be easily plotted to reveal patterns inthe user's stride.

We also considered using an LCD screen to view the analogoutputs and used one during the early testing phases of the project. However, as we began integrating thehardware into the shoe, we relied more upon outputs toPutty via the serial port, and eliminated the LCD displayentirely. If we are able to achieve wireless function, we


4/29

may explore the possibility of sending data wirelessly to areceiver point, and then displaying it via LCD, maybe like awatch.

A wireless RF transmitter and receiver pair was alsoattempted, but after failed attempts in getting the USARToutput to sync properly, the wireless portion was scrappedin the interest of time. The original design was to attach aTLP 434 transmitter to the TX pin on the microcontrollerwhile setting up an rf "sniffer" with the receiver feeding itsoutput to an FTDI232R chip which interfacted to acomputer via USB. Essentially, the wireless implementationwould have almost no overhead compared to the wiredversion except for the lack of a wire. It was found thatwireless noise de-synced the USART communicationbetween the MCU and the FTDI232R chip, so jumbledgarbage was received. A brief attempt was made atcreating packet headers to ensure reliable transmission,but was halted due to time considerations.

Software Design:Our software is broken up into three main modules muchlike our high level design. Final_Project.c/.h, maintainsprogram control flow and data collection. We modularizedthe signal post processing in calculations.c/.h and SD cardfunctionality in sdcard.c/.h to promote independent paralleldevelopment. We have future plans of rewriting theprogram to be multi-threaded so that all of our monitoringtasks can be simultaneously run and output to a functionalGUI. Much of the code for accessing the SD card wasadapted from prior ECE 4760 projects. It utilizes the FatFShardware abstraction layer system, which provides a very


5/29

intuitive API for handling the specifics of integrating the SDcard.

Top Level System Architecture (from Project Proposal)

Main ControllerUnlike previous projects, we did not find a need to build astate machine to manage program state. Instead, we setup Timer0 to trigger an ISR every millisecond, which isresponsible for managing the timing of several crucialcomponents. It decrements a program counter to triggerthe sensor readings every 100 ms. The FatFS specificationrequires that a time and date stamp be provided to it,which is implemented by a several counters variables thatis incremented within the ISR. Additionally, we decrementone additional timer at a rate of 100 Hz to handle the delaytiming for the SD card.

Our sensor array utilizes three FSRs, two accelerometers,and one dual-axis gyroscope. All our sensors utilize analogoutputs, therefore we utilize seven out of eight ADCs on


6/29

the ATMega644. To switch between the different channelsof the ADC, we assign the 3-bit binary value correspondingto that channel to MUX2:0 bits in the ADMUX. It isimportant to maintain a logic high in the REFS0 bit of ADMUX throughout the changing of ADMUX. One of ourinitial problems was ADC output values that werenonsensical because the ADC was referencing the value of the input to some arbitrary AREF, instead of Vcc.

Unlike previous labs, we wanted the full 10-bit resolution of the ATMega644's ADC. A wrapper function, read_ADC()writes a logic high to the ADSC bit in the ADCSRA to startthe conversion. The conversion takes an unspecifiedamount of time, therefore the only way to ensure propertiming is to trap the execution of the program in a whileloop as long as the ADSC bit remains high. Once ADSCgoes low, the conversion is finished and both ADCL andADCH can be read. The datasheet specifies that ADCL mustbe read before ADCH, otherwise the results of anotherconversion may erase the values in the register. For

simplicity's sake, we chose to right align our data outputs,meaning the 8 least significant bits of the data will be inADCL, and the 2 remaining MSB will be in ADCH.Combining the inputs simply requires a logical OR betweenADCL and ADCH left shifted by 8 bits.

Rather than write each reading to the SD card at the end of a full set of ADC conversions, we chose to store it in a

buffer. Once the buffer is full the program calls the helperfunctions in the SD card module to write all the values inthe buffer to the SD card. Writing to the SD card requires asignificant amount of time relative to reading from the ADCvalues. We chose to have a longer delay, on the order of several seconds, every 100 readings of the ADC rather


7/29

than having a delay at the end of each ADC read. Usingthis method, our program requires more data memory,increasing usage by about 30%. If we were close to ourbudget, we could have opted to use ATMega16microcontrollers instead, and run the ADC conversions at aslower rate.

Data MonitoringA debug mode of our device allows the microcontroller toread ADC values from all its devices and print them out ina pretty format for analysis. In a medical application, theshoe can then constantly stream data through USART as

strings for post processing on another machine.Step Detection ProcessingWhile we were collection data, it was discovered that wecould implement step detection in multiple ways. Both theFSRs and the accelerometers output consistent enoughdata that both the falling and rising acceleration or theimpact of the foot pressing into the ground and releasingfor the next step could be used to detect a step. In ourdesign, we elected to use the accelerometers to implementa three-state state machine to detect and debounce a step.When the ADC value of an accelerometer surpasses a setthreshold value, the state machine goes to a "STEPUP"state where it has detected a rising foot and will await forthe falling sequence. If the falling sequence does not occurwithin 0.8 seconds, the state will timeout and return to awaiting, "TRACKING," state. If a falling acceleration occursbefore the timeout and surpasses a falling threshold, thena step is said to have been taken. In field tests, we foundthat by adjusting the threshold values, we were able tostep detect quite well.

Currently, step detection keeps track of the number of


8/29

steps taken. We could have also multiplied the steps takenby an average stride length to display approximatedistance walked.

Pronation DetectionPronation detection is also done via a state machine, but inthis case, we elected to use the force sensors. Pronationdetection triggers when the heel FSR force surpasses a setthreshhold to signal the heel taking most of the subject'sweight as they roll toward the front of their foot. The statemachine then waits a short period for the front sensors tosurpass their respective thresholds during a certain timeout

window. If a forefoot force is detected, the exact forcesensor that fired is located and depending on its physicallocation, pronation or supination can be determined.

We were originally planning to use our gyroscope to detectthe exact degree of rolling that a foot undergoes whenmakign a step, but conversions and integration of the ADCvalues from the gyroscope resulted in degree values that

drifted linearly. This drift made most of our programminguseless, so in the end, the more simplistic FSRs were used.

Writing to SD cardAs previously mentioned, our project makes extensive useof the work done by previous ECE 4760 students as well asthe FatFS system. In particular, we referenced thefollowing ECE 4760 projects:Adaptive Alarm Clock GPS Data Logger

One of the reasons we chose to use SD cards for our datastorage was because the interface is accessible via SPI,which is easily implemented with the ATMega644.Essentially, FatFS modularizes all the commands and
http://people.ece.cornell.edu/land/courses/ece4760/FinalProjects/s2009/jsm66_mpk28/jsm66_mpk28/index.htmlhttp://people.ece.cornell.edu/land/courses/ece4760/FinalProjects/s2009/jsm66_mpk28/jsm66_mpk28/index.html


9/29

timing so that the user only needs to worry about settingup the microcontroller with the right SPI configuration. Thisis done in mmc.c . As per the documentation on the FatFSwebsite, the microcontroller should be set as the master,and the phase and polarity both set to logic low. Within theinitialization function of mmc.c , pins B.4(Chip Select),B,5(MOSI), and B.7(SCLK) are set to logic high todesignate those pins as output. Fortunately, the twoprevious groups modified their mmc.c to work with theATMega664, and we had no difficulties from a softwareperspective. We did have issues when we first tried toimplement the SD card because of hardware problems,which will be discussed in the next section. To set the SDcard to communicate via SPI, the following intializationprocess must be completed:

1. Set the SPI clock to 125 kHz2. Wait 80 clock cycles by transmitting a generic SPI

command ten times3. Send CMD0 to enter SPI mode in idle mode4. Determine what type of card (SDHC/SD/MMC) by

sending the following commmands in order, until onereturns a logic high: CMD8, ACMD41, CMD1

5. Restore fast clock rateWriting data to the SD card accessed by calling helperfunctions provided by FatFS. The file is first opened bycalling f_open() passing in the pointer to the FResult objectas well as the access type. Writes are done by formatting astring using snprintf and passing the FResult pointer, theformatted string, and the length of the data to be written.FatFS hides the implementation details such as the specificcommand to send as well as the number of commands(since only eight bits of data can be sent at once through


10/29

SPI).

FatFS is distributed free of charge without any licensesrestricting usage.

FatFS diagram

Hardware DesignFor our project, we used the following hardware functional

blocks: ATMega644 Target Board Freescale MMA1260D Accelerometer Sensitronic/Interlink Force Sensitive Resistors LPR503AL Dual-Axis gyroscope SD Card Module 5V to 3.3V Voltage Converter


11/29

Hardware Integrated into Shoe

ATMega644 Target Board:The ATMega644 target board provides the user with asmall, portable platform to interface with the ATMega644chip. All necessary protection resistors and bypasscapacitors are provided in surface-mount format and

mounted on a custom designed PCB. The PCB routes theport pins of the ATMega644 to pins on the edge of theboard, which makes interfacing with other hardwareelements much easier. We used a 16 Mhz oscillator withour ATMega644. The target board was designed by ourprofessor Bruce Land. One major change from previousversions of the target board is the inclusion of a USB portfor debugging purposes. We prefer using the FT232R USB-

to-serial UART iterface because we do not feel confident inthe quality of the serial-to-USB converters. We used a LEDto tell us when the board was being powered and active.Because we planned to run the target board on our shoe,we soldered leads to a 9V battery clip.


12/29

Total parts list for the target board:

Mega644-20PU Atmel microcontroller MAX233CPP dual RS232 interface or FT232RL USB female connector LM340LAZ-5.0 regulator CTX077 16 MHz crystal Switch SPDT surface mount AYZ0102AGRL 401-1001-1-ND 2.1 mm power plug CP-002A-ND 9 volt battery clip 84-6k-ND All resistors and capacitors are 1206 surface-mount

packages

Target board PCB


13/29

Target board schematic

More information on the target boards can be found

here: Target Boards All images are property of Bruce Land.

Freescale MMA1260D AccelerometerWe used the Freescale MMA1260D accelerometers donatedto ECE 4760 lab by Freescale Electronics. There were manyvariants with different maximum acceleration ratings, butwe chose the 1260D with a maximum acceleration of +/-1.5g because we preferred resolution over bandwidth.During normal standing position, the accelerometer willread out approximately 1g. We do not think that duringnormal walking motion, the acceleration would exceed thebounds of the accelerometer. We developed a quickprototype by taping an accelerometer to our shoe to verify
http://people.ece.cornell.edu/land/PROJECTS/ProtoBoard476/http://people.ece.cornell.edu/land/PROJECTS/ProtoBoard476/


14/29

our assumption. Another desireable feature of theaccelerometers was the analog output. We were muchmore comfortable using the ADC converter than the SPIinterface. A decoupling capacitor is used between Vcc andground. The analog output signal is filtered through asimple RC low-pass filter to remove the clock noise.

Accelerometer schematic

Sensitronic/Interlink Force Sensitive ResistorsWe used three FSRs underneath the insole of our shoe tosupplement our pronation/supination detection byanalyzing the force on both the inside and outside edge of the shoe. The FSRs vary in resistance greatly as force isapplied to them. Although the decrease is not linear, wecan get a rough idea of relative force. We used the FSR asthe resistor tied to Vcc in a voltage divider. Through trialand error, we determined that a 1K resistor tied to groundprovided the best resolution throughout the range of forcesapplied during normal human gait for the sensors at theball and outer edge. Since less force is on the heel, weused a 330 ohm resistor for that sensor only. As moreforce is placed on the FSRs, the resistance drops and agreater voltage is dropped across the series resistor,leading to a higher ADC value.


15/29

FSR schematic

FSR datasheet


16/29

FSR location on insole

LPR503AL Dual-Axis gyroscopeTo measure the angular movement rate of the shoe, wedecided to use a gyroscope to simplify our data processing.Initially we had received samples of the ADXRS450 digital

accelerometer from Analog Devices. The packaging type of the samples were designed to be surface mounted andwere extremely difficult to solder. We successfully solderedthe small accelerometer to a solderboard, but we wereunable to interface it via SPI. We believe the accelerometermay have been damaged by the heat during soldering.


17/29

Although we probably could have used the twoaccelerometers to accomplish the same function, theanalog output of the gyroscope was much easier to use.The breakout board already contained all the necessaryfiltering capacitors and header pins. We provided 3.3V andconnected the 1X outputs to our ADC and instantly hadresults.

LPR503AL


18/29

Schematic of breakout board

We purchased our gyroscope from Sparkfun: LPR503AL Dual-Axis gyroscope

SD Card ModuleInitially we tried to save on costs by directly solderingheader pins onto a SD card, however that method formedan unreliable connection on the solderboards. We decidedthat the $10 cost of a SD card breakout board fromSparkfun was worth it for the peace of mind. Once thebreakout board arrived, we soldered it onto a largersolderboard. Because the ATMega644 pins output 5V forlogic high, we needed to level-shift the microcontrolleroutputs to 3.3V. We adapted the same circuitry that the"GPS Logger" project used. A diode is placed between the3.3V Vcc and the pin on the SD card. A 1K resistor lies

between the pin on the SD card and the microcontrollerpin. When the pin is driven logic high, the diode isconducting and since it has a low forward voltage drop, theSD card pin is held at about 3.3V. When logic low is driven,the diode no longer conducts and the SD card also sees a
http://www.sparkfun.com/products/9990http://www.sparkfun.com/products/9990http://www.sparkfun.com/products/9990


19/29

logic 0. A 57K resistor is used on the MISO pin as a pull-upresistor.

SD Card level shifter

5V to 3.3V Voltage ConverterOur gyroscope and the SD card interface require a 3.3V

Vcc instead of the 5V provided by the microcontroller.Initially, we used a simple voltage regulator constructedfrom an 2N3904 NPN transistor, 5K resistor, and apotentiometer. While we were experiementing with the SDcard, we noticed that the output of this regulator wasstrongly affected by the load resistance. We would adjustthe potentiometer such that it would output 3.3V. When weattached the SD card, no matter how we adjusted the

potentiometer, the circuit would output roughly 4V. Thiswas out of the SD card specification, and caused majorissues when the microcontroller tried to send SPIcommands.


20/29

Simple voltage regulator

Fortunately, we were able to sample an adjustable voltageregulator from Linear Technologies, the LT1584. The outputvoltage is adjusted by establishing a Vref using a simpleresistor voltage divider. According to the datasheet, theoutput voltage follows the formula: Vout = Vref(1 +R2/R1) + Iadj* R2. The circuit schematic is shown below.Using resistor values, R1 = 330 ohms, R2 = 500 ohms, wewere able to achieve a steady 3.2V output, which is withinspecification for both the gyroscope and the SD card.


21/29

SD Card Module with Voltage Regulator

Simple voltage regulator

More information on the LT1584 can be foundhere: LT1584 The datasheet is provided below in our datasheets section.

Overall Circuit Diagram
http://www.linear.com/product/lt1584http://www.linear.com/product/lt1584


22/29

Overall Schematic

Standards:SD Card


23/29

The SD card standard is defined by a consortium of memory manufacturers named the SD group. Their latestrelease, revision 2.0, can be found here . Our design doesnot implement the full SD card standard because wewanted to avoid additional complexity with implementingthe SD bus. Instead, we implement the part of the SDstandard that utilizes SPI communication.

ResultsData Gathering and ExecutionHardware wise, the circuits that we built performed exactlyas designed. Each of our sensor elements output consistentdata and never failed. We were able to stream data fromall of the sensors out serially while also storing the dataand analyzing it for steps and pronation. Future coderevsions will implement a realtime OS such as Tiny Real-Time so that each function to gather data is run as aseperate thread concurrently.
http://www.sdcard.org/developers/tech/sdcard/pls/Simplified_Physical_Layer_Spec.pdfhttp://www.sdcard.org/developers/tech/sdcard/pls/Simplified_Physical_Layer_Spec.pdf


24/29

Results

Results AnalysisIn the above graph, accelerometer 1 is the left side,accelerometer 2 is the right side, force 1 is the heel, force


25/29

2 is the ball, force 3 is the outside edge of the foot. Weprimarily use the accelerometer to detect the raising of theleg at the beginning of a step and the moment of impact.Both these events have sharp peaks that we look for insoftware. One step is composed of two or three peaks, withthe second or third peak attributed to oscillations uponimpact. We found that the resolution and accuracy of theaccelerometers were not high enough forsupination/pronation detection. Instead, we rely upon ourforce sensors. The current wearer is a known supinator dueto the outside edge of his sneakers being worn away. Asthe force curves show, during normal gait the heel strikesfirst, as shown by the peak of the green line before thepurple or blue. A supinator then rolls along his outsideedge of the foot before putting a minor amount of pressureon the ball. Our graphs clearly indicate this via the hugepeak on the blue curve just before a slight peak in thegreen curve.

Project Scope

The scope of our project had to be reduced after our initialtroubles with the Analog Devices gyroscope and a wirelessimplementation. We feel that although the device lacks anice wireless interface with a computer, the shoe can stillbe invaluable in medical applications as well as hobbyistsapplications. The raw data output enables any adventerousmodder to write their own program to parse the serialoutput which can lead to the use of sensor data in

conjunction to measure jumping airtime, user velocitiesthrough kinematics, stomping forces, and perhaps even agame that uses the shoe as a controller.

Safety:The shoe device poses no risks nor dangers to the generalpublic. All the electronics of the device are contained in


26/29

antistatic bags or a safety box that attaches to the usersankle. This box contains the microcontroller, multiple busboards, voltage regulators, a battery, and the SD Card. Itallows easy access to critical parts of the device whilekeeping everything intact and safe during use.

In order to embed the sensors in the best data gatheringlocation, we hollowed out significant sections of themidsole. Although this allowed us to gather accurate data,it should be noted that the midsole provides most of thesupport in the shoe. Wearing a shoe without a solid amountof support is dangerous. In a commercial setting, thesensors would be embedded into the midsole during theproduction process without affect support.

Interference:The shoe has very few, if any interference issues. The lackof wireless implementation and a secure enclosure preventmost possibilities of radio noise.

Usability:As a medical data logging device, the shoe is quite useableand does a fine job at the price and size of its components.In production all of the electronics would be shrunk and thedevice would be a very good runner-hobbiest device to notonly keep track of distance run, steps, and calories burned,but also amount of force that each part of your foot isdealing with as one walks.

ConclusionsWe feel that our prototype implementation of a proof of concept performed to reasonable expectations. Althoughmany of our fancier features had to be dropped along theway, the core functionality of our device is usable and


27/29

useful. We did obtain our goal of designing and building acheap metering tool for podiatrist or hobbyist use.Refrencing our intial roadmap to our prototype, weachieved every single "Core Functionality" goal as well asabout a third of the "Phase 2 Functionalities."

Future iterations of the device will take the current largeembedded devices and attempt to print them as smallsurface mount pieces on a much thinner flexible conductivesurface. Much of the current project bulk comes from theunavailability of circuit board printing tools. The softwarecontrol programs would also be rewritten to allow

multithread functionality between data gathering functionsand data printouts.

We were unable to implement a few features that we hadplanned to include in our initial prototype. The featureswere RF communication to PC, pronation angle, and usingthe Analog Devices ADXRS450 digital gyroscope. With RFcommunication, a wireless receiveing module was built andthe transmission module was also built, however, we werenot able to set up a noiseless communication channel.Attempts were made to reliably send packets, but timerestrictions forced us to cut this feature out. Timerestrictions were also why exact pronation angle could notbe calculated. The calculated integrated angle had toomuch linear drift to be useful. Finally, a full week of ourinitial lab time was spent construction and debugging ansampled Analog Devices ADXRS450 digital gyroscope. It'sfine pitch surface mount soldering proved to be too muchof a challenge for us. When everything was soldered on, itsent us terrible data through the MOSI and MISO lines. Wesuspect this was due to heat damange to the gyroscopefrom oversoldering. There were a couple of softwareissues. Because the programming is linear, functions to


28/29

measure pronation and functions to measure walking stepscannot be simultaneously run. Future editions of therunning firmware will implement a real time operatingsystem to take advantage of threads and multithreadedrunning of code.

Ethical Considerations:Our project follows the IEEE Code of Ethics and during thedevelopment of the shoe device, no ethical concernsoccured or were brought up. This device poses no threat tothe public and instead is designed to assist the public inenjoying their lives. All the electrical devices on the shoe

are properly electrically isolated from a wearer and theelectronics box also reduces the possibility of an electricalhazhard occuring if and individual wearing our advice wereto end up in a compromising situation.

If used in an actual medical setting, the data obtained withour device could have real implication for patients and mayinfluence doctor opinions and treatment. To uphold the

IEEE Code of Ethics, we need to pay special attention toensure that the data is accurate and reliable. In addition,our design needs to be safe to use for people with healthissues.

Intellectual Property Considerations:The idea of a shoe device to monitor one's movements wasan idea what we both brainstormed. Upon doing someonline research, we found that a similar project wascurrently under research by Erez Lieberman, a graduatestudent in the Harvard-MIT Division of Health Sciences andTechnology. His product, the iShoe, was developed toenable "early diagnosis and rehabilitation of deterioratingbalance for aging adults." To ensure that our project didn'tinfringe upon the iShoe, we moved our design away from


29/29

foot balance to pedometry as well as general hobbyistmonitoring systems.

Societal Impact:

This inexpensive foot monitoring device can be used invarious ways by the public. Podiatrists can use this devicefor simple examinations to determine if a patient isstanding or walking in an unusual way. Casual runners canfind how they are pronated and by how much to determinean ideal running shoe for them. If they'd rather not decidefor themselves, they can also bring in their SD card of running data in to a professional to be analyzed. More

professional runners and/or hobbyists can use the shoe tomonitor their running form and patterns. They can monitortheir force curves to see if their legs are smoothlytransfering weight from foot to foot.

Acknowledgements:We would like to thank Bruce Land for motivating usthroughout the semester. This was by far one of our moreenjoyable labs of our undergraduate careers!

Footprint Detection

Documents

Transcript of Footprint Detection