The current practice of adding topics to the default set isn't scalable,
as it affects all setups.
By making sure topics are advertised on init, logger can just discard
topics that don't exist. This does not work for all topics, so topics are
specifically marked as optional. It can be extended to more topics later
on though.
This reduces the list of topics by ~35 on a pixracer configured as quad,
and reduces RAM usage by ~1KB.
The situation where this would be desired is unclear, plus it's basically
the same as setting ASPD_SC_P_NOISE to a very small value.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
Do no longer use tas_innovation from wind estimator and test ratio, but calculate
the innovation based on wind estimate, TAS measurement (including currently applied scale)
and ground velocity. Use innovations directly to trigger failure.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
- run airspeed scale estimation always, not in dedicated mode
- add option to apply scale automatically, with extra feasibility check
- add airspeed scale for all 3 possible airspeed instances
- clean up parameters
- add check for data stuck (non-changing airspeed data)
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
* fix disable airspeed check with negative ASPD_FS_INTEG
* improve logic when nav velocity data is not good
* simplify logic. Reset integrator state when the check is not run.
Stall speed check would otherwise trigger during landing if airspeed falls below
stall speed before landing is detected.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
- publish wind estimate only from EKF, and wind speeds from airspeed selector to new separate topic (airspeed_wind)
- rename message wind_estimate to wind
- publish wind from currently used ekf instance (ekf2selector)
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
That enables the sensor checks by default
The default for the innovation check integral of 5 is rather conservative, thus
makeing it less likely to be triggered by accidnet (e.g. due to bad wind estimate).
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
- parameter updates can be quite expensive because they trigger nearly all modules to reload all of their parameters immediately
- limit modules from updating faster than once per second
- ekf2 can now run in multi-instance mode (currently up to 9 instances)
- in multi mode all estimates are published to alternate topics (eg estimator_attitude instead of vehicle_attitude)
- new ekf2 selector runs in multi-instance mode to monitor and compare all instances, selecting a primary (eg N x estimator_attitude => vehicle_attitude)
- sensors module accel & gyro inconsistency checks are now relative to the mean of all instances, rather than the current primary (when active ekf2 selector is responsible for choosing primary accel & gyro)
- existing consumers of estimator_status must check estimator_selector_status to select current primary instance status
- ekf2 single instance mode is still fully supported and the default
Co-authored-by: Paul Riseborough <gncsolns@gmail.com>
This is to prevent a wrong (false positive) failure detection of the airspeed
shortly after system boot due to delays in driver and/or estimator startup (seen in SITL).
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
Jukka Laitinen