Copter-3.5.5-rc1 is available for beta testing. This is a relatively minor change compared with 3.5.4 (Release Notes)
ICM20948 compass orientation fix
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 most critical fix is perhaps the first item which is important for the latest Hex GPS/Compass modules that use the new compass. You can determine if you have one of these new modules by looking for “HX4-06022” or “HX4-06021” on the box. If you were using these modules with Copter-3.5.4 you would have needed to set COMPASS_ORIENT to “26” (aka “Pitch180Yaw90”) but with this release, Copter-3.5.5-rc1, COMPASS_ORIENT should be set to “0”.
Any testing you can do would be greatly appreciated, thanks!
This came out perfect time. Just finished a new build and these HERE gps are using the new modules. Just completed a first flight with autotune with no issues.
Just did an automission and this never happened with 3.5.4. The EKF2 IMU1 constantly switched compasses to 1 and immediately back to 0. First image is zoomed out, second is zoomed in to see the messages.
Keith,
Do you have a binary log I could have a look at? It’s most likely that the compass orientation is incorrect but I can’t say if that’s a configuration issue or a code issue.
Keith,
Ok, thanks. I’ve just received my new Hex GPS and I’ve tested it and it seems OK so that adds some support to the idea that it’s not related to 3.5.5. txs again for testing.
Thank you very much for testing and providing feedback!
I suspect we will release this as the official default Copter firmware next week some time - maybe Wednesday or Thursday assuming nothing comes up.
The resulting flight was not pretty and resulted in a crash.
Basically, you enter values into MP and for some reason the Pixhawk records maximum possible values instead. Disconnecting and reconnecting Pixhawk or using Refresh Params does not reveal the erroneous values (instead, it always shows the values you entered.) The only way I’ve found to see the erroneous values is to use the Compare Param feature.
A quick look shows you might have a 4 cell battery, and over the flight it goes down to about 13.3volts = 3.3 volts per cell.
There’s about 6400 mAh’s used assuming your current calibration is close to correct.
I cant see where it’s voltage or capacity fail, the log just says “FS:Battery Detected” for me., so i assume it’s voltage.
You might want to increase the failsafe voltage a little to give more time to land - just my amateur/newbie opinion.
I’m unable to open the .bin file in MP (issue raised here) so this makes my analysis a bit difficult but the battery failsafe didn’t take any action - the vehicle didn’t change mode. It’s perhaps a little odd, but the “low battery” message will be displayed in the groundstation’s HUD and an ERR will appear in the dataflash logs regardless of whether the “FS_BATT_ENABLE” parameter is zero or not. The parameter only affects whether action is then taken (i.e. a mode change).
I think the logging of the error message at least is a bit weird so I’ve created an issue here.
It entered RTL flight mode all on its own (edit: rather the GCS stated RTL mode and continued to repeat “battery failsafe”). Look at the altitude climb and descent near the end. (I haven’t been able to view the log myself yet because of the bug mackay pointed out.)
Keith,
There was a transmitter/receiver/RC failsafe in the log. I suspect that was what caused the RTL…
A the risk of being nitpicky… the GCS almost never sends flight mode change requests, certainly it’s not responsible for failsafes. In general the only time the GCSs request flight mode changes is when the user requests “Follow-me”, “Fly to Here” or specifically hits one of the set-mode buttons (i.e. on the MP’s action tab).
@rmackay9 what happens if a user upgrades without knowing this? Will the ground station pop up a warning that the compass orientation is now invalid? Or will it be 90 degrees off and the mag x, y, z values reversed, with no warnings? Or does the firmware upgrade automatically detect the ICM20948 chip and set it to zero?
On helicopters I’ve installed these units with a Roll 180 Yaw 270 because the HERE GPS is mounted on the heli backwards usually for best cable routing. I have not had a chance to test this yet myself, just wondering what to look for.
There’s no warning I’m afraid beyond the regular “inconsistent compass” message in the pre-arm checks. I think the hope was that we get this change out there quickly enough that most users won’t have tried to use the new Here GPSs yet.
I will have to test this to see what happens. I have a Chinese made unit here, as well, with that same mag chip. That one is installed in the unit in a Yaw 45 orientation. And I have a brand new Here unit, also, for my turbine helicopter with the HX4-06022 tag on the box that should be plug-n-play with 3.5.5.
I would think users would note that the compass direction is off if the internal compasses aren’t being used. It’s kind of an interesting problem but I want to find out if a user upgrades without knowing this if the system will spit out a compass error (or not).
