How long to sample (100Hz) to be able to use Allan deviation for Kalibr? #64
Comments
|
This is what I got after about 2 hours (tried to keep the temperature as stable as possible). Something looks weird though: the values for all axis starts going downwards towards the end of the chart, while they should go up only.
|
|
This Allan deviation plot looks reasonable. Note that a.) the precision of the Allan deviation estimate naturally decreases for higher integration times \tau and b.) sensors rarely show a noise behavior that matches the "white noise + random walk" model you refer to (which would indeed lead to a monotonic increase for \tau -> \infty), but rather show flickering or other noise characteristics. If you want to make sure your math is right, simulate N sample paths using parameters deduced from this plot and run them through your Allan deviation computation. Please indicate the units (g or m/s^2) and which accelerometer you are using. 2h should be enough for the accel you are using to be in the ballpark with the parameters. |
|
Hey @nikolicj thanks a ton for your answer, it clarified things for me. The units are So I think white noise in this case would be: Thanks! |
|
Great. The 6s has two accels (see http://www.macrumors.com/2014/09/26/iphone-6-6-plus-two-accelerometers/). One of which, Bosch's BMA280 has an "output noise density" of It would be interesting, too, to have a look at the PSD of the noise, to see if the chip is properly configured. Try |
|
The article refers to iPhone 6, but the components didn't seem to change for 6s. From what I understand the external accelerator is the more capable one and used at high frequencies, the other one is used only for things like screen flips. This is what I get for the PSD of the x axis:
This is y:
And this is z:
Regarding the bias, how would I proceed to do the line fitting with those irregular +0.5 curves? Thanks! |
|
For the bias I extrapolated a value of about |
|
Yes. Although I would consider to start with a higher value to make sure the bias fluctuations of the z-axis are covered. How about |
|
The value for the "white noise density" sounds about right, too. Again, consider increasing it a bit due to the poorer performance of the z axis. |
|
Interesting PSD plots. I was just asking out of curiosity. You can plot it in a more easy to read log-log fashion as follows: |
|
@nikolicj yeah if you count that What do you mean by extended mode? Kalibr extended mode? If yes, I'm currently not using that. Also, I tried your code, but couldn't make it work (procparam missing). Thanks for your input! |
|
Now, I tried to pass these parameters + subpixel camera calibration to the cam + imu calibration algorithm, but it doesn't converge to a value that makes sense (huge errors in pixels). I am wondering if it is because I take the timestamp from the accelerometer and assign them to the gyro samples too, to build a single CSV file, while iOS is actually giving me different times for raw gyro and raw accelerometer. Should I treat them as separate IMUs in Kalibr (don't know if it's possible)? Also, there are other two issues with timing:
Plus, when rotating the phone fast, the effects of rolling shutter probably start show to up, even if keeping exposure at 20ms. Seems like there are a lot of potential issues. 😞 These are some of the results:
PS: I saw you just recently merged the extended mode 👍 |
|
Update: I tried with the latest Kalibr version and I'm now getting an error at optimization time: This is with and without the EDIT: I removed the option Will still try with a better dataset. |
|
You may want to try both |
|
OK I investigated and I was able to retrieve the actual time a frame is buffered and I also know that IMU time is based on the same clock of the camera time, so they are natively synchronized. Also just found out (yikes) I was passing acceleration in |
|
Haha, it would have been interesting to see whether that flaw would have been taken care of by estimating an appropriate scaling factor for the acceleration measurements (with the |
|
Oh I didn't think about using that option to fix the acceleration! My last try output: It seems like the accelerometer always has the biggest error in my tests. |
|
I played with the IMU intrinsics like I saw someone did in another Github issue and by increasing the values a lot I got to this result: Seems like LM is converging fast. But does increasing IMU intrinsics make sense? The only thing I see wrong in the calibration is the position of the IMU compared to the camera on the X axis (25cm away). I will try with a longer dataset. |
|
Both, reprojection error and accelerometer residuals are still large. We commonly get reprojection errors that are at least 6 times smaller and accelerometer residuals which are about 10 times smaller. Are you using the |
|
Hey, sorry for the late response: I tried One question I have is, do I need to excite the accelerometer DoFs for a good range (distance) or intensity (force)? I assume exciting the gyro involves rotating for a while by a big angle. Could you point me to resources that explain this process? I'll keep you updated. Thanks a ton. |
|
For us, 10 seconds datasets worked well, so you should probably be fine with the memory of your phone. You will need to excite the rotational degrees of freedom in order to render the position of the accelerometers observable. The "delta angles traveled" are less important here than angular velocities. At the same time, you are constrained by the range of your sensors (saturations) and the rolling shutter effect and motion blur, so please do not overdo it. |
|
Oh that's gold! I was doing exactly the opposite: long slow movements. I will try your approach next. Also, I am using a big Apriltag pattern. |
|
That improved the results without the necessity of increasing noise parameters and now I use linear interpolation to get gyro values at accelerometer times (to cope with the ros sensor message format), but it still is not good enough. It's hard to strike a balance between rolling shutter and sensor range. |
|
Yes, that is true. You could try to combine bits and pieces from PR #65 (please see this paper for details) with the IMU calibration for rolling shutter/IMU calibration. We might also be able to offer another solution in the future, but for now, you are on your own. Another fix that you may want to try is a higher frame rate (you should be able to crank that up to 60 fps in the iPhone 6), which may result in an overall decreased exposure time and line delay. For a decreased computational load, you could still consider omitting some of the images. |
|
OK will look into the rolling shutter logic, see if I can make it work. Still trying different combination of speed of rotation and dataset length. Yeah, the framerate is 25fps, but I manually locked exposure to 3ms, which resulted in much less motion blur, but you can still see wide effects of the rolling shutter. |
|
@rehderj if I understood it right, you suggested to use that algorithm to calibrate the camera line delay and then use the same PnP function to locate features while doing cam + IMU yes? |
|
Well, I would do the following: Leave all that untouched, hoping for the best, and plainly try to exchange the reprojection error formulation to Luc's: |
|
Sounds exciting, looking forward to it. Will let you know how it goes. |
|
Haha, i get that response a lot. People are usually overly excited about all things calibration ;) |
|
That's the first step of a long journey ;) |
|
Going to close this thread and open a more relevant one. |
I'm following https://github.com/ethz-asl/kalibr/wiki/IMU-Noise-Model
How long should I sample to be able to have a reliable base to calculate the Allan deviation needed to extract the noise parameters needed by Kalibr?
The text was updated successfully, but these errors were encountered: