Open source embedded foot-mounted INS

 

THE TRACKING MODULES HAVE RECENTLY UNDERGONE SIGNIFICANT UPDATES (NEW IMUS, WIRELESS INTERFACE, ETC). THE MODULE DESIGN AND THE UPDATED SOFTWARE ARE ALREADY RELEASED BUT THE INFORMATION BELOW AND SOME OTHER DOCUMENTATION ON THIS SITE HAVE NOT BEEN UPDATED. SEE RECENT POST FOR FURTHER INFORMATION ABOUT THE NEW MODULES.

A PAPER DESCRIBING THE NEW MIMU22BT PLATFORM IS CURRENTLY UNDER REVIEW. IF YOU WOULD LIKE TO  TAKE PART OF THE PAPER, PLEASE CONTACT US AT openshoe@ee.kth.se.

 

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 openshoe@ee.kth.se.

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 www.beta-prototypes.com. 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.

Massive-MIMU

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 myobjectify.com.