The file writer thread could get into a state where it blocked infinitely
on pthread_cond_wait() (or rather until the logging stops).
This is very rare and the following conditions must be met:
- the buffer is almost empty (<4KB filled), so that the writer thread does
not write anything.
- an fsync call is scheduled (happens once every second)
- the fsync call takes a long time (several 100ms), during which time the
complete log buffer fills up.
The main thread would then get into dropout state where it does not call
_writer.notify() anymore.
Notifying the writer thread on every loop update of the main thread fixes
that.
It does not increase resource usage.
This new airspeed module does:
-runns an airspeed validator for every airspeed sensor present, which checks measurement validity and estimates an airspeed scale
-selects another airspeed sensor if for the current one a failure is detected
-estimates airspeed with groundspeed-windspeed if no valid airspeed sensor is present
-outputs airspeed_validated topic
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
The threads running commands for clients through the Posix daemon used
to write to a char buffer through snprintf (etc.) which was then written
directly to the file descriptor, whereas in the other case printf
(etc.) was used to write to stdout (FILE*). Both versions used some
macro's and repeated code to have the same output.
This change unifies these two cases by using a FILE* in both cases. The
(line) buffering is done by the standard C library's implementation
(just like with stdout), and px4_log.c now uses the same code in all
cases (using fprintf, etc.) for printing (colored) output.
- move the update after the integration: a new computed jerk has an impact at the next epoch only
- add jerk reduction in case of too large integration time: when a jerk of "min_jerk" during dt is too much
- add jerk reduction if the integration time is larger than the predicted one and that integrating that jerk would lead to an acceleration overshoot
- rename some variables
- fsync can be a long blocking operation, so we need to make sure the main
logger thread does not block during this time, when it tries to aquire
the mutex
- fixes calling fsync on an invalid file descriptor
Julian Oes