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