Significant bug fix

New updates, new bugs.

In test­ing the updated code at the end of last week I expe­ri­enced some strange behav­iour. It turned out to be a sub­tle issue with the manip­u­la­tion of the process sequence. The result was poor ini­tial (first time after power on) per­for­mance for the dead reck­on­ing. In the worst case sce­nario it could give errors in the order of a meter for the first steps. The bug had been around since the revi­sion from 16th of Jan. Now it’s fixed in revi­sion 15f969 and I rec­om­mend to upgrade if you are using the dead reck­on­ing com­mand (0x34).

I’ve also made a few other updates. The only impor­tant one from the user per­spec­tive is that I’ve moved the func­tions which read data from the IMUs to the process sequence. This is to get more flex­i­bil­ity, and really there is noth­ing spe­cial about this func­tion so it fits bet­ter in the process sequence than beside it. The imu_read() func­tion is in the process sequence by default and it has been added to all com­bined com­mands. Con­se­quently, from the user inter­face per­spec­tive, the dif­fer­ences are small. How­ever, if you are man­u­ally manip­u­lat­ing the process sequence, you will have to take into account that the imu_read() func­tion should prob­a­bly reside in the first slot in the sequence.

The plan is to spend part of this week on test­ing, revis­ing and refac­tor­ing the code so more updates may come. How­ever, the revi­sion of the com­mu­ni­ca­tion pro­to­col was a one-time thing and I do not plan on mak­ing any sig­nif­i­cant changes there.

This entry was posted on Monday, February 9th, 2015 at 11:48 pm and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed.
Responses are currently closed, but you can trackback from your own site.