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.
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.
Test flights reported the warning `[load_mon] log_writer_file low on stack! (292 bytes left)`
Increase stack size from 1060 to 1072 (=8 + 1060 rounded to next multiple of 8).
This requires support in the parsers, and thus the ULog file version is
increased.
As long as no data is appended, both, existing pyulog & FlightPlot, can
still read the new logs (they will output a warning).
The replay module will print an error, but still continue.
This enables to use the RAM normally consumed by the log buffer to be used for calibration and other memory-intense tasks.
These run typically only disarmed when logging is not enabled.
This will avoid file system corruptions in cases where px4_shutdown_request
is used. However it will not help obviously when the battery is pulled
directly.
For the process usage: we need to measure over a certain period of time,
then we can use the results. To avoid blocking, this does:
- after log is started, initialze the load counters, then one second later
add the results to the log
- after disarming: continue logging for one more second, then add the process
load to the log and stop logging.
- to avoid a delay, 'logger stop' will stop immediately and not log
postflight process usage.
Just to make sure that it will never be used on NuttX. This is not an
architectural limitation, just a memory optimization, since we call
clearenv() on NuttX.
Daniel Agar