OA: hysteresis on failsafe #12109
Merged
OA: hysteresis on failsafe #12109
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
mrivi
force-pushed
the
companion_delay_fix
branch
from
5047aa8 to
23f49f1
Compare
|
It's unfortunate about the delay, but no matter what it is impossible for the setpoint to be sent to the companion and the companion to respond, guaranteed, before the next cycle. I'd like some feedback from @bresch about whether there might be a better way to do this, otherwise I think this needs to be merged to avoid getting failsafe warnings on modeswitch from position -> auto ie. without twitching. |
bresch
previously requested changes
Jun 11, 2019
mrivi
force-pushed
the
companion_delay_fix
branch
from
d88cbde to
84a10cb
Compare
jkflying
previously approved these changes
Jun 12, 2019
bresch
previously approved these changes
Jun 12, 2019
|
Sorry, I clicked on the "update branch" and it did a merge of master into that branch. @mrivi could you rebase you branch and force push here again? You could also squash your two commits together at the same time. |
mrivi
force-pushed
the
companion_delay_fix
branch
from
89f521b to
941f5ff
Compare
bresch
approved these changes
Jun 12, 2019
|
@mrivi Please link the result of the test here |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Scenarios that this PR is trying to fix:
You have a vehicle with a companion computer. You take off in PosControl and fly around. The companion doesn't receive any
vehicle_trajectory_waypoint_desiredbecause it isn't in a Auto Mode.Since the algorithm running on the companion always waits for the desired goal from the FCU, it's sending back (NAN, NAN, NAN) position and velocity setpoints. Since you are in PosControl and they don't get fused, your flight is fine.
As soon as you switch into a Auto Flight mode, those NAN setpoints get injected into the AutoMapper. This happens because there is a delay until the companion receives
vehicle_trajectory_waypoint_desired, computes the changed setpoints and sends them back onvehicle_trajectory_waypoint. The flight task failsafe will therefore kick in.How to fix it: on the companion side, if
(xy_pos_sp_valid || xy_vel_sp_valid) && (z_pos_sp_valid || z_vel_sp_valid)the valid flagpoint_validis set to true otherwise is false.If
point_validis false, we don't overwrite the setpoints from the companion such that the FCU failsafe from the flight task doesn't kick in. Otherwise, if the point keeps not being valid for more than 500ms, the OA specific failsafe will kick in.Any other ideas on how to handle the delay with the companion when it isn't always computing a trajectory?