Hi, See the below description, it should be enough to get us started. The IMU is used for monitoring the angle (roll and pitch) of a large (~2m wide x ~5m long) platform. The platform is fixed in space at the front. The height of each platform's side is controlled electronically (let's call this the electronic side height controller). With one side at max height and one side at min height, the roll of the platform is around 3 degrees. Similarly, the maximum change in pitch is around 2 degrees. It takes the system around 3 seconds to move 3 degrees in both pitch and roll and the movement is approximately linear, hence the 1 degree per second. We require accuracy down to 0.05 degrees (which is implemented, it just takes a really long time to stabilise readings). The IMU reports back to the main controller the gravity vector, which is converted to spherical to find the approximate angles. The angles are used by the electronic side height controller to know which direction to move and when to stop, depending on an initial target angle for roll and pitch. I don't have a data stream for you just yet, and it could be difficult to implement in a worthwhile manner. I'd need a known-good reference pitch and roll system and some form of intermediary timekeeping and control app to ensure data is stored and compared correctly. This requires time and effort, and unfortunately I will no longer be with the company in 3 weeks. I'm hoping the below is enough to discuss the next step to achieve a faster response with the IMU for our use case. I'm currently viewing the live calculated angles via a debugger connected to the system in-situ. To ensure this isn't some form of lag between system -> debugger -> my eyes, I've also implemented a calculation for pitch and roll based on just the acceleration vector (no use of BSX fusion core AFAIK). A test was performed where the sides were shot up/down for specific times, just to see how the IMU reacted. What I'm seeing is the acceleromer calculated angles leading the gravity calculated values by up to 10 seconds i.e. The accelerometer output stops changing and permits a correct angle calculation as soon as the sides stop moving, but it takes 10 seconds for the gravity vector to offfer the same. This points to the issue lying with the BSX fusion core's implementation wrt our specific use case. When something like this happens with a Kalman filter, I would typically just tune the filter to undamp it, but I can't find this feature with the Bosch range of IMUs. I would just use the accelerometer output, but there are other sub-systems that cause the electronic side height controller to vibrate in a full system setup, throwing off the acclerometer calculated angles by an unaccepetable amount. The gravity vector ignores these vibrations very, very well, but retains the large delay before settling. This leaves me with a requirement to use the BHI160B's gravity sensor, but it needs to settle faster. Even if I could get it down to settling within 1s and implement a "estimate, shoot, wait and check" scheme, that would be acceptable. I can't dow that now because a "wait" of 10 seconds is just too long for the overall implementation. I've tried turning the gravity virtual sensor on and off every ~100ms in an effort to reset the fusion core. It definitely reduces the time, but not considerbaly. In summary, what I'm looking for is a solution to reduce the delay within the core's fusion of Accelerometer and gyroscope readings, as movements at one degree per second with a total movement of 0.05-3 degrees take 10-20 times longer than our target stabilisation times.
... View more