Skip to content

Smooth yaw in auto mode by limiting acceleration #24766

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

Merged
merged 4 commits into from
May 21, 2025

Conversation

dawr68
Copy link
Contributor

@dawr68 dawr68 commented Apr 25, 2025

Solved Problem

Currently, only a slew rate is applied to the yaw setpoint, which causes issues on highly responsive platforms (e.g., helicopters) due to steep changes in the yaw setpoint.

actual

Solution

Smooth the yaw setpoint by limiting the yaw acceleration.

Results

Applying an acceleration limit leads to more realistic yaw and yaw rate setpoints, enabling improved yaw tracking performance.
smoothed

@dawr68 dawr68 requested review from MaEtUgR and bresch April 25, 2025 18:39
@dawr68 dawr68 self-assigned this Apr 25, 2025
@MaEtUgR MaEtUgR force-pushed the yaw-acceleration-limit branch from ab4c87b to cd85bc0 Compare May 8, 2025 16:26
@MaEtUgR
Copy link
Member

MaEtUgR commented May 8, 2025

I rebased and added my suggestions. I also did some testing in SITL SIH and realized we should adjust the default parameters such that this change shows the significant improvement I was looking for. The current defaults only make sense with the current limited implementation that doesn't consider acceleration.

image

EDIT: I checked the rough timing for a 180° turn which is likely the worst case for an autonomous yaw change (otherwise you start to rotate the other direction) and assuming the drone could accelerate indefinitely with the previous slew rate it would by default turn in (180°) / (45°/s) = 4s which it of course never managed and overshot so it probably took ~5-6s. If we have a high (100°/s) limit with the new implementation but limit the acceleration to have a smooth turn it roughly results in the following timings if it can track the demanded yaw acceleration:

Acceleration Time to turn 180°
5°/s^2 ~12s
10°/s^2 ~9s
15°/s^2 ~7s
20°/s^2 ~6s
25°/s^2 ~5s
30°/s^2 ~4.8s
35°/s^2 ~4.65s
40°/s^2 ~4.38s
45°/s^2 ~4.17s
50°/s^2 ~4s
55°/s^2 ~3.78s
60°/s^2 ~3.55s

I suggest to go with 20°/s^2 for a start and adjust that in case we see undesired either too slow or too aggressive yawing.

@MaEtUgR MaEtUgR force-pushed the yaw-acceleration-limit branch from cd85bc0 to 456f073 Compare May 8, 2025 18:55
@MaEtUgR
Copy link
Member

MaEtUgR commented May 8, 2025

I added the HeadingSmoothing also to the Orbit flight task because it's the only other place that uses the maximum autonomous yaw rate and still has a slew rate. And then suggested the 60°/s and 20°/s^2 defaults. The acceleration could possibly still be increased a bit if we deem it not quick enough but I kept it relatively low such that even with not-so-great yaw tracking you have minimal overshoot.

@dawr68
Copy link
Contributor Author

dawr68 commented May 20, 2025

Test flown today on a 10" multicopter. The results are promising, however we can possibly increase default yaw acceleration as the vehicle didn't reach maximum yaw rate.
image
With proposed default values, the vehicle was smoothly tracking the trajectory and adjusting heading.
image

@dawr68 dawr68 requested review from MaEtUgR and removed request for bresch May 20, 2025 15:33
Copy link
Member

@MaEtUgR MaEtUgR left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dawr68 Thanks for the real world testing you provided. Now that you checked again and tested I feel confident to merge. If the defaults turn out to be limiting in some use case I'm happy to follow up with adjustments.

@MaEtUgR MaEtUgR merged commit 30df381 into PX4:main May 21, 2025
62 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants