Open source embedded foot-mounted INS




Open­Shoe is an open source embed­ded foot-mounted iner­tial nav­i­ga­tion sys­tem (INS) imple­men­ta­tion, includ­ing both hard­ware and soft­ware designs. The mod­ule tracks the motion of the foot over the step by means of iner­tial nav­i­ga­tion. The steps can then be summed up to get a rel­a­tive posi­tion of a pedes­trian, as illus­trated above.

The embed­ded imple­men­ta­tion and the step-wise iner­tial nav­i­ga­tion mod­u­lar­izes the foot-mounted INS tech­nol­ogy which facil­i­tates the inte­gra­tion in real­time pedes­trian posi­tion­ing sys­tems, and make it fea­si­ble to equip a larger num­ber of users with foot-mounted INS mod­ules for field per­for­mance tests and coop­er­a­tive local­iza­tion stud­ies. The mod­ules are wire­less and can pro­vide the track­ing infor­ma­tion to, for exam­ple, a smart-phone. Mod­ules can be used on both feet for improved performance.

Gen­eral fea­tures of the implementation:

  1. Embed­ded ZUPT-aided INS
  2. Open source
  3. Wire­less
  4. Dead reck­on­ing updates*

Hard­ware features:**

  1. Four Invensense MPU9150 IMUs
  2. Atmel AVR32UC3C microcontroller
  3. Blue­tooth and USB interfaces
  4. Approx. 1.5[h] bat­tery time
  5. Size 23.2x31x13.5[mm]

Soft­ware features:

  1. Embed­ded soft­ware writ­ten in C
  2. Gen­eral pro­cess­ing and com­mu­ni­ca­tion framework
  3. Algo­rithm implementations
  4. Repro­gram­ma­ble via USB
  5. Appears as a vir­tual com-port

For a more detailed pre­sen­ta­tion of the imple­men­ta­tion, see the paper Foot-mounted iner­tial nav­i­ga­tion made easy (opens in a new tab). The cur­rent mod­ule is the sec­ond gen­er­a­tion of mod­ules. Descrip­tion of the pre­vi­ous gen­er­a­tion can be found in the paper Foot-mounted INS for Every­body — An Open-Source Embed­ded Imple­men­ta­tion.

We hope that you find the imple­men­ta­tion inter­est­ing and use­ful. If you have any ques­tions, com­ments, sug­ges­tions, or inquiries, please con­tact us at

Best regards
/The Open­Shoe team


* For sys­tem inte­gra­tion, the sta­tis­tics of the posi­tion and head­ing is nec­es­sary. This is achieved by pro­vid­ing dead reck­on­ing updates (dis­place­ment and head­ing changes over indi­vid­ual steps) which can be used to repro­duce the sta­tis­tics. This way, most of the pro­cess­ing can be hid­den from the user while still pro­vid­ing suf­fi­cient infor­ma­tion for fusion with other infor­ma­tion sources.

** Addi­tional hard­ware fea­tures such as a FLASH mem­ory and a pres­sure sen­sor are avail­able. How­ever, no soft­ware sup­port for these com­po­nents is yet available.

Recent posts

Software updates

September 30, 2015, Posted by: John-Olof

Recently there has been a num­ber of soft­ware updates on source forge:

1. The com­mu­ni­ca­tion logic has now been iso­lated from the hard­ware depen­den­cies and the UART (Blue­tooth) and the USB is now han­dled by the same rou­tines. Pre­vi­ously the com­mu­ni­ca­tion logic code was dupli­cated to han­dle the two interfaces.

2. The project files have now been upgraded from Atmel Stu­dio 6.5 to Atmel Stu­dio 7.

3. The Atmel Soft­ware Frame­work (ASF) has been updated from ver­sion 2.7 to ver­sion 3.18. Fur­ther, all ASF/platform depen­den­cies have been removed from the algo­rithms so there is no ASF stuff longer in the algo­rithm project.

Updated low-level communication routines

March 9, 2015, Posted by: John-Olof

Over the last weeks I’ve updated the low-level com­mu­ni­ca­tion rou­tines in the embed­ded code. This should be the end of the clean-up and update of the com­mu­ni­ca­tion inter­faces over the last two month. Now the USB and the Blue­tooth inter­faces should behave iden­ti­cal, apart from the lower band­width of the Blue­tooth inter­face. Fur­ther, both inter­faces are now dou­ble buffered giv­ing a slightly bet­ter per­for­mance. Over­all these changes should not affect high level usage of the mod­ules. What remains to be done is to actu­ally merge the com­mu­ni­ca­tion log­ics of the two dif­fer­ent inter­faces. Now there is a lot of code dupli­ca­tion, not more than before but just much more obvi­ous. How­ever, for now I’m con­tent with the state of the code and I don’t think I will do this in the near future.

Some­what adjusted control-scripts and cal­i­bra­tion scripts:



Espe­cially, in the cal­i­bra­tion script I’ve added a pac­ing beep for plac­ing the cal­i­bra­tion body on the dif­fer­ent sides for roughly the same time.

