In the normal sitl `commander takeoff` case, the takeoff jump was never
actually carried out because the default altitude radius is set to 3m
and the takeoff altitude to ~2m which means that the takeoff waypoint is
"reached" immediately.
This works around this edge case by using the altitude between the home
altitude and takeoff altitude divided by 2 as a acceptance radius.
Since orb_copy is guarded with a orb_check, we ended up not having the
corrent landed state in the beginning which could lead to some
unexpected behaviour on takeoff.
In most cases, _extern_address was unused, thus wasting cycles & RAM. This
adds a separate class BlockParamExt with the field and uses it in ekf2_main
Frees roughly 0.5KB of RAM on Pixracer
The lifetime of the string is guaranteed because we never delete
DeviceNode objects and the strings in question are already on the heap.
This frees roughly 2.2KB of RAM on Pixracer
reorder & reduce instance to uint8_t (which is more than enough).
Reduces sizeof(MavlinkOrbSubscription) from 40 to 24.
On Pixracer this frees almost 2KB of RAM
The limits the maximum queue size to 255, which I think is ok for the
forseable future.
sizeof(uORB::DeviceNode) is reduces from 128 to 112 on NuttX, and with
~80 instances, this saves over 1KB of RAM.
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.
This limits the maximum bandwidth of ulog streaming to 70% of the specified
mavlink datarate. If less is used, the leftover is assigned to the mavlink
streams, if more is used, it starts to drop.
mavlink status outputs the currently used rate, to check if a link is
saturated.
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.
The packet_count was actually an error_count, therefore we should
process RC input only when the error_count since the last packet is 0.
Also, this commit fixes the RSSI scaling for st24.
Julian Oes