-
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
AutoSmoothVel - Compute desired speed at target based on path curvature #12505
Conversation
@PX4/testflights Can you test this PR in mission (survey and random mission) please? The drone should slow down but not stop if the turn is not too sharp. |
@@ -177,6 +177,50 @@ void FlightTaskAutoLineSmoothVel::_checkEkfResetCounters() | |||
} | |||
} | |||
|
|||
float FlightTaskAutoLineSmoothVel::_getSpeedAtTarget() |
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.
can we move the two new methods into a UtilityClass/Function with more general names? then we can reuse it in other tasks as well
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.
Agreed, it would be great to use the _getMaxSpeedFromDistance
in the collision prevention as well, instead of using just the velocity controller P gain.
looks great. will try to test it tomorrow on H520 |
What if the angle is really acute? |
@hamishwillee The circle with radius R gets smaller and when the angle is 0, the radius is 0 and the desired entrance speed is 0. |
I tested it on the H520 and seems to work well. I think it is a bit too conservative at corners and approaches the waypoints a bit too slow. Can that be changed via tuning? During one particular survey, the vehicle also experienced an abrupt stop at one of the waypoints (see below), where the drone first accelerated before it stopped abruptly. The flight log: In addition, to prevent the vehicle from passing a waypoint if the altitude has not been reached yet, I created this PR. |
Tested on PixRacer V4:Flight Card 2 Modes Tested Procedure Note: Logs: https://review.px4.io/plot_app?log=8e5b032a-ec31-48e4-9ec6-9ae59b0ded49 https://review.px4.io/plot_app?log=293a137f-56b3-47d0-9a00-46760d04b4e2 |
Tested on Pixhawk 4 mini v5:Flight Card 2 Modes Tested Procedure Note: Logs:
Tested on Pixhawk Pro v4:Flight Card 2 Modes Tested Procedure Note: Logs:
Tested on NXP FMUK66 v3:Flight Card 2 Modes Tested Procedure Note: Logs: |
…n previous-current and current-next waypoints Also remove crosstrack P controller that produces overshoots when the acceptance radius is large (crosstrack error is suddenly large at waypoint switch).
… been reached yet
Add check for this flag in AutoLine
…utation of the maximum waypoint entrance speed
@Stifael I moved the computation in static functions inside the VelocitySmoothing class that contains the jerk-limited optimizer. Is that enough or do you want them in an other file (header library? what would be the scope of the library? name? ...) |
Do you think it makes sense to have I think if the function has a general implementation and is not necessarily FlightTasks related, then it could be put into the math-library similar to other functions (https://github.com/PX4/Firmware/blob/master/src/lib/mathlib/math/Functions.hpp#L48-L208). If it will anyway just be used by FlightTasks, then I would put it in a file such that it can easily be found. For instance, |
4b43089
to
15dbed2
Compare
@Stifael I moved the functions into a |
* @return maximum speed | ||
*/ | ||
template<typename T> | ||
const T computeMaxSpeedFromBrakingDistance(T jerk, T accel, T braking_distance) |
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.
Awesome! I'll try to get this into the collision prevention as well.
@PX4/testflights Can you test that again please? |
Tested on Pixhawk4 v5 f-450 Modes Tested Procedure Pr log: https://review.px4.io/plot_app?log=d3b10670-b737-4657-9ea8-9484d79ecbdf |
@dannyfpv Thanks a lot! Ready to be merged once we have a bit more space on the omnibus target :| |
Tested on PixRacer v4:Modes Tested Procedure Note: Logs:
Tested on Pixhawk Pro v4Pro:Modes Tested Procedure Note: Logs: |
Describe problem solved by the proposed pull request
Currently, the drone does waypoint navigation while almost stopping at each waypoint. When the waypoints are aligned or that the heading change is small, we should not completely stop the drone but rather decelerate to make a nice turn and continue.
Describe your preferred solution
The solution implemented in that PR assumes that the drone will fly an arc between the two lines connecting to a waypoint and that we want to fly this arc with some desired centripetal acceleration. Given the acceptance radius
r
, the desired centripetal accelerationac
and the angle between the two lines α, we can easily compute the desired waypoint speed:Also, to avoid entering too fast into the waypoint if the next waypoint is really close, the maximum speed between current and next is computed to constrain the waypoint speed.
You can interactively estimate the waypoint speed by clicking on the following link:
https://www.desmos.com/calculator/rvx6uybeo8
Tests
I tested quite extensively in SITL and on a F550.
Here an example of a log:
https://logs.px4.io/plot_app?log=2ab24653-a229-4e81-8295-ee7c58c8a373
Related
Fixes #11827