-
Notifications
You must be signed in to change notification settings - Fork 13.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Robustify range finder kinematic consistency check #22117
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -62,15 +62,15 @@ void Ekf::controlRangeHeightFusion() | |
const Vector3f pos_offset_earth = _R_to_earth * pos_offset_body; | ||
_range_sensor.setRange(_range_sensor.getRange() + pos_offset_earth(2) / _range_sensor.getCosTilt()); | ||
|
||
// Run the kinematic consistency check when not moving horizontally | ||
if (_control_status.flags.in_air && !_control_status.flags.fixed_wing | ||
&& (sq(_state.vel(0)) + sq(_state.vel(1)) < fmaxf(P.trace<2>(State::vel.idx), 0.1f))) { | ||
if (_control_status.flags.in_air) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What's the harm in letting this always run (!in_air)? The actual usage in the terrain estimator is still going to require in_air && rng_kin_consistent. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. An issue I see is when the operator is powering the drone but is still manipulating it before takeoff. There is then a high chance to fail the consistency check for no real reason. It should then be validated again after takeoff, so in theory it's not a big problem, the terrain estimator will just start a bit later and the 5s of no terrain aiding timeout should be enough. |
||
const bool horizontal_motion = _control_status.flags.fixed_wing | ||
|| (sq(_state.vel(0)) + sq(_state.vel(1)) > fmaxf(P.trace<2>(State::vel.idx), 0.1f)); | ||
|
||
const float dist_dependant_var = sq(_params.range_noise_scaler * _range_sensor.getDistBottom()); | ||
const float var = sq(_params.range_noise) + dist_dependant_var; | ||
|
||
_rng_consistency_check.setGate(_params.range_kin_consistency_gate); | ||
_rng_consistency_check.update(_range_sensor.getDistBottom(), math::max(var, 0.001f), _state.vel(2), P(State::vel.idx + 2, State::vel.idx + 2), _time_delayed_us); | ||
_rng_consistency_check.update(_range_sensor.getDistBottom(), math::max(var, 0.001f), _state.vel(2), P(State::vel.idx + 2, State::vel.idx + 2), horizontal_motion, _time_delayed_us); | ||
} | ||
|
||
} else { | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't you want to still invalidate if there's horizontal motion?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, we can validate regardless of the horizontal motion, but we can only invalidate if we're only moving vertically, otherwise a change in terrain height would invalidate too.