with multiple airspeed sensors and airspeed affinity in EKF3,
it is possible to have switched over to a lane not using the
primary airspeed sensor, so AHRS should know which airspeed
sensor to use, i.e, the one being used by the primary lane.
this allows the EKF core index to be used to select a GPS/baro/mag
instance. This is an alternative to GPS blending that allows EKF lane
switching to be used to select the right combination of GPS and IMU
add logging to XKFS message
TODO : Port lane switching logic from EKF3 to make use of these terms
Since both share the same NKF3 log structure, needed to do this.
Just log 0 as of.
`strndupa` is only available when using the GNU GCC suite.
With this definition is possible to use the MUSL compiler.
Signed-off-by: Patrick José Pereira <patrickelectric@gmail.com>
musl implements `sched_*` following the posix standard,
where `sched_setschedule` is used for process scheduling.
Linux implementation defines `sched_*` functions based in
the thread scheduler and not with the process.
Using `pthread_*` should be used to follow such standard.
Ref: https://pubs.opengroup.org/onlinepubs/9699919799/
From: https://www.openwall.com/lists/musl/2016/03/01/5
> ... Linux does not provide a way
> to set scheduling parameters for a _process_, only for threads. The
> sched_setscheduler syscall is documented as taking a pid but actually
> takes a thread id and only operates on that thread. glibc just ignores
> this and provides sched_* functions that do the wrong thing.
This can be fixed by using `pthread_setschedparam` and requesting the current
thread id via `pthread_self`.
Signed-off-by: Patrick José Pereira <patrickelectric@gmail.com>
this will allow a fixed wing to fall back to DCM if the EKF stops
providing an absolute position while we have 3D GPS lock. The
using_gps flag is not enough, as lagged GPS data can lead to the EKF
stopping fusing when the data is behind the fusion time horizon. In
that case EKF3 gives using_gps=1 but sets horiz_pos_abs=0
this detects GPS data lag, and if 5 samples in a row are lagged by
more than 50ms beyond the expected lag for the GPS then we declare the
GPS as unhealthy.
This is useful to detect users who have asked for more data from the
GPS then it can send at the baudrate that is being used. The case that
led to this path was a F9 GPS with GPS_RAW_DATA=1 at 115200 baud. In
that case the UART data is quickly lagged by over 1s
