-
Notifications
You must be signed in to change notification settings - Fork 17k
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
Plane: Mode LoiterAltQLand to reuse same loiter point if available #25318
Conversation
Along with PR #25319 this will enable this flight mode to have accurate landings |
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.
LGTM, had a little play in SITL, a nice improvement.
ArduPlane/mode_LoiterAltQLand.cpp
Outdated
@@ -10,17 +10,17 @@ bool ModeLoiterAltQLand::_enter() | |||
return true; | |||
} | |||
|
|||
const Location previous_wp = plane.next_WP_loc; | |||
const bool already_in_a_loiter = plane.reached_loiter_target(); |
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 could be true in modes like FBWA, cruise etc, would go to the wrong position
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.
@tridge changed to
const bool already_in_a_loiter = plane.previous_mode->does_auto_navigation() && plane.reached_loiter_target();
Which I think should handle all the cases.
Note, I CAN NOT use the most accurate and direct check plane.loiter.start_time_ms > 0
because it gets set to 0 in set_mode() before _enter() is called. I looked through the code and it looks like moving that set to 0 is probably OK to move to after the _enter() is successful but that has the potential to create some gremlins that aren't worth it. At this point I feel like reached_loiter_target() not being set to zero in the same place is a bug fixing that by setting to zero would break this PR. To globally fix that we would change reached_loiter_target() to return control_mode->does_auto_navigation() && nav_controller->reached_loiter_target();
but that would need some additional testing.
acb6515
to
e0e6751
Compare
@Hwurzburg wiki update here ArduPilot/ardupilot_wiki#5499 |
This is ready to merge with suggestion(s) from the DevCall applied. |
e0e6751
to
345862c
Compare
I wrote this to do millis() checks and it just looked way too cumbersome for what we're wanting out of this. I realized a more straight-forward solution is to just invalidate the state AFTER a mode change so that enter() and _enter() will still get the existing state but after that it's correctly cleared. That's full-proof. If we want something MORE full full-proof that is time based then we should re-work loiter.start_time_ms to be updated appropriately in all modes which would warrant a new/different PR and lots of testing. |
345862c
to
22738cb
Compare
22738cb
to
de9de0f
Compare
@IamPete1 changes suggested by you from the devcall have been applied. Please re-review |
de9de0f
to
1e53d5d
Compare
1f06bc9
to
786d06f
Compare
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.
I have tested switching into LoiterAltQLand from a mode which is loitering and the point is not moved. I also tested changing to intermediate mode and the point does move.
Current behavior:
Problem:
New/Proposed behavior in this PR: