Open source embedded foot-mounted INS

 

 

 

DURING THE YEAR, WE HAVE MADE SIGNIFICANT UPGRADES TO THE TRACKING MODULES. UNFORTUNATELY, WE HAVE NOT YET UPDATED THE INFORMATION ABOUT THE MODULES UNDER THE LINKS TO THE RIGHT. CONSEQUENTLY, MOST OF THE INFORMATION THERE REFERS TO THE OLD GENERATION OF TRACKING MODULES. THE INFORMATION SHOULD BE UPDATED DURING THE FALL. FOR MORE INFORMATION, SEE RECENT POSTS.

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. (The man­u­script is still under review. If you would like to take part of it now, please con­tact us.) 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 here: 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

 

* 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:

Presentation_IPIN14

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