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
FW navigation first order hold move to position controller #15677
Conversation
016af91
to
5089b88
Compare
5089b88
to
d628cbe
Compare
@dagar I did some testing on this branch. I fixed a few things that seemed obviously wrong to me (see comments above). There's still an issue in the logic switching between position setpoint and loiter setpoint. It seems to constantly switch between the two. I need to dig a bit deeper. |
Signed-off-by: RomanBapst <bapstroman@gmail.com>
@dagar Please check the commit I pushed. |
3fc3c52
to
84f8ba9
Compare
loiter and position type waypoints Signed-off-by: RomanBapst <bapstroman@gmail.com>
Signed-off-by: RomanBapst <bapstroman@gmail.com>
@dagar I fixed a bug in the FOH logic and did some small changes to make things work. I don't really like this too much though. The main problem is that we decide to switch from a position setpoint to a loiter based on an acceptance radius. However, the loiter radius might be much bigger than the acceptance radius and so as the vehicle is trying to loiter the logic will put it back into position mode. |
Signed-off-by: RomanBapst <bapstroman@gmail.com>
@@ -718,6 +720,8 @@ FixedwingPositionControl::control_position(const hrt_abstime &now, const Vector2 | |||
} | |||
} | |||
|
|||
_type = position_sp_type; |
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.
This should probably probably be reset for the other cases.
Thanks @RomanBapst, looks good. |
- this was overzealously removed in #15677
- this was overzealously removed in #15677
Take 2 #8883