I have spent the last week trying to figure out why the BSX Lite library (Cortex M0+ version from the BMF055 evaluation board shark demo) would give bad orientation data on my custom BMX055 board whenever I fed the gyro data into the library.
In order to save everyone else having this problem some time, here is what I found: In bmf055.h, the gyro is initialized as
/* BMG settings for running BSXLite: Range = 500dps, BW = 64Hz*/ bmg160_set_range_reg(0x02); bmg160_set_bw(0x06);
This is wrong! Apparently that version of BSX lite requires 250dps, so all raw values are too low by a factor of 2. If I change this to
/* BMG settings for running BSXLite: Range = 250dps, BW = 64Hz*/ bmg160_set_range_reg(0x03); // fixed range bmg160_set_bw(0x06);
it works. Another alternative if one wants to keep the larger gyro range is to manually scale the raw values instead:
/* Read and process gyro data */ bmg160_get_data_XYZ(&bmf055_gyr_data); /* Convert the timer tick to micro seconds */ timestamp_dataxyz.gyro.time_stamp = local_timestamp * 1000; timestamp_dataxyz.gyro.data.x = bmf055_gyr_data.datax*2; // scale everything timestamp_dataxyz.gyro.data.y = bmf055_gyr_data.datay*2; timestamp_dataxyz.gyro.data.z = bmf055_gyr_data.dataz*2;
With these modifications is works very well. I'm a bit lost though why they are required. I find it hard to believe that such a bug has made it into the evaluation board, as it pretty much breaks the sensor fusion. So it might be something else, but I have not idea what could cause an incorrect reduction by a factor of 2.
Thanks, you suggestion is very much to the point. I can see that the quality of the output largely depends on the frame rate. If it is just a few percent off 100fps, it starts to drift a lot. I'm assuming this is due to the double integration of the acceleration data?
I also had delay in the I2C routines as I found that commands were ignored if sent too fast. The result was that reading the accelerometer data took 1-2 ms. As I was using the same timestamp for accelerometer and gyro, that probably caused some inaccuracy as well.
Finally I'm currently taking the timestamp from the 32.768kHz RTC; as the MCU must sleep between cylcles, which probably also causes some inaccuracies. I will see if I can get a more accurate counter.