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.
... View more
Hello, 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_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 */
/* 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.
... View more