ekf2: Consolidate range finder checking #9886
Conversation
|
@mcsauder and I can help test this one with our range finder. |
|
@priseborough ECL is merged and I think it makes sense to consolidate with #9865. |
I'd obviously also welcome if this could be incorprated in some way. @priseborough I modified #9865 according to your feedback, so If you want to directly incorprate it feel free. Otherwise I'd adapt #9865 later, although it would be more efficient to merge both together now .... |
|
We just loaded this along with the new ecl onto our quad and had a successful test flight. We will do more testing here shortly. https://review.px4.io/plot_app?log=8adafb31-7498-4900-9daa-1ebdd8715832 |
|
@priseborough We have recently been doing a lot of work in our distance sensor driver, mostly the limit the amount of bad data we publish. It appears that the estimator continues to fuse the last range finder data point. Notice the last distance value published is at about 0.5m @ t=2:06s and the next point that comes in is at 2m @ t = 2:15s. The behavior we saw was the quad just keeps ascending because it thinks it is still at 0.5m. This is with range aid enabled. |
|
I've created a patch priseborough@3e0d1df which effectively pulls this PR into #9865. Once that is merged i will submit PR's to fix #9861 and move the quality == 0 check to inside the ecl library. |
|
Just saw the same behavior as @dakejahl on a separate piece of hardware. https://review.px4.io/plot_app?log=861edb66-663c-46b2-8a60-d1935a7290b6
|
|
@priseborough Also I should ask, is simply not publishing the best way to go for a driver that has detected it has bad data? I agree with the conversation in #9865 that data validity checking should be done inside of the driver for the device. |
|
@dakejahl and @AlexKlimaj I will raise this as an issue against the ecl library |
|
@dakejahl In theory not publishing would be more efficient, however then we have no way to log the 'invalid' data which is necessary to develop algorithms to detect invalid operating conditions. |
|
It looks like this function isn't turning off range aiding when the data is old. https://github.com/PX4/ecl/blob/4d59c834ebb181b78294ec3981c3d32b470e6f15/EKF/control.cpp#L1143 |
|
@AlexKlimaj Can you please record your observations and any additional discussion here: PX4/PX4-ECL#478 |
|
@AlexKlimaj and @dakejahl Please ensure that your code complies with the updated distance_sensor message interface and that instead of not publishing data when out of range, you set the quality to 0 |
|
I am closing this because the required changes have been pulled into #9865 |
DESCRIPTION
This brings all the range finder data checks (excluding innovation consistency checks) into one place and eliminates the need to perform range checking external to the library. Having checks in multiple places has previously resulted in unintended loss of functionality over time which had to be fixed by #476. This PR should reduce the likelihood of this type of bug being introduced in the future.
The hard coded optical flow tilt limit has also been changed to use the same value as the range finder for consistency.
Variable names have been changed changed to make a clear distinction between the max/min values calculated by by the stuck range check and the max/min valid values published by the sensor.
DEPENDENCIES
Requires PX4/PX4-ECL#477
Impacts #9865 (could be incorporated)
TESTING REQUIRED
For full test coverage we need to check:
Data below min valid (on ground and in air)
Data above min valid (on ground and in air)
Data returning to valid range after > 10 seconds out of range and sticking at a constant value (on ground and in air)
Vehicle tilted > 45 deg
Initial reversion test using replay log here: https://logs.px4.io/plot_app?log=a56f0800-6944-4f46-8171-4a7fab048923