Edit:  I’ve not updated the com­mu­ni­ca­tion pro­to­col doc­u­men­ta­tion jet. I hope to do that before I for­get about it. How­ever, the changes are very small, essen­tially that the USB inter­face sup­ports loss­less com­mu­ni­ca­tion just like the Blue­tooth interface.

Dual OpenShoe foot-mounted tracking modules — 10x10min walks around our office

March 3, 2015, Posted by: John-Olof

Today I did some ten 10 min­utes walks around our lab (the film runts at x20). Some bet­ter, some worse, noth­ing cen­sored. Two MIMU22BT mod­ules on the top of the forefeet and a Sam­sung Galaxy S3 Android phone were used. Step-wise iner­tial nav­i­ga­tion and wire­less trans­mis­sion of the steps to the phone where the dead reck­on­ing was per­formed. No mag­ne­tome­ters, only accelerom­e­ters and gyros. Fusion of the two dead reck­on­ing sys­tems on the phone.

The shown tra­jec­to­ries are rather benign. Plain walk­ing in a bounded area will cer­tainly not stress the sys­tem but I hope it gives you a feel­ing for the per­for­mance of the mod­ules dur­ing a rea­son­ably real­is­tic sce­nar­iou and not a worst case sce­nar­iou (straight line) which I would typ­i­cally use to assess the performance.

I did 5 walks, charged the mod­ules, and then did 5 more walks. I let the mod­ules warm up for 20 min­utes before the walks. Yes, the mod­ules can give worse per­for­mance dur­ing warm-up.

The map is man­u­ally adjusted to the first lap of the tra­jec­tory. No per­fect fits. Dif­fi­cult with clumsy fin­gers on a small screen. I did not want to adjust it after the first lap since it would be cheat­ing. The bars around the edges of the screen indi­cate 5 meters. The build­ing is roughly 15x50 meters. Con­se­quently each walk is around 700m.

The mod­ules were cal­i­brated a few hours before the walks.

Why 10 min­utes? Well, we have a lim­i­ta­tion in our Android soft­ware which means we can plot at most 10 min­utes of his­tory. Also, over 10 min­utes, the errors are rea­son­ably small such that the results don’t look too messy. Note that the earth rotates some 2.5° over 10 minutes.

What you see is a play­back of what I saw dur­ing the walks. That’s why you see a charg­ing sym­bol every now and then. Simul­ta­ne­ous screen cap­ture would require four arms or reli­able WiFi over the floor. I had neither.

Significant bug fix

February 9, 2015, Posted by: John-Olof

New updates, new bugs.

In test­ing the updated code at the end of last week I expe­ri­enced some strange behav­iour. It turned out to be a sub­tle issue with the manip­u­la­tion of the process sequence. The result was poor ini­tial (first time after power on) per­for­mance for the dead reck­on­ing. In the worst case sce­nario it could give errors in the order of a meter for the first steps. The bug had been around since the revi­sion from 16th of Jan. Now it’s fixed in revi­sion 15f969 and I rec­om­mend to upgrade if you are using the dead reck­on­ing com­mand (0x34).

I’ve also made a few other updates. The only impor­tant one from the user per­spec­tive is that I’ve moved the func­tions which read data from the IMUs to the process sequence. This is to get more flex­i­bil­ity, and really there is noth­ing spe­cial about this func­tion so it fits bet­ter in the process sequence than beside it. The imu_read() func­tion is in the process sequence by default and it has been added to all com­bined com­mands. Con­se­quently, from the user inter­face per­spec­tive, the dif­fer­ences are small. How­ever, if you are man­u­ally manip­u­lat­ing the process sequence, you will have to take into account that the imu_read() func­tion should prob­a­bly reside in the first slot in the sequence.

The plan is to spend part of this week on test­ing, revis­ing and refac­tor­ing the code so more updates may come. How­ever, the revi­sion of the com­mu­ni­ca­tion pro­to­col was a one-time thing and I do not plan on mak­ing any sig­nif­i­cant changes there.

New and improved calibration script

February 6, 2015, Posted by: John-Olof

A new and improved cal­i­bra­tion script is avail­able below. First of all, you do not longer have to man­u­ally ver­ify data from each side of the cal­i­bra­tion body. Con­se­quently, the pro­ce­dure is much faster. Sec­ondly, the script is adapted to the recent updates to the embed­ded code. If you change the com­mands and the pars­ing mex-file to those of the old script pack­age, you could use it with an old mod­ule with­out repro­gram­ming it, but then it’s prob­a­bly bet­ter to sim­ply repro­gram your mod­ule. Thirdly, it comes with a brief instruc­tion video:



Zip-file with cal­i­bra­tion script pack­age. Down­load and run main.m.


(Note: if you do not use 64-bit win­dows you will have to com­pile the .cpp file with mex com­man in Matlab)

(Note: Your mod­ule will work with­out any cal­i­bra­tion. How­ever, it will pos­si­bly work bet­ter with it.)