added and using circuit_breaker_enabled_by_val() where possible instead of circuit_breaker_enabled() which search for cbrk parameters by name, which is extensive process.
Condition to enter the prearmed state, an intermediate state between disarmed and armed
* in which non-throttling actuators are active.
*
* @value 0 Disabled
* @value 1 Safety button
* @value 2 Always
* the large 20% margin is no longer appropriate now that nearly all work in the system is
scheduled (moved out of ISRs) and represented in the load percentage
* closes https://github.com/PX4/Firmware/issues/12753
- the last check expects pre_arm to run so we need to enable the
preflight checks. This is closer to the real system.
- as a result we need to enable HIL for other tests so that the sensors
are not checked.
This allows to bypass preflight and prearm checks.
During development there are regular cases where I just want to arm the
board/vehicle no matter what, and the preflight checks are guaranteed to
fail (e.g. sensors uncalibrated, inconsistent, powered via USB, etc.).
Allowing an easy and quick way to arm (assuming you know what you are
doing) helps to speed up development considerably and is less frustrating.
Reason: if you don't want preflight checks, you don't want prearm checks
either (these are the circuit breakers, like usb connected check).
The other changes are cleanup and rework of operations.
In most cases, arming_state_transition is called with fRunPreArmChecks set
to true, so no change in behavior.
The cases with fRunPreArmChecks=false are:
- unit tests
- in_arming_grace_period=true (quick arming after disarm)
- VEHICLE_CMD_PREFLIGHT_CALIBRATION (does not transition to armed)
The int32 param COM_ARM_AUTH is mapped to a packed struct. However, this
struct was not actually packed (anymore) and therefore the values were
applied incorrectly.
I fixed this by applying the packed attribute. By using a union with a
int32_t I could rid of the warning about address-of-packed-member.
* This fix is necessary because usually uORB structs get initialized with
all zeros and then get filled with the fields that are actually in use.
* The number 0 for the mode slot was already commanding to switch to the
mode in slot one even though for example the joystick input via mavlink
does not use this mechanism at all.
This fixes the terrifying case where the drone disarms in-air just
because it receives a MAVLink disarm command. We now check param2 for a
magic number which enforces arming/disarming.
This is added to the mavlink protocol in:
https://github.com/mavlink/mavlink/pull/1162
It doesn't affect fixed wing flying anymore. I disabled it for the
deltaquad since I presume @sanderux prefers to have the feature disabled
even when flying in multicopter mode.
AAs discussed in the devcall this functionality is only useful for
rotary-wing (multicopter) flying since it's a big safety hazard to
accidentally bring a fixed wing out of an auto mode e.g. a mission
and fly away in a straight line or into an obstacle.
