When the timer callback is called at a higher rate than the logger can
execute the main loop (which is never the case under normal conditions),
the semaphore counter will increase unbounded, and eventually lead to
an assertion failure in NuttX.
The maximum semaphore counter is 0x7FFF, and when the logger runs at
default rate (3.5ms), the logger task must be blocked for 0x7FFF*3.5/1000
= 114 seconds continuously for an overflow to happen.
I see 2 cases where that could happen:
- the logger execution blocks somehow, or busy-loops in an inner loop
- a higher-prio task runs busy and hogs the CPU over a long period of time
_should_stop_file_log is set after disarming: logging continues for 1s
to measure the CPU usage.
During that time, other modules might change params (such as ekf), and
we don't need to have these the log. However currently all modules do
not notify the system when setting params after disarming.
Meaning this patch is not strictly needed, it's more a preventive
measure.
If logger is started very early, orb_exists() will fail for a lot of
topics, they will be advertised within the next few seconds.
Logger already dynamically adds subscriptions during logging, but if we
do that before as well, we'll avoid any delays and having to subscribe
to a lot of topics all at once.
To keep track of the configured interval, we store it as negative file
descriptor, until we do the subscription.
This frees up a considerable amount of file descriptors in most use-cases.
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.
Beat Küng