The commander checks use instantaneous values which are vulnerable to false negatives or positives with noisy data or transient faults.
This patch checks the estimators published pre flight check status which is based on persistent checks using filtered data.
This change will force commander into manual reversion mode when an external override device (like PX4IO) overrides the system externally. This is not a functional change on the outputs, as they were in override mode even without this patch. However, this change ensures that the system state is consistent with the output state and also ensures that the pilot and operator has better situational awareness when he / she triggers the manual reversion without realizing it.
arming_state_changed was not set in all places where an arming transition
occurred, for example when calling arm_disarm() from auto-disarm.
We did not notice because the state is published with at least 5 Hz already.
if vmount was enabled in mavlink mode, it was continuously sending mavlink
commmands, which lead to 'command denied during calibration: 205' messages
during calibration.
This fixes (or at least works around) a race condition where the
`status_flags.condition_local_position_valid` is still `false` but the
`status_flags.condition_global_position_valid` is already `true`.
The way to reproduce it is t:
1. Poll home position to check if home is initialized
2. Send arm and takeoff command as soon as home is initialized
Then arming will succeed but takeoff will fail because there is a check
for `status_flags.condition_local_position_valid` in
`main_state_transition()` to enter TAKEOFF.
Change units of parameters from uSec to sec.
Change recommended FW value for COM_POS_FS_GAIN from 2 to 0
Fix error in parameter description for COM_POS_FS_PROB
Fix error in unit for COM_POS_FS_GAIN
This is required because the hardcoded values were too sensitive for fixed wing use and bad initial mag heading could trigger the failsafe and lead to crashes on launch. The defaults have been left unchanged. Suitable values for fixed wing use will need to be implemented in the airframe specific config file.
If the second bit of COM_ARM_MIS_EXT_REQ is set the vehicle
will only arm after receive an authorization.
The authorization flow:
vehicle/external -> command: arm authorization request -> arm authorizer
vehicle <- command ack with result in progress <- arm authorizer
vehicle <- any data request <- arm authorizer
vehicle -> data response -> arm authorizer
vehicle <- command ack authorizing or denying <- arm authorizer
Right now there is 2 ways to start the arm authorization request,
that can be configured by COM_ARM_AUTH parameter.
- One arm: When pilot request the vehicle to arm, it will request
authorization blocking the arm process up to the timeout defined in
COM_ARM_AUTH parameter.
- Two arms request: The first arm request will request the
authorization and will deny the first arm request, if authorizer
approved the request, pilot can arm again within the authorized
time and arm without any block.
The arm authorizer can be running anywhere(compute board or PX4
itself) and it is responsible to request the mission list or any
other information to vehicle before send a final response, it
should send to vehicle a COMMAND_ACK with
result = MAV_RESULT_IN_PROGRESS as soon as it receive the arm
authorization request and the final result
as after it got all the data that it needs authorize or deny the
request.
Instead of having several bools to each requirement to arm, lets group then
in a byte and use bitmask.
This also add a new arm requirement "arm authorization" that
will be implemented in another patch.
This will initialize those structs with zero in all fields not set
and all fields set will only be change once to the final value not
wasting CPU time zeroing it.
This will guarantee that no non-unitialized structs will have
a trash value on from_external causing it to be sent to the
MAVLink channel without need it.
Paul Riseborough