Calculation steps 1-3: Scale and bias temperature compensation
This section shows how to use the Cal program to generate temperature based bias, scale and alignment compensation parameters for your IMU.
The process generates 3rd order polynomial equations to describe sensor bias curves as function of temperature. The cal program also generates initial scale and alignment parameters, which are refined later with the Sim3 program.
It requires using both static and dynamic log files, so you should have completed the steps for gathering both dynamic and static log files and made sure to to have analysed and prepared the data before proceeding any further. Insert links
If you run into problems with any of the following steps, scroll down to the troubleshooting section, below.
Step 1, cal -rate: Gyro (rate) temperature compensation
This step uses only the static log files as input.
Select the ‘Step1: cal –rate‘ tab and hit ‘Start cal.‘ button. The output screen will now show the gyro bias calculations. It will run for a couple of minutes.
Once finished the output will look similar to this:
Using MAE to judge solution quality
You will notice that a number: MAE = 0.000119 was printed. The MAE (Median Absolute Error) is an expression of the quality of the solution calculated. The lower, the better.
The output will show one MAE value for each static log file if more than one file is used.A log file with with a significantly higher MAE than the others could be an indication of poor quality of that data and you should consider not using or replacing that file with a better one.
It can be a good idea to re-run the cal steps a few times and pick the set of defines that has the lowest MAE across the files used.
Saving generated parameters
Select the output and place it on the clipboard with CTRL + C, then click on the ‘All generated parameter ‘ button.
Paste the previous selected data in this screen with CTRL + V
and click ‘save to para file‘ button:
Params from step 1 is saved, Proceed to step 2
Step 2, cal -acc: ACC scale, align and temperature compensation
In this step we calculate scale, align and bias values for the ACC.
NOTE: This step and step 3 both the static and dynamic log files as input.
Click on ‘Step2: cal –acc‘ tab and the ‘Start cal.‘ button. This will take a bit longer to run. When it is done, select the output and paste it to the ‘All generated parameter’ screen, after the data parameters already in there.
Using MAE and AVG in step 2
In this step there are 2 values to pay attention to. MAE and AVG – Magnitude average. If you scroll up you will see MAE and AVG printed for each file used in step 2. Take a look at the dynamic acc stats printed just above the defines.
Dynamic acc stats:
The dynamic ACC state is a good indicator on overall solution quality. The above example is pretty much ideal with a MAE around 0.104. You should expect to MAE of < 0.15 for a good dynamic file.
You will also notice a line saying “AVG” for each of the files. This expresses the average ACC magnitude for each of the files used. The ideal is to get as close as possible to 9.806 (1G) as possible. So the above example is very close to ideal.
Some AVG variation is to be expected on the static files (up to +/. 0.5), but if you see the dynamic file AVG beeing off by more than +/- 0.2, its an indication that the data is not good or there was problems in the calculations. Rerun calculations or replace files
|Reminder: don’t forget to ‘save to para file’. after the data paste.|
Step 3: calculation of the mag bias.
This step uses both the static and dynamic log files along with the previusly generated param file.
The goal of the exercise is to get the lowest MAE and an Average (AVG) as close to 2.0 as possible. Unlike the 2 previous steps, this step requires the user to abort the calculations manually.
This means that you have to watch the MAE and AVG and abort at the right time. Look at the MAE printed at the bottom as the calculations proceed. The moment MAE begins to rise, hit the abort button and save the outputted defines to the params file. You should run this step a few times and save params from the best run that acheives the lowest MAE and an AVG as close to 2.0 as possible.
Let it run too far with raising MAE and the solution will diverge, the program will abort and print “nan” (not a number)
In some cases you can get the MAE to drop further and get AVG closer to 2.0 by performing second and third runs. Use the below procedure.
- Run ‘Step 3: cal –mag‘ the first time as oulined above.
- Copy/paste the output to ‘All generated parameter‘ window and save it.
- Run the calculation again, abort when MAE begins to rise.
- If MAE has not dropped and AVG did not get closer to 2.0 since last run, stop the process and use the params you have.
- If If MAE and AVG did improve, copy/paste the output to the generated params file, replacing the earlier generated mag defines.
- Repeat from 3
After completing step 3, you can load the generated params file onto your AQ board and connect it to QGC. This should make the artificial horizon line up. If
Once done, you now have data that will be used in the parameter estimation simulation in the next steps. Don’t close any screens, move to the next page.
Steps 1-3 Troubleshooting
Possible issues include very high MAE values (if you don’t see at least one zero after the decimal point in the MAE, it is probably too high). It is also possible to “confuse” the Cal program with bad, or insufficient, data from the logs. Symptoms of this include cal.exe crashing, taking a long time to run and/or not stopping the calculations automatically, not incrementing the loop count in the output, or other anomalous behavior.
Typically the cure for these problems is using a different data set. This may mean performing a new dynamic calibration dance (dynamic logs are a common source of bad data, it takes time to do it right). Or it may mean trying a different combination of static logs. Sometimes a glitch in one log can “cascade” and influence the whole data set, but only when combined with a particular set of other logs. It can get a bit tricky, but the best approach is to start removing/adding log files one at a time and observe the result and look at the MAEs and AVGs for individual files to single out and remove bad data. Patience is key.
A common source of data errors are “faulty” SD cards. A card may appear to work fine but contain some bad memory blocks. Or it may simply be unable to keep up with the data rate requirements of the AQ logging. To avoid these problems, make sure you use a fast micro SD card from the recommended list, and scan the card for errors using a utility such as the built-in Windows disk checker (R-click on the drive, Properties -> Tools -> Check for errors).
Probably the best thing to do if you are having trouble with your calculations or doubts about your data, is to post your issue and your log graphs on the forums. Here is an example post with all the relevant graphs provided.