Hardware in the loop algorithm testing

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

Comments are closed.