Archive for March, 2014

Computational cost of inertial frontend

Saturday, March 15th, 2014

I just clocked the iner­tial fron­tend and it came in on around 1200 clock cycles for the sta­tis­tics cal­cu­la­tion, 200 clock cycles per IMU for the cal­i­bra­tion com­pen­sa­tion (sta­tic bias, mis­align­ment, scale error com­pen­sa­tion), and around 400 clock cycles for the (float­ing point) on-line bias esti­ma­tion. The bias esti­ma­tion is prob­a­bly dom­i­nated by the divi­sion oper­a­tion in the gain cal­cu­la­tion. Unfor­tu­nately, the micro­con­troller has no hard­ware float­ing point divi­sion operation.

The 1200 clock cycles for the sta­tis­tics cal­cu­la­tion can be com­pared with around 5500 float­ing point arith­metic oper­a­tion which would be required to cal­cu­late just the longer 256 sam­ple test sta­tis­tics in the naive way. And this com­pu­ta­tional cost would scale with the num­ber of sam­ples. I have not clocked the old func­tions but together with mem­ory accesses and other aux­il­iary oper­a­tions, I guess the old (naive) imple­men­ta­tion would take at least about 10 times the num­ber of clock cycles. I had pre­vi­ously done some back-of-an-envelope cal­cu­la­tions of the com­pu­ta­tional cost reduc­tion of the recur­sive inte­ger sta­tis­tics cal­cu­la­tions but this was the first time I have seen it for real.

Software updates

Saturday, March 15th, 2014

A new ver­sion of the boards is under pro­duc­tion. While wait­ing for it I have pri­mar­ily been work­ing with the embed­ded soft­ware. The fol­low­ing are the important/larger changes which have been pushed to sourceforge:

  • Sup­port for com­pil­ing the code for the dif­fer­ent hard­ware plat­forms (ver­sions) has been added. The plat­form is con­trolled by in-line macro def­i­n­i­tions (-D) which together with #if … #endif state­ments include appro­pri­ate code sec­tions. Most of the set­ting for the dif­fer­ent ver­sions have been col­lected in plat­form spe­cific con­fig files.
  • The inte­ger iner­tial fron­tend is now almost com­pletely inte­grated and can now be used with the old units. The cor­re­spond­ing float­ing point func­tions in nav_eq.c are still there but will prob­a­bly be cleaned out some­time later.
  • The com­mands have been cleaned up and sev­eral com­mands which have been essen­tially unused have been removed.

140316: The float­ing point zupt-functions and states have now been cleaned out from nav_eq.c and the run­time framework.