It makes more sense to set the optimization flags on a platform basis
instead of individually for each module. This allows for different
optimization options for SITL, NuttX, Snapdragon, etc.
add missing break
uorb topics generator: add multi-topics to the list of all topics
topic names with '# TOPICS <name>' were previously not in orb_get_topics().
This means the logger could not find them.
Affects for example actuator_controls_0.
px_generate_uorb_topic_files.py: add multitopics to generate_topics_list_file_from_files method
switch simulated attitude to new topic: vehicle_attitude_groundtruth
logger: add input_rc topic. needed for web plotting
input_rc.msg: remove timestamp_publication, use timestamp instead
mixer.cpp: warnx -> PX4_ERR
logger: initialize timer_call to 0 (hrt_call_every reads some fields)
position_setpoint_triplet topic: set the timestamp when publishing
px_generate_uorb_topic_files.py: add multitopics to generate_topics_list_file_from_files method
add vehicle_attitude_groundtruth to default topics
change to hil_state_quaternion
- ulog file message rate limited to 50Hz
- queuing with size 2
- this replaces the mavlink log message in the ulog
(but the mavlink warnings & errors still go to the ulog)
* 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
