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

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!

Clarification — calibration body

October 2, 2014, Posted by: John-Olof

Just a small clar­i­fi­ca­tion con­cern­ing the cal­i­bra­tion body. Both the MIMU22BT mod­ules and the MIMU4444 boards (as well as the old MIMU3333 boards) fit in the body. (The do slide in fur­ther com­pared to the pho­tos.) The wire­less link of the MIMU22BT mod­ules is really nice when you do the cal­i­bra­tion. Just be sure to pair with the right mod­ule. Once I spent tenth of min­utes try­ing to fig­ure out why my cal­i­bra­tion script had stopped work­ing until I real­ized that the mea­sure­ments did not come from the mod­ule in the body.

Calibration procedure

August 22, 2014, Posted by: John-Olof

Our recent mod­ules con­tain mul­ti­ple single-chip iner­tial mea­sure­ment units. To get the best per­for­mance out of them, they should be cal­i­brated. How­ever, the “IMU array” setup means stan­dard cal­i­bra­tion pro­ce­dures will not work. We have there­fore devel­oped array cal­i­bra­tion meth­ods for the mod­ules. These have lately been pub­lished in the let­ter below. Mat­lab code for per­form­ing the cal­i­bra­tion and and STL-file and cor­re­spond­ing SCAD-code are also provided.

In short, the mod­ules are inserted in the cal­i­bra­tion body seen above, sta­tic mea­sure­ments are take from all sides, the cal­i­bra­tion para­me­ters are esti­mated in a blind sys­tem iden­ti­fi­ca­tion fash­ion, and code is gen­er­ated which should then be loaded onto the respec­tive module.


John-Olof Nils­son, Isaac Skog, and Peter Hän­del, Align­ing the Forces—Eliminating the Mis­align­ments in IMU ArraysInstru­men­ta­tion and Mea­sure­ment, IEEE Trans­ac­tions on , vol.PP, no.99, pp.1,1

Repro­ducible research: code, STL/SCAD

Hardware in the loop algorithm testing

May 29, 2014, Posted by: John-Olof

Algo­rithm imple­men­ta­tions live their grown-up life in C, but fre­quently they are devel­oped with tools like Mat­lab. Also, exper­i­men­ta­tion, tun­ing and char­ac­ter­i­za­tion are con­ve­niently done in Mat­lab. Con­se­quently, I con­stantly find myself hav­ing to port code from Mat­lab to C and hav­ing to check the con­sis­tency between Mat­lab and C imple­men­ta­tions. In the case of the Open­Shoe mod­ules, the embed­ded plat­form makes this work worse than usual. Orig­i­nally (back in 2011) we had some frame­work (found on source­forge) for test­ing the C imple­men­ta­tions of the algo­rithms but it was not main­tained and it is now hope­lessly out of sync with the cur­rent run­time frame­work. With the new mod­ules we have renewed exper­i­men­ta­tion, tun­ing, and char­ac­ter­i­za­tion needs. There­fore, I have now added built-in sup­port (to ensure it’s main­tained), in the run­time frame­work, for push­ing iner­tial data over the USB, run­ning some pre­con­fig­ured pro­cess­ing func­tions (con­fig­ured by com­mands), and get­ting some requested states back. This I use to check the con­sis­tency between Mat­lab and C imple­men­ta­tions of the pro­cess­ing func­tions and related logics.

A side note is that it’s a pain check­ing the con­sis­tency between C code and Mat­lab code when using float­ing point vari­ables, espe­cially with sin­gle pre­ci­sion. C and Mat­lab sim­ply don’t give iden­ti­cal results and then it’s hard to know whether this is due to some small actual error or if it’s just numer­i­cal lim­i­ta­tions. The insta­bil­ity of the iner­tial nav­i­ga­tion makes it even worse. There­fore, the code has been para­me­ter­ized such that it can be com­piled with dou­ble pre­ci­sion for off-line test­ing (the 32-bit uC means that using dou­ble pre­ci­sion is too slow for real­time processing).

Status report: testing and integration

May 20, 2014, Posted by: John-Olof

The test­ing and inte­gra­tion of the new MIMU22BT mod­ules are slowly pro­gress­ing. So far so good! Above you see one of the mod­ules with a cas­ing printed in white by My feel­ing is that the new mod­ules give sig­nif­i­cantly improved per­for­mance but this far I have not made any rig­or­ous per­for­mance tests. Before I did this I wanted to increase the inter­nal sam­pling fre­quency (see pre­vi­ous post) and write soft­ware such that I could log all the raw data to an Android phone rather than a lap­top. Car­ry­ing around a phone instead of a lap­top is way more con­ve­nient when col­lect­ing a lot of data. The for­mer is done while the lat­ter remains.

We have now essen­tially replaced the old ADIS16367-based mod­ules in the TOR sys­tem with the new mod­ules. The wire­less con­nec­tions are a great improve­ment com­pared to the old cabled con­nec­tions. I don’t miss bro­ken cables, unplugged con­nec­tors, USB hubs, and the trip­wires the made up at all. (The wire­less con­nec­tion to the Android phones is up and run­ning but to log all raw data in order to carry out a per­for­mance eval­u­a­tion the wired con­nec­tion need to be set up as well.)

In the test­ing and inte­gra­tion we have not encoun­tered any major hard­ware issues this far. There are a bunch of small things I would like to change such as place­ment of LEDs, exchange the power switch with a push but­ton with a latch cir­cuit, and so on. How­ever, over­all the mod­ules seems to work reli­ably, for our purposes.