I am trying to use APM 2.0.15RC3 to do compass calibration with my 3DR Y6B running 3.2.rc12.
I have tried twice (this time as RC1 was failing with 3.2RC9) and get the OK dialog with both compass readings.
I can’t save the params files, as this appears to be another bug on RC3 on OS X Mavericks, so have attached a couple of screen shots of the compass params
[attachment=0]Screen Shot 2014-10-16 at 09.52.35.png[/attachment]
[attachment=1]Screen Shot 2014-10-16 at 09.41.21.png[/attachment]
I have a fix for the save dialog not showing, I will post a link to a daily build with a fix later today
Thanks Bill.
Unfortunately the APM dual compass calibration doesn’t appear to be working, as I’m not alone in having this problem…
See :
diydrones.com/forum/topics/arduc … _com_forum
Do I need to report this somewhere as an APM bug?
As stated Dual Compass calibration was added with 2.0.15-rc1.
Can you post the log of you attempting a dual calibration. The logs are available from ~/apmplanner2 directory.
The process is
1: start program
2: attempt compass calibration
3: quit program
post a compressed ~/apmplanner2/log.txt to this forum (i.e… zip it!)
Thx
I used the latest build and confirmed that I can save the params file 
Still no joy with compass calibration. I even disconnected and reconnected, but still the pre-arm check failure.
In passing it looks like the app is trying to backup the current log.txt to log.txt.1… when you start up, but these end up as 0 bytes, so it looks like no backup. Not sure if that is intended?
I’ve attached the ZIP of the compass calibration attempt.
The log confirms the messages have been sent and confirmed by the APM as being set.
INFO 2014-10-17T15:24:04.516 New Compass Offset to be set are: -34.0229 , -55.9281 , 101.144
INFO 2014-10-17T15:24:04.516 New Compass 2 Offset to be set are: 54.499 , 83.535 , 6.50348
DEBUG 2014-10-17T15:24:04.612 APL::parameterChanged: "COMPASS_OFS_X" char= "0" int= -34 float= -34.0229
DEBUG 2014-10-17T15:24:04.613 APL::parameterChanged: "COMPASS_OFS_Y" char= "0" int= -56 float= -55.9281
DEBUG 2014-10-17T15:24:04.613 APL::parameterChanged: "COMPASS_OFS_Z" char= "0" int= 101 float= 101.144
DEBUG 2014-10-17T15:24:04.614 APL::parameterChanged: "COMPASS_OFS2_X" char= "0" int= 54 float= 54.499
DEBUG 2014-10-17T15:24:04.615 APL::parameterChanged: "COMPASS_OFS2_Y" char= "0" int= 84 float= 83.535
DEBUG 2014-10-17T15:24:04.615 APL::parameterChanged: "COMPASS_OFS2_Z" char= "0" int= 7 float= 6.50348
The APL::parameterChanged message is the confirmation.
My suggestion would be to format the eeprom and try again. This can be done in the terminal, or you can trigger this over mavlink by click the ‘reset to defaults’ in the full parameter view
Let me know if that helps
Unfortunately still no joy.
This is after a reset and then going through a compass calibration, accelerometer calibration and finally a radio calibration.
I also got a complete APM crash when I was clicking in the declination to change the minutes value.
I’ve attached the log.txt and APM crash in the ZIP below
OK I gave the latest MP beta a try in Parallels.
It did successfully carry out the compass calibration, so I’m afraid there is definitely a problem with the APM compass calibration code.
I saved the params files at three steps:
Y6B_latest - the param state from APM before MP compass calibration.
MissionPlannerY6B - saved state from MP after just doing the compass calibration.
AfterMP_CC_Y6B - reading the params in APM after doing the MP compass calibration
Hope this helps.
Adding a link to another person suffering from compass calibration woes in APM:
viewtopic.php?f=100&t=10084
It’s a shame we have to revert to Windows VMs to solve the problem…
There is an issue raised, it will be checked and fixed in the next release.
It’s not ignored github.com/diydrones/apm_planner/issues/505
Finally I can confirm this!
After being a little skeptical since the APM Planner showed both compass offsets and also listed everything fine in the full parameter list and log (even after reconnecting everything), I can now confirm that there seems to be some “other” place in the copter software where those settings need to be applied when the compass calib gets finished…
On both, Mac and Windows the latest APM Planner just seems to work but the copter will still show pre-arm check compass calibration.
After using the latest Mission Planner to do the calibration it didn’t show the second compass offsets in the full parameter list although it confirmed them in the second alert after calibration. But that does just seem like a UI glitch. After reconnecting the MP and reading all params it showed both offsets just fine and I could finally arm the copter again.
Connecting with the APM Planner on the Mac now also works just fine.
Yey!!!
Thanks a lot and let’s hope that the APM Planner compass calibration gets fixed soon.
Verified dual compass calibration works as expected.
View In Full Param View
This seems like an important fix. When will this be released as a standard download?
Thanks!
There is no fix per se. I just did a compass calibration to verify it works, and it does. I do not know why the OP was having an issue. My suggestion was to format the eprom and try again.
@ billbonney: As I said above I ran into the same problem and solution as meavydev these days. My APM Planner too said that it calibrated BOTH compasses just fine and I also could find both parameter settings within the full parameter list (even after reboot). Though, it again and again throw the warning that the compass is not calibrated and I could not arm it.
So there seemed to be still missing something somewhere else “within the copter” despite just those parameters…
I tried everything around 5 times even with resetting the whole params using the terminal and starting from scratch…
Finally, after doing exactly the same calibration from within the “old” Mission Planner, the warning got fixed - even when I went back into the APM Planner.
As a side note: The calibration results from APM Planner and Mission Planner were almost exactly the same…
I looked at the specific locations in the code within both tools and maybe I found the little difference which is responsible here.
(Please keep in mind that I’m not an expert here and I’m doing just a little guessing by trying to understand what the code should do 
)
Here’s a snipped of the Mission Planner code:
// disable learning
MainV2.comPort.setParam("COMPASS_LEARN", 0);
if (!MainV2.comPort.SetSensorOffsets(MAVLinkInterface.sensoroffsetsenum.magnetometer, (float)ofs[0], (float)ofs[1], (float)ofs[2]))
{
// set values
MainV2.comPort.setParam("COMPASS_OFS_X", (float)ofs[0]);
MainV2.comPort.setParam("COMPASS_OFS_Y", (float)ofs[1]);
MainV2.comPort.setParam("COMPASS_OFS_Z", (float)ofs[2]);
}
// disable learning
MainV2.comPort.setParam("COMPASS_LEARN", 0);
if (!MainV2.comPort.SetSensorOffsets(MAVLinkInterface.sensoroffsetsenum.second_magnetometer, (float)ofs[0], (float)ofs[1], (float)ofs[2]))
{
// set values
MainV2.comPort.setParam("COMPASS_OFS2_X", (float)ofs[0]);
MainV2.comPort.setParam("COMPASS_OFS2_Y", (float)ofs[1]);
MainV2.comPort.setParam("COMPASS_OFS2_Z", (float)ofs[2]);
}As you can see it sets the params which the APM Planner also does in CompassConfig.cc:417:
void CompassConfig::saveOffsets(alglib::real_1d_array* offset, alglib::real_1d_array* offset2)
{
alglib::real_1d_array& ofs = *offset;
float xOffset = static_cast<float>(ofs[0]);
float yOffset = static_cast<float>(ofs[1]);
float zOffset = static_cast<float>(ofs[2]);
QLOG_INFO() << "New Compass Offset to be set are: " << xOffset
<< ", " << yOffset
<< ", " << zOffset;
QGCUASParamManager* paramMgr = m_uas->getParamManager();
paramMgr->setParameter(1, "COMPASS_LEARN", 0);
// set values
paramMgr->setParameter(1, "COMPASS_OFS_X", xOffset);
paramMgr->setParameter(1, "COMPASS_OFS_Y", yOffset);
paramMgr->setParameter(1, "COMPASS_OFS_Z", zOffset);
QString message = tr("New offsets (Compass 1) are \n\nx:") + QString::number(xOffset,'f',3)
+ " y:" + QString::number(yOffset,'f',3) + " z:" + QString::number(zOffset,'f',3);
if (m_haveSecondCompass) {
alglib::real_1d_array& ofs2 = *offset2;
float xOffset2 = static_cast<float>(ofs2[0]);
float yOffset2 = static_cast<float>(ofs2[1]);
float zOffset2 = static_cast<float>(ofs2[2]);
QLOG_INFO() << "New Compass 2 Offset to be set are: " << xOffset2
<< ", " << yOffset2
<< ", " << zOffset2;
paramMgr->setParameter(1, "COMPASS_OFS2_X", xOffset2);
paramMgr->setParameter(1, "COMPASS_OFS2_Y", yOffset2);
paramMgr->setParameter(1, "COMPASS_OFS2_Z", zOffset2);
message.append(tr("\n\nNew offsets (Compass 2) are \n\nx:") + QString::number(xOffset2,'f',3)
+ " y:" + QString::number(yOffset2,'f',3) + " z:" + QString::number(zOffset2,'f',3));
}
cleanup();
QMessageBox::information(this, tr("New Compass Offsets"), message + tr("\n\nThese have been saved for you."));
}But when you look close again to the way Mission Planner does it, you’ll find that it does something else:
if (!MainV2.comPort.SetSensorOffsets(MAVLinkInterface.sensoroffsetsenum.magnetometer, (float)ofs[0], (float)ofs[1], (float)ofs[2]))And this seems to be it. It sets the sensor offsets using a mavlink command instead of just setting the params through the com port interface:
public bool SetSensorOffsets(sensoroffsetsenum sensor, float x, float y, float z)
{
return doCommand(MAV_CMD.PREFLIGHT_SET_SENSOR_OFFSETS,(int)sensor,x,y,z,0,0,0);
}This “doCommand()” essentially generates a mavlink packet and sends it to the pixhawk which I think treats the whole sensor setup a little different, which is finally the reason why the calibration worked only by using Mission Planner.
So this seems to be a little “issue” in both, the tool and the copter firmware?!
What version of ArduCopter are you using?
This isn’t an issue with APM Planner, but it maybe with APM code. If it’s not accepting parameter setting for the compasses using setParameter method, that’s going to be a issue. Especially as the old mavlink command can only set one compass, and not compass 2 and compass 3.
[quote=“billbonney”]What version of ArduCopter are you using?
This isn’t an issue with APM Planner, but it maybe with APM code. If it’s not accepting parameter setting for the compasses using setParameter method, that’s going to be a issue.[/quote]
I was using the latest versions of everything at the time (Arducopter 3.2 RC12) and the latest betas of APM Planner and Mission Planner.
Hmm, are you sure? Then what is MAVLinkInterface.sensoroffsetsenum.second_magnetometer for in this line?
if (!MainV2.comPort.SetSensorOffsets(MAVLinkInterface.sensoroffsetsenum.second_magnetometer, (float)ofs[0], (float)ofs[1], (float)ofs[2]))I’m totally sure that the APM should be accepting parameter settings.
See this change (as it shows old and new) and you can see that when it makes the calculation is calls _offset[i].get() which reads the offset from the parameter settings
I just tested this with AC3.1.5 and AC3.2-rc14
Using the MAVLink long command message is not necessary AFAIU.
I’m not saying there is not something not working as expected. The issue of parameters
not saving over reboot can be related to corrupt SD card, so formatting the SD is a good
idea.
All I am saying in that I haven’t been able to find the root cause yet, and i have spent
sometime looking at the AP2 code and the APM code to decipher where the problem
is. It elusive at the moment.
I always take reports of issues seriously, hence why i tested this with both versions of FW
and I cannot reproduce the problem. Any help with replicating the issue is welcome.
Thanks.
Bill