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

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.)

More resources

January 30, 2015, Posted by: John-Olof

GT-Silicon (who are build­ing and sell­ing com­plete Open­Shoe mod­ules) have a lot of resources related to the mod­ules on their home­page. You can find them at:

OpenShoe communication protocol revision and documentation

January 30, 2015, Posted by: John-Olof

Not many updates here lately, but a larger num­ber of updates in the repos­i­tory. Dur­ing the last month, I have revised, com­ple­mented, and cleaned up pri­mar­ily the com­mu­ni­ca­tion pro­to­col. I’ve even writ­ten some doc­u­men­ta­tion! The bad news is that the com­mu­ni­ca­tion pro­to­col has changed slightly but keep­ing the messy order of com­mand IDs seemed even worth. The com­mu­ni­ca­tion logic is the same but some com­mand head­ers have changed. Any­how, this should not be too big of a prob­lem since now you can find all com­mands described in the fol­low­ing document:


Just to sum up, the sig­nif­i­cant changes are:

  1. There are now a two byte pack­age num­ber in the pack­ages com­ing over the USB inter­face, just like it has always been for the Blue­tooth inter­face. The long term inten­tion is to con­nect the inter­faces much tighter. Now they only sig­nif­i­cant dif­fer­ence is the lack of a “loss­less” mode for the USB interface.
  2. A num­ber of com­mands have new headers.
  3. A num­ber of new com­mands have been added to make the pro­to­col more complete.
  4. Sup­port for the old­est gen­er­a­tion of Open­Shoe mod­ules (those based on the AD16367 IMU) have been removed.

To make get­ting started with the mod­ules eas­ier I have also com­piled a num­ber of Mat­lab scripts which I use. These scripts demon­strates the basic usage of the mod­ules. You find the scripts below:


Some of the scripts rely on mex-files. The C++-code is included but it has only been com­piled for 64-bit Win­dows. If you are run­ning some other OS, you need to com­pile those functions.

IPIN 2014

October 28, 2014, Posted by: John-Olof

I (John-Olof) is cur­rently attend­ing the IPIN con­fer­ence in Busan, South Korea. The pre­sen­ta­tion of today is avail­able at:


Tomor­row I will also give a demo at the con­fer­ence. See you there!