Skip to content
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

Adding parameter to scale velocity in flight task get current state #11969

Conversation

FeUs17
Copy link

@FeUs17 FeUs17 commented May 6, 2019

Describe problem solved by the proposed pull request
The state machine in FlightTaskAuto, which is aimed to update the internal waypoint triplet, uses the velocity (_mc_cruise_speed) as parameter. However, one may want a different condition to meet one of those states. With the addition of MPC_WP_NAV_ACC there is the freedom to scale the parameter used by the state machine. If it is equal to 1 nothing changes.
This feature is interesting also because if the acceptance radius is big, it is possible that the drone does not move to the next waypoint because it is in "offtrack" or "previous_infront" state. If the value of MPC_WP_NAV_ACC is large enough this problem can be avoided.

@julianoes julianoes requested review from MaEtUgR and Stifael May 6, 2019 13:36
@MaEtUgR
Copy link
Member

MaEtUgR commented May 7, 2019

Your description hints me towards something is broken in that waypoint logic because as soon as you are in the acceptance radius the vehicle should continue with the next waypoint. If that doesn't work there's a bug. I assume you have the problem that your vehicle in a mission stays too long at a reached waypoint or even gets stuck there. Is that correct? I appreciate you contributing a pull request attempting to solve the problem but it looks to me that the introduced scaling factor is a workaround to avoid the real problem in the logic. I'd prefer to find the root cause of the problem you experienced, do you have a log or more detailed explanation for that? Please correct if I misunderstood.

@FeUs17
Copy link
Author

FeUs17 commented May 8, 2019

Yes, the drone stays too much in the reached waypoint. Due to the state machine in FlightTaskAuto, if the acceptance radius is big (let's say 20 m, so it is easier to see this behavior) the drone may not switch to the next waypoint as soon as conditions are met (assuming that also the altitude acceptance radius is reached). The main reason why this happens, for what I have experienced, is that the drone can enter in "offtrack" or "previous_infront" state, delaying the new waypoints coming from the navigator (as described in the code, waypoints from the navigator can be different from the ones the controller is using). I have suggested this "work around" because there might be special reasons to get this behavior that I'm not seeing and this solution is the one with less impact on the code.

@stale
Copy link

stale bot commented Aug 7, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale
Copy link

stale bot commented Aug 21, 2019

Closing as stale.

@stale stale bot closed this Aug 21, 2019
@MaEtUgR
Copy link
Member

MaEtUgR commented Oct 21, 2019

I think your issue is likely fixed with #12505
Can you check?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants