Before this patch is applied we may never send the second message
because there's not room for it in the buffer and we can't return
failure-to-send (always interpreted as "retry") as we're in a void function.
Further, if you are on a mavlink2 connection we will not send out the
RC_CHANNELS_RAW message, depriving the user of any RC_CHANNELS messages.
This patch does have the drawback of doing more work on a mavlink1
connection - it has to fetch the data twice. On the other hand, it also
allows the GCS to set the message rates independently for both
RC_CHANNELS and RC_CHANNELS_RAW so one or the other can be squelched.
That could be handy for reducing bandwidth if you know you're not using
more than 8 input channels.
this forces the EKF origin to the GPS alt on a height datum reset if
we have GPS lock. If we don't do this then the reported AMSL alt will
drift over time away from the GPS alt when we reset while on the
ground
this forces the EKF origin to the GPS alt on a height datum reset if
we have GPS lock. If we don't do this then the reported AMSL alt will
drift over time away from the GPS alt when we reset while on the
ground
this zeros the delta angle and delta velocity accumulators when a
sensor is unavailable for a period of 0.1s. This prevents garbage
values being passed into the EKF when a sensor dies and then becomes
available again some time later
this we ensures we get new data for all active IMUs on each loop,
rather than sometimes returning with some IMUs not having data.
This matters as not having a sample on an IMU for a single loop can
cause an EKF IMU failover, which will degrade the learned bias
variances
The issue is usually only seen under high load, such as requesting a
loop rate beyond what the hardware is capable of