There is a long documented bug on all version of the Raspberry Pi (including the new v3 apparently) whereby the I2C bus doesn't work to spec. For those that don't know, the I2C bus supports the notion of "clock stretching" which allows either the master of slave device to slow down communications if one end cannot keep up. Most I2C devices don't use this because they can keep up just fine, but the BNO055 device does use clock stretching, and the Raspberry Pi doesn't deal with this well.

The upshot of this in my ROV is that sometimes I get bad data from the IMU. This bad data appears to manifest itself in two ways: 1 - I just get back 0's; and 2 - the last bit of a 16-bit read is set to 1 when it should be 0. Unfortunately, for whatever reason, immediately re-reading the data doesn't usually result in a good data; which makes me think the BNO055 is busy internal and can't talk properly right now ... but who really knows.

In an ideal world I'd come up with a solution to make the I2C bus work correctly on the Raspberry Pi, but until that happens I need to deal with this error infested data. My first plan had been to simply discard these bad readings. Fortunately they're easy to spot because a reading of all 0's for pitch, heading and roll is very unlikely to occur, and the high-bit being set will put the radian value larger than 2*pi. Unfortunately these errors occur often enough that I end up with large gaps in the data stream, which won't make balancing the ROV easy.

At least when working in radians, the device only needs to return 14-bits worth of signed data for roll, pitch and heading. After some experimenting it appears that the Raspberry Pi can at least get this much data before any errors occur. If I just use these 14-bits, the data stream is almost perfect (the random sets of 0's still occur, but are infrequent enough to be ignored).

Still, I'd rather have the Raspberry Pi run the I2C protocol correctly. Fingers crossed they fix this one day; but I'm not hopeful.