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.
I’ve done 20 more flights and all seems good for me.
1 Like
Keith,
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.
This problem has been going on for a while, not exactly related to 3.5.5, but maybe it should finally get addressed because of the severity.
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.
Sorry it’s not setting to max value. If I widen the column, it’s showing E-06.
i just had battery failsafe kick in when FS_BATT_ENABLE = 0. MAH triggered it, not voltage
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.
Keith,
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.
Thanks again for testing and reporting issues!
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.)
I’ve had that problem since an MP beta push on Friday I believe. I made a post here and Michael has responded, but not fixed yet.
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.
Chris,
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.
-Randy
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).
Can Mission Planner detect if this compass is being used? Maybe MP’s Service Bulletin feature would be appropriate.
The compass calibration succeeds with relaxed using all 3 compasses with 3.5.4, and “inconsistent compass” only shows if you move the frame. I attempted a flight with 3.5.4. I had no warnings until liftoff and still it flew well in stabilize. When I switched to position hold, then it got fun and bounced it off the ground before a very rough landing. I also wasted 2 days disassembling and repositioning components trying to get rid of the error before I gave up and came here.
The clarify a bit, the “inconsistent compass” message shows up when two (or more) compasses are pointing in different directions (90 degrees off in 3 dimensions or 60 degrees off in the horizontal plane) or of different lengths (200 milligause which is about 30% different) so it doesn’t necessarily require moving the vehicle. Metal on the ground or perhaps in the frame could affect the field which might push it over the limit which might explain why sometimes moving it makes a difference.
https://github.com/ArduPilot/ardupilot/blob/master/libraries/AP_Compass/AP_Compass.h#L32
A service bulletin is a good idea.
I think the inconsistent compass error will appear if the internal compasses are enabled. If they’re not enabled you should see the vehicle is pointing in the wrong direction although people often may not check this.
I tested it quickly by doing an upgrade from 3.5.4 to 3.5.5 without the internal compasses enabled. No inconsistent compass message, but the heading was off. So that answers that question. If a person was flying without the ground station, he/she wouldn’t know it.
You’re right, it did show momentarily without moving. It popped up for about 3 seconds and disappeared for a descent amount of time with a white EKF. So most of the time you look at the hud, everything appears normal.