PaulStoffregen
Well-known member
I'm just now trying to get caught up to the last few days of forum stuff, while I was working intensely on the calibration program. Let's see if I can get these answered quickly...
Things I'm still wondering about:
- Why does the calibration get dramatically worse sometimes?
The two likely scenarios involve getting the sensor near a magnet or strong electrical current (which isn't balanced by an equal return current in another close-by wire), or sitting the board on or near iron or ferrous metal that shields it from the Earth's magnetic field.
This comment in the code, and some others in the function just above it, might help to explain some of the issues with how data is interpreted.
https://github.com/PaulStoffregen/MotionCal/blob/master/rawdata.c#L100
[*]Why does the sphere of dots slowly roll when the Prop Shield is relatively still and certainly not rolling?
The fusion algorithms primarily use the gyroscope for rapid response, and the accelerometer and magnetometer for long-term stable correction. The problem is the magnetometer output is changing as the cal takes form, so a lot of very slow correction can be needed. I've tried a few times to jump-start that process, but the algorithms are complex and my main focus has been on improving the cal itself, and fixing a number of GUI issues.
If you've achieved a good cal, eventually it should come to a stop.
[*]Why do the Accelerometer and Gyroscope fields report all zeros?
I haven't implemented calibration of those. It's planned, but may not happen for weeks or even months.
[*]After "Send Calibration" is performed, is there anything needed in subsequent sketches to make use of the calibration?
The calibration is used automatically.
[*]Is there any way to capture the calibration data or metadata other than attempting a screen shot as quickly as possible after sending the calibration?
You can run File > Examples > NXPMotionSense > PrintCalibration
[*]Which parameter(s) should be optimized? I'm assuming first priority would be getting the "Fit Error" as low as possible. Is 1.8% a good number?
Yes. 4% is good and 2% is excellent.
In the latest versions, the Send Cal button enables when all 4 meet a reasonable criteria.
[*]How long should the calibration process take? It seems long to me.
It really depends on how quickly you manage to move the sensor through enough angular positions. Maybe I should shoot a video showing a few tricks I've learned? (a decent quality video will draw a lot of time away from other stuff....)
One technique that's surprisingly effective is holding the USB cable a few inches away from the Teensy and rapidly twirling & waving the cable around. Doing that with a vigorous motion that feels somewhat risky or irresponsible for a few seconds with the cable pointing up and a few seconds pointing down usually get the gaps to under 10%.
[*]When should re-calibration be done? Obviously if the environment changes or the readings get worse, but is it expected that it's done daily, annually, just once, etc?
That's a good question.
My hope is just once after final assembly can be adequate. Maybe OneHorse and others who've worked with these types of sensors can comment?
Freescale publishes code that preforms the calibration continuously. I don't like it. The main reason the Prop Shield was delayed so long was how confusing the sensor is (basically doesn't work and does very wrong things) when that code produces poor calibration. Even on a good day, it rarely achieves a fit as good as you can get and visually confirm with the calibration tool.
MotionCal feature request: Add a menu item to load the appropriate hex file to the Teensy.
If this is not a good idea, perhaps add some help text with the URL of the instructions for preparing the Teensy for Prop Shield calibration.
That is a good idea, but quite a lot of work. Perhaps version 2.0.
[Edit: and error messages about being unable to communicate with the Teensy/Prop Shield would be helpful, too.]
Yes. Probably the only other feature that's likely to happen soon (next few weeks) is improved status display. As you might guess from my absence over the last few days, GUI programming takes a lot of fiddly work. I believe now, or with better status display, we're pretty much a solid 1.0 release point.