I (John-Olof) is currently attending the IPIN conference in Busan, South Korea. The presentation of today is available at:
Tomorrow I will also give a demo at the conference. See you there!
I (John-Olof) is currently attending the IPIN conference in Busan, South Korea. The presentation of today is available at:
Tomorrow I will also give a demo at the conference. See you there!
Just a small clarification concerning the calibration body. Both the MIMU22BT modules and the MIMU4444 boards (as well as the old MIMU3333 boards) fit in the body. (The do slide in further compared to the photos.) The wireless link of the MIMU22BT modules is really nice when you do the calibration. Just be sure to pair with the right module. Once I spent tenth of minutes trying to figure out why my calibration script had stopped working until I realized that the measurements did not come from the module in the body.
Our recent modules contain multiple single-chip inertial measurement units. To get the best performance out of them, they should be calibrated. However, the “IMU array” setup means standard calibration procedures will not work. We have therefore developed array calibration methods for the modules. These have lately been published in the letter below. Matlab code for performing the calibration and and STL-file and corresponding SCAD-code are also provided.
In short, the modules are inserted in the calibration body seen above, static measurements are take from all sides, the calibration parameters are estimated in a blind system identification fashion, and code is generated which should then be loaded onto the respective module.
John-Olof Nilsson, Isaac Skog, and Peter Händel, Aligning the Forces—Eliminating the Misalignments in IMU Arrays, Instrumentation and Measurement, IEEE Transactions on , vol.PP, no.99, pp.1,1
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).
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.