Open source embedded foot-mounted INS
OpenShoe is an open source embedded foot-mounted INS implementation including both hardware and software design. A cross section of a shoe with a unit of the implementation integrated into the sole can be seen above. To our knowledge, this is the only implementation of its kind.
The implementation has been done with the hope that it will save time, sweat, and tears for navigation researchers as well as facilitate the use of the technology by researchers not specialized in aided INS, e.g. in fields such as biomedical engineering, behavioral science, and ubiquitous computing. The value of the embedded implementation also lies in its modularity and in its small weight, bulk, and price in comparison with the typical sensor-plus-laptop research systems. These properties alleviate the work of integrating the foot-mounted INS in larger realtime pedestrian navigation systems, and make it feasible to equip a larger number of users with footmounted INS units for field performance tests and cooperative navigation studies.
THE MODULES ARE CURRENTLY (SPRING OF 2014) UNDERGOING SIGNIFICANT UPDATES AND THE INFORMATION BELOW IS NO LONGER UP-TO-DATE. SEE RECENT POSTS BELOW FOR FURTHER INFORMATION.
General features of the implementation:
- Embedded ZUPT aided INS
- Open source and fully documented
- Reproduction cost below $800
- Designed for an Analog Devices ADIS16367 IMU but with interface compitability with all IMUs in the iSensor serie
- 820[Hz] sampling rate, 18[g] and 1200°/s dynamic range, 330[Hz] sensor bandwidth using the ADIS16367 IMU
- Atmel AVR32UC3C microcontroller with hardware floating point
- Footprint 28.5x32x40.5[mm]
- USB interface
- Source code written in C
- Easily configured to run any user implemented algorithms
- Matlab code available for communication
- Reprogrammable through the USB interface.
- Appear as a virtual com-port
- Configurable to work as an IMU, as a stand-alone ZUPT-aided INS, and as a displacement and heading change sensor.
The system is easily reproducible. On this site you can find:
- Precompiled code
- Fully documented C source code
- Production files for PCB/PCA and casing
For a more detailed presentation of the implementation, see the article Foot-mounted INS for Everybody — An Open-Source Embedded Implementation (opens in a new tab).
We hope that you find the implementation interesting and usefull. If you have any questions, comments, suggestions, or enquiries, please contact us at firstname.lastname@example.org.
/The OpenShoe team
Hardware in the loop algorithm testing
May 29, 2014, Posted by: John-Olof
Algorithm implementations live their grown-up life in C, but frequently they are developed with tools like Matlab. Also, experimentation, tuning and characterization are conveniently done in Matlab. Consequently, I constantly find myself having to port code from Matlab to C and having to check the consistency between Matlab and C implementations. In the case of the OpenShoe modules, the embedded platform makes this work worse than usual. Originally (back in 2011) we had some framework (found on sourceforge) for testing the C implementations of the algorithms but it was not maintained and it is now hopelessly out of sync with the current runtime framework. With the new modules we have renewed experimentation, tuning, and characterization needs. Therefore, I have now added built-in support (to ensure it’s maintained), in the runtime framework, for pushing inertial data over the USB, running some preconfigured processing functions (configured by commands), and getting some requested states back. This I use to check the consistency between Matlab and C implementations of the processing functions and related logics.
A side note is that it’s a pain checking the consistency between C code and Matlab code when using floating point variables, especially with single precision. C and Matlab simply don’t give identical results and then it’s hard to know whether this is due to some small actual error or if it’s just numerical limitations. The instability of the inertial navigation makes it even worse. Therefore, the code has been parameterized such that it can be compiled with double precision for off-line testing (the 32-bit uC means that using double precision is too slow for realtime processing).
Status report: testing and integration
May 20, 2014, Posted by: John-Olof
The testing and integration of the new MIMU22BT modules are slowly progressing. So far so good! Above you see one of the modules with a casing printed in white by www.beta-prototypes.com. My feeling is that the new modules give significantly improved performance but this far I have not made any rigorous performance tests. Before I did this I wanted to increase the internal sampling frequency (see previous post) and write software such that I could log all the raw data to an Android phone rather than a laptop. Carrying around a phone instead of a laptop is way more convenient when collecting a lot of data. The former is done while the latter remains.
We have now essentially replaced the old ADIS16367-based modules in the TOR system with the new modules. The wireless connections are a great improvement compared to the old cabled connections. I don’t miss broken cables, unplugged connectors, USB hubs, and the tripwires the made up at all. (The wireless connection to the Android phones is up and running but to log all raw data in order to carry out a performance evaluation the wired connection need to be set up as well.)
In the testing and integration we have not encountered any major hardware issues this far. There are a bunch of small things I would like to change such as placement of LEDs, exchange the power switch with a push button with a latch circuit, and so on. However, overall the modules seems to work reliably, 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 internal sampling frequency of the board was previously set to around 400Hz while the internal sampling frequency of the IMUs was a 1000Hz. The main reasons for the low sampling frequency was that the IMUs (of the MIMU333 test board) were originally connected to two different ports on the uC and that the uC was running on a single internal PLL, which limited the internal clock frequency since the USB needed 48MHz. These hurdles have now been cleared and the sampling frequency of the board is now set to 1000Hz, just like the internal IMU sampling frequency.
Unfortunately, the 1000Hz sampling frequency is not without problems. For the MIMU22BT boards everything works fine. However, for the MIMU4444 array boards, the sampling frequency works fine internally but the USB cannot keep up in case you want all raw data from all 32 IMUs. If you try to output all raw data from all IMUs at every sampling instant, the sampling frequency will drop to around 500Hz since the uC will be waiting for the data to be sent. I’m not sure whether this is a limitation of the USB profile, the USB stack, or our code.
The mechanization and the filtering of the aided inertial navigation can be run at 1000Hz. This means that the clock frequency, i.e. power consumption, can be traded for sampling frequency. Currently, the uC makes up around 2/3 of the power (current) consumption of around 100mA. Its power consumption will scale rather linearly with the clock frequency. Consequently, the power consumption could, in principle, for example, be reduced by 1/3 by halving the clock frequency at the cost of halving the sampling frequency.
April 1, 2014, Posted by: John-Olof
Finally, the new generation of the IMU array boards, the MIMU4444v1, arrived yesterday. These boards measure 49.3x26.6[mm] and contain 32 MPU9150 IMUs each, which are all sampled in parallel. The embedded software for the boards is achieved by compiling the code on sourceforge with the argument –DMIMU4444. The design-files for the boards are available 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 development. The same principles are used in the MIMU22BT boards but with 4 IMUs.
Casing STL files
March 30, 2014, Posted by: John-Olof
The casing STL files can now be found under:
The casing is 1.5[mm] thick all around.
The outer dimensions of the casing are 23.2x31x13.5[mm].
The casing has a snap fit solution and does not require any screws or similar. This far, we have had the casings printed on a MakerBot 2 by myobjectify.com.