-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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
Heli AutoTune: fix rate and accel limiting #28911
Conversation
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 posed some questions but it all looks correct to me.
dwell_freq = chirp_input.get_frequency_rads(); | ||
float tgt_att_limited = tgt_attitude; | ||
if (is_positive(dwell_freq)) { | ||
float tgt_att_temp = tgt_attitude; |
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.
Why do we need the extra variable?
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.
@lthall I think it is needed to hold the rate limited attitude. If the rate limit is not set then it will skip setting tgt_att_temp variable. I guess I could just use the tgt_att_limited variable throughout and keep setting it from the MIN function.
rate_test_max = rate_max; | ||
accel_test_max = accel_max; | ||
// have attitude controller not perform rate limiting and angle P scaling based on accel max | ||
rate_test_max = 0.0; |
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.
If we are limiting the chirp then we shouldn't be hitting these limits unless there is a plot input.
I am not very familiar with how you handle pilot input here but it may be dangerous if you don't have acceleration limiting and do accept pilot input.
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.
@lthall Pilot input is not allowed during the autotune input. It works just like multi autotune where once the pilot makes inputs, the autotune maneuver is stopped.
@lthall I think you should consider adding the limiting the way i have done it here to the chirp function and SysID mode. Once it is added then I would modify my code to just use it. I did it in the Heli autotune just because I wanted to ensure this got into 4.6 since the other technique was not effective. |
@rmackay9 If there are no issues here from your end, I would like to merge this since I got Leonard's approval. |
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.
Hi @bnsgeyer, it's OK to me to merge, thanks!
The original implementation of this relied on the attitude controller to provide the rate and accel limiting. The rate limiting worked but it can cause square wave behavior as it clips the rate at the rate limit. As for the accel limiting, the attitude controller wasn’t designed with the feedforward turned off to limit accel. It actually reduces the angle P to reduce acceleration.
So a different approach was taken. Using a sinusoidal input makes it easy to limit the acceleration and rate without causing any clipping. The attitude amplitude was modified based on the first and second derivative of the amplitude sinusoid chirp. This ensures the desired rate and acceleration are limited. However, the target values maybe smaller or larger based on the error and angle P. In most cases I have seen the target rates are lower.
This has been tested in SITL.