We are using ZED Mini cameras for a custom built AR headset. For getting the orientation of our headset we use the camera’s IMU information.
From time to time it happens that the IMU calibration information gets lost and the camera is “spinning” in the “ZED Sensor Viewer” tool as described in the forum entry Something’s wrong with my Zed Mini IMU.
Re-calibrating works to recover from that state.
Is there any way how we can detect the “error” state from within our application so that we can inform our users that a calibration is necessary?
Do you have any idea what may cause the IMU loosing its calibration information?
When the ZED SDK opens the camera it performs a quick recalibration of the IMU to remove gyro biases that can be caused by temperature variations.
If your camera moves while the calibration is performed, it’s possible that wrong values are stored and a reset is required.
The same problem can happen if the calibration is performed with the camera placed on the same surface where a PC fan is generating little vibrations.
How long does this quick recalibration take and when in the initialization phase is it done?
Is there any way how we can detect these wrong values and react on it with the help of the SDK?
It has been a while since last time, but as we are still facing the problems mentioned above I am contacting you again regarding this issue.
I just read in the release notes of the new SDK version 5.5 that there has been some work done that may help us to solve the issue:
Fixed the IMU orientation returned by getSensorsData() rotating continuously on a perfectly static camera, with camera_moving_state stuck on MOVING, when an invalid gyroscope bias had previously been stored on the device. Such a stored value is now detected and ignored, the bias is re-estimated automatically, and the invalid value can no longer be written back to the camera. Affected cameras recover on their own; running ZED Calibration is no longer needed.
If that works for the ZED Mini then at least the spinning camera issue would be solved I guess.
But we also have the issue that the IMU reports wrong directions from one system start to another. May this have something to do with the temperature compensation or do you think that it is purely a problem of vibrations?
The problem with the IMU recalibration is that the systems do not have a monitor / mouse / keyboard attached. They are remotely controlled via a web interface.
Another point is that in my experience the faulty behaviour is very rare, but from the field we are getting the feedback that it happens more often or even regularly.
Up to now I could not find a way how I could force the IMU into the failure state, so reproducing the issue and looking for a solution is quite hard.
Recalibration works of course and solves the issue. We are currently looking for ways how we can implement it in our system so that it works for our users.
Our next release is on 5.2.3 and we did not test 5.5 yet. But as said, it is very hard, if not impossible, for me to reproduce the behaviour or to bring a test system into the failure state, so that I can further investigate it.