* logger: prevent logpath buffer overflows
The handling of the log path had the potential to cause buffer
overflows, especially on POSIX platforms where the paths are often much
longer than just 64 chars.
* sdlog2: prevent logpath buffer overflows
When the log folder path was created, this was done with the unsafe
sprintf function instead of snprintf. This caused buffer overflows in
SITL but the overflow was usually not detected until recent testing of
some work in progress.
* logger: disable some default topics, which are most likely not used
This is also to safe CPU and lower the amount of file descriptors used.
* logger: use the hrt timer for more accurate scheduling
Under NuttX with the default rate of 285Hz, the actual measured rate was
only 200Hz while on Linux it was ~280Hz. The reason is that NuttX only
uses a usleep() granularity of 1ms, so that the typical sleep time is
longer than what we set.
Now the logger waits on a semaphore, which gets activated periodically
with a hrt timer. With this the measured rate is exactly the expected one,
285Hz.
This adds a new module that does:
- read an parse an ULog file, given via ENV variable 'replay'
- apply all parameters from the log file
- read and apply user-defined override parameters from a file
- publish all messages in 'real-time' from the log file and add a constant
offset to the timestamp to match the system time.
- apply changed parameters in the log (which are not overridden)
Drawbacks of the previous method: when writing to the SD card, there are
high delays in the write() call of several 100ms, every now and then. The
frequency and length of these events depend on:
- SD card
- used logger bandwidth
- bandwidth of gps data (RTCM)
Since the whole gps thread was blocked during this period, it lead to
gps timeouts and lost module.
What we do now is: publish an orb topic with queuing. This makes it async
and the logger takes care of buffering. This means it's best to:
- use high logger rate
- use large logger buffer
- reduce logger bandwith by disabling unused topics
we now use the already existing buffer for logging messages, which is
allocated on the heap.
In fact, stack usage was too high before this, now it's ok again.
Also, it's not clear where the allocation was. It looks like it was on
the heap, but the compiler could decide to put it on the stack. This is
very bad for us because we use fixed size stacks with tights bounds. So if
a user specifies a large topic to log, it could have crashed.
Now the allocation is on the heap and the user can specify any size of
topic to log (as long as there is enough memory).
Instead we use o_name to get the topic name. Now the topic names are not
upper case anymore in the log format. This makes it more consistent, eg.
if used as a nested topic
