If you still have one plugged in then you can enable/disable it with the switch
Aircraft disarming in sky due to hardware failure
Add new parameter?
MdB: You will be making a decent amount of changes in the PX4 IO firmware btw for this
[10:03 AM] (Channel) MdB: the button is connected to io firmware
[10:03 AM] To Weekly devcall: Maybe do it after the ChibiOS IO firmware is ready?
[10:04 AM] (Channel) MdB: peter and I had discussed at the unconf a version of the switch that is inverted state as well (as far as arming checks are concerned)
Relying on heuristics for your safety button is problematic
“Single use” button
Once active you can’t deactivate
MdB: it breaks a lot for what I do…
[10:06 AM] (Channel) MdB: Does not survive my flight regime
Base things on armed/disarmed?
Have to disarm before toggling button
Removes ability to disarm crashed aircraft
Safety switch should work regardless of other external inputs to vehicle
MdB: the inadvertent one breaks the other one at the moment
MdB: we can’t get is flying to that level
Rule: safety button should be predictable… not heuristics
MdB: IO firmware also has no clue what is_flying really is…
More values for enum
An option to not take vehicle to safe state when vehicle is armed
It’s scary how easy it is to get a false positive on these safety switches
No such thing as a “good enough switch”
Really smart safety switches from industry?
TP: Once, I had a bird attack my Skywalker X8 and PRESS THE DAMN POWER SWITCH off
Floating input?
It is pulled up
But how much pinning is enough?
Is it dangerous as is?
Pull it to 3.3V if you want to!
MdB: the disable parameter should just mean we ignore the pin, but we don’t
Couple of changes
BRD_SAFETY_ENABLE set to 0 should mean disabled entirely
Another enum value which says it can’t move to outputs disabled when armed
MdB: GCS’s can also actuate the button. That should probably be brought forward on the GCS side
MdB: Can we have another enum to invert the arming check
Can only arm when safety enabled
Would need to poll the switch
Could actually use a non-momentary switch instead of a button!
Do we change the existing behaviour of value 0
Or add another parameter?
This was just a lazy way of getting the behaviour
Answer: yes
We can add existing behaviour as a new enum value
How about fmuv4?
Not a hardware safety switch in that there’s no IO board