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.
px4_shutdown_request() was called from the power button IRQ callback, which
invoked a work queue callback. But on NuttX, the work queue uses a
semaphore, and thus it cannot be called from IRQ context.
This patch switches to publishing an uORB msg instead, which is handled in
the commander main thread.
To increase failure resistance, we could subscribe to the same topic in
another module for redundancy, in case commander runs wild.
Sugnan Prabhu