Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 8 of 8

Thread: Motion Sensor Calibration Tool Parameter Understanding

  1. #1

    Motion Sensor Calibration Tool Parameter Understanding

    I am using Motion Sensor Calibration Tool for calibrate the Magnetometer Sensor. I want to know about the parameters which are showing quality of calibration.
    The parameters are:
    1. Gaps
    2. Variance
    3. Wobble
    4. Fit Error

    What is significant of above parameters and how they are useful for quality of calibration? I want to know about those parameter because I am trying to make the firmware which is useful without Motion calibration Tool.

    Please help me to understand this and Many many thanks in Advance.

    Thanks and Regards,

  2. #2
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    The most precise info about each of these is the MotionCal source code.

    Look at quality.c.

    As you move the sensor, the 3D visualization should appear as a sphere.

    To answer your question very briefly...

    Gaps tries to measure how much of the sphere's surface is missing data points.

    Variance tries to measure how much of the data is not located on the (imagined) surface of the sphere.

    Wobble tries to show how far an estimated the "center of mass" is from the ideal center.

    Fit error comes from the algorithm which actually produces the calibration coefficients. The main reason I wrote MotionCal is because the fit error can sometimes be low for a terrible set of data. Think of fitting a linear line onto a set of 2D data on a graph. You can have a group of incomplete data on just one tiny part of the graph, which by chance happen to fall well onto a straight line. Intuitively you wouldn't draw a line through such a small group and claim that line represents a trend across the large graph. A set of poor magnetic measurements which happen to fit the model well is the same sort of situation, but fitting a sphere onto 3D data, rather than fitting a linear line to 2D data.

    Also, if you attempt calibration near the presence of a strong magnetic field or too close to iron or steel objects that run parallel to power wires or anything else that induces a magnetic field, you can end up with an ellipse or other weird shape. The fitting algorithm is remarkably good at transforming an obviously wrong ellipse into coefficients. Fit error alone can't warn you that you've got garbage data. The best way to tell if your calibration is based on good measurements is to visually confirm the 3D animation really is a sphere.

    I designed MotioCal's data management to prioritize replacing bad data points with good ones, so the results (usually) converge rapidly to a sphere. But if you start out with really horrible data, well, I'm not that good at anticipating such scenarios. Some really bad initial data cases can cause it to never converge to a useful data set. You can experience this if you hold a small magnet in one hand while moving the sensor around with your other hand. It's kind of fun to wave the magnet near the sensor and see the calibration go wild. You can also see my attempts to make MotionCal converge back to sphere by purging the bad measurements over time, and the limitations it has. The important point to remember is MotionCal isn't treating data in a dispassionate or purely objective way. It's making prioritized decisions to try to keep good data and purge bad. But MotionCal is far from the sort guarantee of convergence you might expect from something designed by academians who specialize in rigorous mathematical proofs. Much of how MotionCal works is ad-hoc stuff I just made up. I'm pretty good, but not that good.

    Those 3 other numerical estimates are a poor substitute for human vision and intelligent judgement. They mainly just provide a way to keep the button to commit the calibration disabled in the early phase while the data is so obviously not a good sphere. Don't get seduced into the idea that those 4 numerical estimates are really meaningful. The first 3 are just crude estimates I made up. They are based solely on my own personal intuition & experimentation. They're not any sort of well recognized algorithm, only things I made up for the sake of a user-friendly GUI. None of the 4 are perfect. The idea is that hopefully at least 1 of the 4 will keep the send cal button disabled while the data is so bad that it should not be used. Those numbers aren't meant to prove the data is good. They only reject very bad data, and even that isn't 100% guaranteed.

    The real validation of quality is human judgement of whether the 3D animation actually resembles a perfect sphere. That's why I went to so much trouble to mess with OpenGL programming!
    Last edited by PaulStoffregen; 01-28-2020 at 10:33 AM.

  3. #3
    Hi Paul,

    Thank you so much for providing the information.
    As earlier I said, we are trying to port Motioncal sourcecode for firmware in our device. But after porting the code we are facing the problem.
    We are not getting updated value of gaps and fit-error in firmware. After a few seconds we are showing on serial prints that data is not updating for gaps and it is stuck there only.
    For your reference, I attached zip file of code here.

    Please have look once the code which I am providing to you and say me where we are making mistakes.

    Attached Files Attached Files

  4. #4
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Sorry, I don't have time to review your code.

  5. #5
    Thank you so much, Paul, for your support. As we tried to calibration inside the firmware that we achieved.
    We installed our device on the oil tank and also we calibrate our device on the tank where we installed. But the problem now we are facing is that with time being yaw value is changing, while our device is in steady condition. Is heavy metal structure can be a problem for fluctuating the yaw value? What could be the solution for getting yaw value stable?


  6. #6
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    So did you get calibration implemented in the sketch/firmware? can you post your working calibration sketch?

  7. #7
    Yes, I implemented code and we succeed in the calibration.
    Here I am sharing you the link of github:

    If anyone can help it will good for me as a solution. If only any information than also it will helpful for me.

  8. #8
    We have deployed the calibration firmware and deployed at site performing rotating calibration at the time of deployement. But after few days, the YAW value has started showing fluctuation.

    It is not feasible for us to do the rotating calibration every time as it requires human-intervation at site, so we are trying to integrate auto-calibration support of IC. Any suggestion - will it workout?

    We have not considered Acceslrometer calibration explicitly, and we always get zero for related calibration offset values while performing rotating calibration. Will Acceslrometer calibration require?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts