Failsafe behaviour

I’m losing faith in the failsafe behaviour of Pixhawk at 3.1 I hope it is being addressed in 3.2.

On three occasions now my Pixhawk has ‘disobeyed’ my explicit disable of failsafes.

On one occasion it triggered a battery failsafe and cut the motors to zero - not acceptable on something that flies. On two other occasions it fired a GPS Failsafe and went into LAND mode - which set the motors to MIN rpm - this is also a concern - min rpm may be OK in an aircraft but in a quad / hex or octo copter it most certainly is not.

This however is despite ALL my failsafes being disabled.

This behaviour ignoring explicit disables is NOT acceptable, disabled should be exactly that and should not be circumvented or bypassed - period. An explicit disable must ‘ignore’ any values configured in minimum and maximum failsafe configurations values.

The failsafe triggers have been verified in the logs so I know that they occurred.

I hope this is being addressed in 3.2.

Hi,
Without your logs showing this, this message is pure rant and there is no way to insure that it won’t happen in 3.2 as we do not know what happened on your copter in 3.1.
M

I object to the rant term - I do this on real time systems for a living.

Log attached. You will see the failsafes in this log - my fail safes are DISABLED !!!

Sorry for the rant term, I see too many people exposing issues without logs which makes it very hard to investigate properly.

Something is wrong in mission planner then. check again, because it is there.
FS_GPS_ENABLE = 3 in your logs
copter.ardupilot.com/wiki/arduco … GPS_ENABLE
3 Land even from Stabilize

Hmm Mission planner V1.3.9 says disable ??? - how can I confirm what it is sending / setting ??

And how can I set a lower rate of descent than minimum RPM … which is way too fast

can you send a screenshot of what you see in MP ?

The acceleration on the z axis is not contained in 3.1. There has been a bit of work on this on 3.2.
The current max speed on landing is 30cm/s which the logs shows it seems to have applied but with a big acceleration.

You should take off with gps hdop and sats number to acceptable level. It was not the case here, it picked up sats at the end of the flight then dropped it and the failsafe kicked in.

Here is a screen shot APM Planner 2.0

I can assure you that I have changed nothing - all show disabled. I don’t care what the numbers are - disabled should be disabled not ‘maybe disabled depending on’ … which attribute in the log indicates the current mode ?? - fortunately this was ‘bench testing’ and it wasn’t in the air - the failsafe took me by surprise since I thought I had them disabled.

Even 30cm/s is way too fast and will cause damage to a copter.

30cm/s or 1m in 3.3 s is not that fast IMHO.
The problem you had was fast it accelerated to that speed quickly. should be better in 3.2

Try Mission Planner to see what it shows you.
Anyway you can go in the parameter list to solve that easily.

This is a APM Planner issue, not a copter issue.

Here’s a puzzle then … this is from mission planner … taken following a ‘refresh’ of parameters.

Just how can I confirm what the Mission Planner or APM planner are telling me - obviously we need to have some confidence in one or other of these tools - or a means to verify.

That’s weird.
Make a new small log to see what is the dataflash log telling you for the parameter value.

Will do so willingly - how do I achieve this - just arm the copter ? or do I need some setting some place ?

you do not even need to arm, I believe.
just plug the battery and push the safety switch (I believe that is necessary)
push again the safety switch to deactivate and unplug battery.

You should have a new log

Sorry about the date - looks very odd.

looks fine now
FS_GPS_ENABLE is 0 on this log
recheck the log 21.bin and it was definitely 3

Yup log 21 clearly shows it as 3. I had an issue with the battery failsafe triggering because I had a positive value in battery voltage too - that’s why it is zero currently.

I’ve noticed in APM Planner that the fields aren’t always correct unless you go and do a parameter refresh, I’m not sure which out of the two applications to trust now.

I can assure you that I did set these values to disable since I am testing and verifying optimum numbers to put into the failsafes, I’d rather sacrifice a battery that an entire copter, I don’t tolerate ESC’s that shut down on overheat - get me down then catch fire for all I care. I can’t rely on getting more than 8 satellites where I live, I’ve had as many as 10 but 8 seems the norm so working ourt the average HDOP here, it looks like RTL would be very high risk where I live - just not accurate enough with a ground position varying by 3 or 4 metres - thats the difference between on the grass and in the trees. I am also stress testing batteries to identify the most appropriate ‘cut off’ point but as I said I prefer a warning only in this case. I also use a Taranis and X8R and am experimenting on ways to ‘reliably’ detect TX loss without using the mode channel (5). My biggest concern is prevention of flyaway, I’ll run a motor / ESC or battery to destruction if it gets me on the ground in a controlled and safe manner, I really don’t want any ‘unauthorised’ failsafes triggering.

I’m going to leave things set as they are now and see if one or more trigger again, I’ll post the log if they do.

On the 3.2 descent issue I think much depends at what altitude you are - bit like dead mans curve on a helicopter - autorotate from 200 feet is fine but from 30 feet it’s gonna hurt, throttle minimum on a helicopter with collective and winged aircraft is fine, on a fixed pitch multirotor that depends entirely on propeller speed for flight control it is not, be interesting to see how 3.2 handles things, what about some internal trigger to ‘activate’ failsafe operation - i.e. minimum altitude gain post arming (proof of flight).

[quote=“Ben Kenobi”]Yup log 21 clearly shows it as 3. I had an issue with the battery failsafe triggering because I had a positive value in battery voltage too - that’s why it is zero currently.

I’ve noticed in APM Planner that the fields aren’t always correct unless you go and do a parameter refresh, I’m not sure which out of the two applications to trust now.

I can assure you that I did set these values to disable since I am testing and verifying optimum numbers to put into the failsafes, I’d rather sacrifice a battery that an entire copter, I don’t tolerate ESC’s that shut down on overheat - get me down then catch fire for all I care. I can’t rely on getting more than 8 satellites where I live, I’ve had as many as 10 but 8 seems the norm so working ourt the average HDOP here, it looks like RTL would be very high risk where I live - just not accurate enough with a ground position varying by 3 or 4 metres - thats the difference between on the grass and in the trees. I am also stress testing batteries to identify the most appropriate ‘cut off’ point but as I said I prefer a warning only in this case. I also use a Taranis and X8R and am experimenting on ways to ‘reliably’ detect TX loss without using the mode channel (5). My biggest concern is prevention of flyaway, I’ll run a motor / ESC or battery to destruction if it gets me on the ground in a controlled and safe manner, I really don’t want any ‘unauthorised’ failsafes triggering.

I’m going to leave things set as they are now and see if one or more trigger again, I’ll post the log if they do.

On the 3.2 descent issue I think much depends at what altitude you are - bit like dead mans curve on a helicopter - autorotate from 200 feet is fine but from 30 feet it’s gonna hurt, throttle minimum on a helicopter with collective and winged aircraft is fine, on a fixed pitch multirotor that depends entirely on propeller speed for flight control it is not, be interesting to see how 3.2 handles things, what about some internal trigger to ‘activate’ failsafe operation - i.e. minimum altitude gain post arming (proof of flight).[/quote]
Un mission planner, you have to click ‘write’ and modified field changes from green to normal.
I hope it will be fine for you.

Appreciated, I always do that, I’m starting to prefer Mission Planner over APM Planner, the parameter tree is a really nice touch. Can’t do any more testing until later tomorrow but I’ll be back at it and will report back any perceived issues.

I’d like to think that at some point I’ll be able to make a useful contribution to this community - since I design real time systems / fly by wire / instrumentation as a day job - which is why I prefer the PM4 / Pixhawk over ‘closed’ and off the shelf stuff - coz I can play :wink: .