Open source embedded foot-mounted INS


Open­Shoe is an open source embed­ded foot-mounted INS imple­men­ta­tion includ­ing both hard­ware and soft­ware design. A cross sec­tion of a shoe with a unit of the imple­men­ta­tion inte­grated into the sole can be seen above. To our knowl­edge, this is the only imple­men­ta­tion of its kind.

The imple­men­ta­tion has been done with the hope that it will save time, sweat, and tears for nav­i­ga­tion researchers as well as facil­i­tate the use of the tech­nol­ogy by researchers not spe­cial­ized in aided INS, e.g. in fields such as bio­med­ical engi­neer­ing, behav­ioral sci­ence, and ubiq­ui­tous com­put­ing. The value of the embed­ded imple­men­ta­tion also lies in its mod­u­lar­ity and in its small weight, bulk, and price in com­par­i­son with the typ­i­cal sensor-plus-laptop research sys­tems. These prop­er­ties alle­vi­ate the work of inte­grat­ing the foot-mounted INS in larger real­time pedes­trian nav­i­ga­tion sys­tems, and make it fea­si­ble to equip a larger num­ber of users with foot­mounted INS units for field per­for­mance tests and coop­er­a­tive nav­i­ga­tion studies.


Gen­eral fea­tures of the implementation:

  1. Embed­ded ZUPT aided INS
  2. Open source and fully documented
  3. Repro­duc­tion cost below $800

Hard­ware features:

  1. Designed for an Ana­log Devices ADIS16367 IMU but with inter­face com­pitabil­ity with all IMUs in the iSen­sor serie
  2. 820[Hz] sam­pling rate, 18[g] and 1200°/s dynamic range, 330[Hz] sen­sor band­width using the ADIS16367 IMU
  3. Atmel AVR32UC3C micro­con­troller with hard­ware float­ing point
  4. Foot­print 28.5x32x40.5[mm]
  5. USB inter­face

Soft­ware features:

  1. Source code writ­ten in C
  2. Eas­ily con­fig­ured to run any user imple­mented algorithms
  3. Mat­lab code avail­able for communication
  4. Repro­gram­ma­ble through the USB interface.
  5. Appear as a vir­tual com-port
  6. Con­fig­urable to work as an IMU, as a stand-alone ZUPT-aided INS, and as a dis­place­ment and head­ing change sensor.

The sys­tem is eas­ily repro­ducible. On this site you can find:

  1. Pre­com­piled code
  2. Fully doc­u­mented C source code
  3. Pro­duc­tion files for PCB/PCA and casing

For a more detailed pre­sen­ta­tion of the imple­men­ta­tion, see the arti­cle Foot-mounted INS for Every­body — An Open-Source Embed­ded Imple­men­ta­tion (opens in a new tab).

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

Best regards
/The Open­Shoe team

Recent posts

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.

Increased sampling frequency

May 20, 2014, Posted by: John-Olof

Due to some legacy code from the first MIMU3333 test boards, the inter­nal sam­pling fre­quency of the board was pre­vi­ously set to around 400Hz while the inter­nal sam­pling fre­quency of the IMUs was a 1000Hz. The main rea­sons for the low sam­pling fre­quency was that the IMUs (of the MIMU333 test board) were orig­i­nally con­nected to two dif­fer­ent ports on the uC and that the uC was run­ning on a sin­gle inter­nal PLL, which lim­ited the inter­nal clock fre­quency since the USB needed 48MHz. These hur­dles have now been cleared and the sam­pling fre­quency of the board is now set to 1000Hz, just like the inter­nal IMU sam­pling frequency.

Unfor­tu­nately, the 1000Hz sam­pling fre­quency is not with­out prob­lems. For the MIMU22BT boards every­thing works fine. How­ever, for the MIMU4444 array boards, the sam­pling fre­quency works fine inter­nally but the USB can­not keep up in case you want all raw data from all 32 IMUs. If you try to out­put all raw data from all IMUs at every sam­pling instant, the sam­pling fre­quency will drop to around 500Hz since the uC will be wait­ing for the data to be sent. I’m not sure whether this is a lim­i­ta­tion of the USB pro­file, the USB stack, or our code.

The mech­a­niza­tion and the fil­ter­ing of the aided iner­tial nav­i­ga­tion can be run at 1000Hz. This means that the clock fre­quency, i.e. power con­sump­tion, can be traded for sam­pling fre­quency. Cur­rently, the uC makes up around 2/3 of the power (cur­rent) con­sump­tion of around 100mA. Its power con­sump­tion will scale rather lin­early with the clock fre­quency. Con­se­quently, the power con­sump­tion could, in prin­ci­ple, for exam­ple, be reduced by 1/3 by halv­ing the clock fre­quency at the cost of halv­ing the sam­pling frequency.


April 1, 2014, Posted by: John-Olof

Finally, the new gen­er­a­tion of the IMU array boards, the MIMU4444v1, arrived yes­ter­day. These boards mea­sure 49.3x26.6[mm] and con­tain 32 MPU9150 IMUs each, which are all sam­pled in par­al­lel. The embed­ded soft­ware for the boards is achieved by com­pil­ing the code on source­forge with the argu­ment –DMIMU4444. The design-files for the boards are avail­able under Massive-MIMU. This is not an April fool mockup! The multi-IMU boards are rather a major side project to the main foot-mounted INS devel­op­ment. The same prin­ci­ples are used in the MIMU22BT boards but with 4 IMUs.

Casing STL files

March 30, 2014, Posted by: John-Olof

The cas­ing STL files can now be found under:
Sys­tem repro­duc­tion
The cas­ing is 1.5[mm] thick all around.
The outer dimen­sions of the cas­ing are 23.2x31x13.5[mm].
The cas­ing has a snap fit solu­tion and does not require any screws or sim­i­lar. This far, we have had the cas­ings printed on a Maker­Bot 2 by