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.
If 2 or more vehicle_command are queued a call to update() will
return the oldest vehicle_command and set the _cmd_time to the
timestamp of the last vehicle_command queued losing it.
Using update_if_changed() fix this causing all item being consumed
one at each call of send().
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.
Test HW has R and G LED swapped and drives the UI LED's active
high. The changes support all the configuratons of FMUv5 on
RC00 and RC01 HW for PWM status and UI LEDs.
Added palarity mask to support active low drive on per channel
bassis.
Added open drain drive type when the enables are active low to
ensure the LED are off when supplied form 5 volts.
For active Push Pull is used. Active low drive is recomended.
Added support for test HW that had the R and G LED signals
swapped.
Board builds may now inclulde both the PWM and I2C RGB LED
To add the PWM RGB LED driver:The board must define
BOARD_HAS_LED_PWM and include rgbled_pwm the moulde list.
This change attempts to start the either rgbled driver, that
may or may not be present. If it is not present the +e
setting allows the start up to continue.
Board builds may now inclulde both the PWM and I2C RGB LED
To add the PWM RGB LED driver:The board must define
BOARD_HAS_LED_PWM and include rgbled_pwm the moulde list.
This change attempts to start the PWM rgbled driver, that
may or may not be present. If it is not present the +e
setting allows the start up to continue.
Paul Riseborough
Daniel Agar
Sugnan Prabhu S
jgs2185
Julien Lecoeur
sanderux
José Roberto de Souza
acfloria
CarlOlsson
David Sidrane