-
Notifications
You must be signed in to change notification settings - Fork 13.7k
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
Adding parameter to scale velocity in flight task get current state #11969
Conversation
…htTaskAuto for offtrack and previous_in_front
…htTaskAuto for offtrack and previous_in_front
…rentState' of https://github.com/FeUs17/Firmware into adding_parameter_to_scale_velocity_in_flightTask_getCurrentState
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. |
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. |
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. |
Closing as stale. |
I think your issue is likely fixed with #12505 |
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.