OpenShoe is an open source embedded foot-mounted inertial navigation system (INS) implementation, including both hardware and software designs. The module tracks the motion of the foot over the step by means of inertial navigation. The steps can then be summed up to get a relative position of a pedestrian, as illustrated above.
The embedded implementation and the step-wise inertial navigation modularizes the foot-mounted INS technology which facilitates the integration in realtime pedestrian positioning systems, and make it feasible to equip a larger number of users with foot-mounted INS modules for field performance tests and cooperative localization studies. The modules are wireless and can provide the tracking information to, for example, a smart-phone. Modules can be used on both feet for improved performance.
General features of the implementation:
Embedded ZUPT-aided INS
Dead reckoning updates*
Four Invensense MPU9150 IMUs
Atmel AVR32UC3C microcontroller
Bluetooth and USB interfaces
Approx. 1.5[h] battery time
Embedded software written in C
General processing and communication framework
We hope that you find the implementation interesting and useful. If you have any questions, comments, suggestions, or inquiries, please contact us at email@example.com.
/The OpenShoe team
* For system integration, the statistics of the position and heading is necessary. This is achieved by providing dead reckoning updates (displacement and heading changes over individual steps) which can be used to reproduce the statistics. This way, most of the processing can be hidden from the user while still providing sufficient information for fusion with other information sources.
** Additional hardware features such as a FLASH memory and a pressure sensor are available. However, no software support for these components is yet available.
September 30, 2015, Posted by: John-Olof
Recently there has been a number of software updates on source forge:
1. The communication logic has now been isolated from the hardware dependencies and the UART (Bluetooth) and the USB is now handled by the same routines. Previously the communication logic code was duplicated to handle the two interfaces.
2. The project files have now been upgraded from Atmel Studio 6.5 to Atmel Studio 7.
3. The Atmel Software Framework (ASF) has been updated from version 2.7 to version 3.18. Further, all ASF/platform dependencies have been removed from the algorithms so there is no ASF stuff longer in the algorithm project.
Updated low-level communication routines
March 9, 2015, Posted by: John-Olof
Over the last weeks I’ve updated the low-level communication routines in the embedded code. This should be the end of the clean-up and update of the communication interfaces over the last two month. Now the USB and the Bluetooth interfaces should behave identical, apart from the lower bandwidth of the Bluetooth interface. Further, both interfaces are now double buffered giving a slightly better performance. Overall these changes should not affect high level usage of the modules. What remains to be done is to actually merge the communication logics of the two different interfaces. Now there is a lot of code duplication, not more than before but just much more obvious. However, for now I’m content with the state of the code and I don’t think I will do this in the near future.
Somewhat adjusted control-scripts and calibration scripts:
Especially, in the calibration script I’ve added a pacing beep for placing the calibration body on the different sides for roughly the same time.
Edit: I’ve not updated the communication protocol documentation jet. I hope to do that before I forget about it. However, the changes are very small, essentially that the USB interface supports lossless communication just like the Bluetooth interface.
Today I did some ten 10 minutes walks around our lab (the film runts at x20). Some better, some worse, nothing censored. Two MIMU22BT modules on the top of the forefeet and a Samsung Galaxy S3 Android phone were used. Step-wise inertial navigation and wireless transmission of the steps to the phone where the dead reckoning was performed. No magnetometers, only accelerometers and gyros. Fusion of the two dead reckoning systems on the phone.
The shown trajectories are rather benign. Plain walking in a bounded area will certainly not stress the system but I hope it gives you a feeling for the performance of the modules during a reasonably realistic scenariou and not a worst case scenariou (straight line) which I would typically use to assess the performance.
I did 5 walks, charged the modules, and then did 5 more walks. I let the modules warm up for 20 minutes before the walks. Yes, the modules can give worse performance during warm-up.
The map is manually adjusted to the first lap of the trajectory. No perfect fits. Difficult with clumsy fingers on a small screen. I did not want to adjust it after the first lap since it would be cheating. The bars around the edges of the screen indicate 5 meters. The building is roughly 15x50 meters. Consequently each walk is around 700m.
The modules were calibrated a few hours before the walks.
Why 10 minutes? Well, we have a limitation in our Android software which means we can plot at most 10 minutes of history. Also, over 10 minutes, the errors are reasonably small such that the results don’t look too messy. Note that the earth rotates some 2.5° over 10 minutes.
What you see is a playback of what I saw during the walks. That’s why you see a charging symbol every now and then. Simultaneous screen capture would require four arms or reliable WiFi over the floor. I had neither.
Significant bug fix
February 9, 2015, Posted by: John-Olof
New updates, new bugs.
In testing the updated code at the end of last week I experienced some strange behaviour. It turned out to be a subtle issue with the manipulation of the process sequence. The result was poor initial (first time after power on) performance for the dead reckoning. In the worst case scenario it could give errors in the order of a meter for the first steps. The bug had been around since the revision from 16th of Jan. Now it’s fixed in revision 15f969 and I recommend to upgrade if you are using the dead reckoning command (0x34).
I’ve also made a few other updates. The only important one from the user perspective is that I’ve moved the functions which read data from the IMUs to the process sequence. This is to get more flexibility, and really there is nothing special about this function so it fits better in the process sequence than beside it. The imu_read() function is in the process sequence by default and it has been added to all combined commands. Consequently, from the user interface perspective, the differences are small. However, if you are manually manipulating the process sequence, you will have to take into account that the imu_read() function should probably reside in the first slot in the sequence.
The plan is to spend part of this week on testing, revising and refactoring the code so more updates may come. However, the revision of the communication protocol was a one-time thing and I do not plan on making any significant changes there.
New and improved calibration script
February 6, 2015, Posted by: John-Olof
A new and improved calibration script is available below. First of all, you do not longer have to manually verify data from each side of the calibration body. Consequently, the procedure is much faster. Secondly, the script is adapted to the recent updates to the embedded code. If you change the commands and the parsing mex-file to those of the old script package, you could use it with an old module without reprogramming it, but then it’s probably better to simply reprogram your module. Thirdly, it comes with a brief instruction video:
Zip-file with calibration script package. Download and run main.m.