Instead use a single timestamp for subscription checks. This frees up
~800B of RAM.
Also make sure the subscription checks are distributed over time. On each
update, at most 1 topic subscription is checked. Reduces the load of the
logger from 7.3% to 5.8% (Pixracer)
ulog_message_info_header_s *msg = reinterpret_cast<ulog_message_info_header_s *>(buffer);
members of msg could end up unaligned, because of the uint8_t buffer.
tested on Pixracer: 14 still produces some dropouts once in a while, but I
think it's a fair tradefoff between RAM usage & dropouts. The queue needs
about 3.5KB of RAM.
When topic sizes/logging rates change, this will have to be reevaluated.
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.
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).
