* EKF: centralize range finder tilt check
* Ekf-control: do not double check for terrain estimate validity
isRangeAidSuitable can only return true if the terrain estimate is valid
so there is no need for an additional check
* range_finder_checks: restructure the checks to avoid early returns
There is now only one clear path that can lead to the validity being
true.
Furthermore, if the _rng_hgt_valid is true, we can trust it and we don't
need for additional checks such as tilt.
The case where we need to provide fake measurements because the drone is
on the ground and the range finder data is bad is already handled
in "controlHeightFusion" so there is no need to hack the range finder
checks with that.
* Add Sensor and SensorRangeFinder classes
The purpose is to encapsulate the checks for each sensor in a dedicated
class with the same interface
* SensorRangeFinder: encapsulate in estimator::sensor namespace
* EKF: rename _sensor_rng to _range_sensor
* Range checks: include limits in valid range
* RangeChecks: update comment in the continuity checks
* RangeChecks: move more low-level checks in functions
Also move setTilt out of the terrain estimator, this is anyway protected internally
to not compute cos/sin if the parameter did not change.
* Sensor: remove unused virtual functions
Those are not required yet but can still be added later
* SensorRangeFinder: re-organise member variables
Also rename getRangeToEarth to getCosTilt
* SensorRangeFinder: split setSensorTilt and setCosMaxTilt functions
* SensorRangeFinder: Add a few unit tests
- good data
- tilt exceeded
- max range exceeded
* SensorRangeFinder: set hysteresis in us instead of ms
* SensorRangeFinder: Add more tests
* SensorRangeFinder: update continuity, hysteresis and stuck tests
* SensorRangeFinder: rename variables
* SensorRangeFinder: get rid of "delayed" specification
From the SensorRangeFinder class point of view, it's not relevant to
know if the data is delayed or not
* SensorRangeFinder: move time_last_valid out of stuck check
* SensorRangeFinder: rename file names to sensor_range_finder
* SensorRangeFinder: address Kamil's comments
* SensorRangeFinder: Add more tilt tests
* SensorRangeFinder: store current tilt offset
This is to avoid recomputing cos/sin functions at each loop
-decrease L1 period for tighter mission tracking in fw mode
- increase backtransition duration, we can now do this is we have active
deceleration control
Signed-off-by: RomanBapst <bapstroman@gmail.com>
* fix param import transition for MC_DTERM_CUTOFF
The previous implementation did not work, as there was a check for
param_find_no_notification() returning PARAM_INVALID for IMU_DGYRO_CUTOFF,
and therefore would not call param_modify_on_import().
This moves param_modify_on_import() before the check and makes it modify
the bson node directly.
* parameters: fix param import transition when testing is enabled
BUILD_TESTING is used for unit test builds, PX4_TESTING is used to enable additional test material within PX4
Co-authored-by: Daniel Agar <daniel@agar.ca>
Previously if in a cycle only a disconnected battery status updated, the
battery health state would switch to unhealthy during that time.
Fixes intermittent 'Arming denied! Check battery' preflight failures on
v5x with 1 power module connected.
* Enhancement: State of health, and max_error value is added. Both shows battery health of SMBUS smart battery.
* Enhancement: BAT_C_MULT parameter is introduced. This is for high-current capable SMBUS-based battery.
As SMBUS only provides 16-bit for current, it could only be +-32768mA which is about +-32A.
But with proper treatment, it could be extended with little accuracy loss.
This factor can be set for individual battery system with available information.
* Relative SOC introduced. Proper SMBUS battery should provide percentage of remaining battery
directly. Therefore it does not have to be computed like before.
* State of Health introduced. Proper SMBUS battery should provide SOH value.
* Max error: this shows estimation error of BMS.
* Enhancement: With smart battery, precise estimation of time remaining is provided
with impedance track. It is unit of minute, so 60 seconds multiplied.
Update rate of this is not fast, but very useful.
Co-authored-by: Hyon Lim <lim@uvify.com>
Claudio Micheli