Copter-3.5.5 has just been released and should now appear as the default firmware in Mission Planner and other ground stations. This is a relatively minor release (ReleaseNotes):
ICM20948 compass orientation fix (important for users of new HEX GPS/Compass modules)
LIS3MDL compass support on Pixracer
support for easy embedding of defaults in firmware binary
do-mount-control control command sets copter yaw when using 2-axis gimbal
TradHeli fix for direct drive variable pitch tail rotors
The first item is the one users of quite recently produced HEX GPS compass/modules need to be careful about. These new GPS/compass modules use the ICM20948 compass (instead of the older Honeywell compass).
In short if you were using one of these new GPS/Compass modules with Copter-3.5.4 and found you had to set the COMPASS_ORIENT parameter to “26” (aka “Pitch180Yaw90”) to make it work then after you upgrade to this release (Copter-3.5.5) you will need to set that parameter back to “0” (aka “Rotation None”) and re-do the compass calibration.
If you want to dig into this issue in more detail, you can check if you have the new GPS/Compass module by doing the following:
if you bought your HEX GPS/Compass module more than 3 months ago, it uses the Honewell compass so no need to worry!
if the box has HX4-06021-xxx or HX4-06022-xxx then it is the new module.
if the COMPASS_DEVID1 is “723977” OR “723969” then it’s the new module. if it’s something else, then no need to worry!
If you have the new module, it is best to check the COMPASS_ORIENT parameter:
if using Copter-3.5.5 (or higher) or Rover-3.2.0 (or higher) then the COMPASS_ORIENT parameter should be left as zero
if using Copter-3.5.4 (or older) or Plane-3.8.4 (or older) then the COMPASS_ORIENT parameter should be “26” (aka “Pitch180Yaw90”).
After changing the parameter you do a compass calibration and reboot the board.
I have a HEX GPS module with Part number HX4-06003 but the COMPASS_DEVID is 723977. So are there other part numbers with the new compass then? I just received this module a week or so ago.
This is a surprise to me. One of the guys at HEX told me the the boxes should be marked as I’ve shown in the picture if they have the new compass in them. I’ll ping them and perhaps they can respond directly. Sorry to pass the buck…
Thanks guys. These are the compass ID’s on a PIxracer (primary GPS of course) with the HEX compass of the product code I mentioned. So I’m wondering which mag chips are being found.
For those interested in decoding these numbers for themselves, above is the output of the Tools/scripts/decode_devid.py script using a command like this, “decode_devid.py -C xxxx” where the last xxxx should be the device id found in the parameter list.
We hope to make this easier in the future by adding all the possible compass ids to the parameter description info so it will either appear in a drop-down if using the MP’s standard parameter list or people can look it up in the description to the right of the number.
This is Eric from Hex Technology. I am very sorry about the wrong S/N on the product. Could you contact me through the email eric.xie@hex.aero and take a photo for the S/N on the package for me. Thank you.
Thanks Randy great info and very handy script. So compass 1 is on the HEX module and 2 & 3 are in the Pixracer. Is there any way to enable the 2nd LIS3MDL compass on the module or is only 1 available on the I2C bus?
Yes, it should be possible to enable the other external compass although ArduPilot only ever uses a single compass at a time. The others are only used in case the first one fails for some reason. In any case, the issue is that we only support up to 3 compasses, so to get the LIS3MDL to appear one of the others must be disabled. That can be done by changing the COMPASS_TYPEMASK parameter… for example the SK8963 can be disabled by setting COMPASS_TYPEMASK to “2”
I think that means that your HEX GPS/compass is using the older Honeywell compass (HMC5883) so I think you will have no problems. You can confirm by checking the COMPASS_DEV_ID parameter … i think the honeywell device id will probably start with a “46” but you can paste it here and I can check it for you if you like.
By the way, my understanding is that the older Honeywell compass is at least as good as the new ICM20948 compass. I am pretty sure all the flight controller manufacturers would have stuck with the Honeywell if Honeywell hadn’t strangely decided to discontinue it.
I’m not following the value of “2” to disable the SK8963 in the typemask. If I convert the binary value of the 13 drivers (incl SITL as 13) with SK8963 for exclusion I come up with bin(100) or dec(4). I setup a simple Excel calculator to produce the mask value maybe I did something wrong.
And it doesn’t seem to matter what compass configuration parameters I try the same 3 compass device ID’s are found. Even if I disable all the drivers except ICM20948 and LIS3MDL (typemask 16095). It does stop the internal ones from registering during compass calibration but the device ID’s remain and the LIS3MDL is not found.
Edit-Apparently the newer Here GNSS modules do not have a LIS3MDL 2nd compass only the ICM20948.
I’ve been flying 3.5 with a Here unit that is affected. I changed my strange compass orientation to Yaw 180 (it’s on the helicopter backwards), and it is working fine.
