We are currently using the BHI160B Gravity vector to calauclate pitch and roll of a platform. We electronically control the vertical height of the lef and right sides of the platform, and the front of the platform is set in space, unable to move. So, if we lift both sides up/down then the pitch changes. If we move one side and not the other, then the roll changes (and also a bit of pitch too, but you get the idea I'm trying to make).
Experimentally, we move fairly slow, around one degree per second. We also only move around 2-3 degrees in total. The issue we have found is that once we have started moving, the calculated pitch and roll substantially lags the actual pitch and roll. This seems to be because the output of the accelerometer and gyroscope sensor fusion (the gravity vector) is heavily damped... after a movement, it can take up to 10 seconds for the gravity vector to approximate the unchanging acceleration vector! This typically results in extreme over/under shoot in our application.
I guess my questions are
Solved! Go to Solution.
For your test, could we know what are your end products?
For your description "Experimentally, we move fairly slow, around one degree per second. We also only move around 2-3 degrees in total. The issue we have found is that once we have started moving, the calculated pitch and roll substantially lags the actual pitch and roll. This seems to be because the output of the accelerometer and gyroscope sensor fusion (the gravity vector) is heavily damped... after a movement, it can take up to 10 seconds for the gravity vector to approximate the unchanging acceleration vector! This typically results in extreme over/under shoot in our application.", how did it move in a second? Did you have log data?
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.
Sorry for the delay reply.
After our internal discussion, we would like to know have you compared it with other part? Like BHI260 which has better fusion performance.
No, we have not compared to any other off the shelf IMU ICs integrated into our custom PCB. Although, we did generate a proof of concept about 1 year ago with an aceinna module (OpenIMU300RI) that worked extremely well in the same conditions.
I've noticed the BHI160 has gone obsolete anyways, so this thread is now redundant. We will have to investigate implementation of an alternative.