minimu9-ahrs-calibrator appears to get stuck in "tune" function

[juliaashk]

Thanks for this awesome project! This is a great demo and I really appreciate your tutorial.

I just wanted to let you know that for some reason when I run minimu9-ahrs-calibrate after the message "Optimizing calibration" the program appears to get stuck for me. It appears that the cause is that the "while True" condition in "tune" of "minimu9-ahrs-calibrator" is never satisfied.

In a future rev it might be a nice idea to terminate this loop after a certain amount of time or if the calibration results are within a certain (adjustable) tolerance. Also some in line comments would be a great bonus for easier debugging.

[DavidEGrayson]

You can debug it by changing verbose to True at the top. The loop is supposed to be terminated by the return statement that is inside it which should run after it finds a local maximum in the 6-dimensional space it is searching.

I knew the algorithm wasn't very efficient, but today I discovered that it is not even guaranteed to terminate. What I am seeing is that (for my particular data set) the algorithm keeps on changing the calibration to be more and more extreme, and the algorithm thinks that these changes are good because all the sample points are getting squished into a smaller and smaller space which is close to the surface of the unit sphere.

[harmsm]

I noticed this problem myself and was considering re-implementing the minimization using scipy, which has a bunch of nice algorithms for this sort of thing. Then again, I probably won't get to such an attempt until this weekend, so hopefully it will be fixed by then! Thanks for the great project.

[DavidEGrayson]

Cool, I am looking in to scipy.optimize.fmin right now.

[DavidEGrayson]

On my development branch, you can get a version of the calibrator script that uses scipy.optimize.fmin:

https://github.com/DavidEGrayson/minimu9-ahrs/tree/dev/david/v3

It's pretty slow right now; I'll see if I can make it faster.

[DavidEGrayson]

I just released version 2.0.0, which uses SciPy to do the optimization. It takes about 18 minutes on my Raspberry Pi, but at least it is guaranteed to terminate.

I noticed that if I feed it a subset of my particular calibration data (e.g. only the first 300 readings) then it produces a ridiculous calibration where many of the numbers are over ten digits long. I made the script print a warning so people can at least be aware that their calibration is wrong and try again. This is the same problem that caused the original algorithm to never terminate; any kind of optimization algorithm might try to squish all the sample points together because it can get a higher score by doing that. The algorithm eventually terminates because I told SciPy to stop after 1000 iterations.