ManualSmoothVel - Split position lock condition and flag action #11543
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
|
@bresch thanks for the explanation in the PR, that's helpful. But next time, please put it in the commit message in the first place. |
julianoes
reviewed
Feb 26, 2019
src/lib/FlightTasks/tasks/ManualPositionSmoothVel/FlightTaskManualPositionSmoothVel.cpp
Show resolved
Hide resolved
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.
In some special cases, the controller enters position lock and the velocity/acceleration setpoint leaves the position lock condition, without actually triggering the unlocking condition (condition depending on the stick only). The position setpoint then drift "behind the scenes" (because it's the integral of the non-zero velocity setpoint) and when the condition becomes again true, a severe position jump can occur. We had a jump of 10m due to a slow drift during a fixed hover of 1 min
This should never happen, but it seems that the trajectory generator fails to find a solution is some specific cases that lead to unexpected behaviors.
This PR doesn't fix the root cause of the problem, but at least, the drone will follow the drift (in my case, move 10m in 1min) and not do a sudden jump of 10m.
I'm actively trying to find the root issue but this PR has to be merged as that behavior could cause severe damages.
See below the position jump in the y axis at t=210s
