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

Copter: run rate loop at full filter rate in its own thread #27029

Open
wants to merge 34 commits into
base: master
Choose a base branch
from

Conversation

andyp1per
Copy link
Collaborator

@andyp1per andyp1per commented May 9, 2024

This is a redo of #26189

I have squashed the commits, rebased and started fixing the underlying problems. There were some fundamental problems with how the original PR was handling attitude control changes so I thought it was better to just open a new PR.

Support is enabled by setting:

FLIGHT_OPTIONS = 8

which gives a variable attitude rate depending on load, and:

FLIGHT_OPTIONS = 16

which gives an attitude rate locked to the gyro rate

ArduCopter/Attitude.cpp Outdated Show resolved Hide resolved
libraries/AC_PID/AC_PID.cpp Outdated Show resolved Hide resolved
@andyp1per andyp1per added the WIP label May 10, 2024
@andyp1per andyp1per force-pushed the pr-fast-rate-thread branch 6 times, most recently from e67b845 to 679611b Compare May 22, 2024 20:40
@andyp1per
Copy link
Collaborator Author

Flow today on top of 4.5 - working well.

@andyp1per andyp1per linked an issue May 26, 2024 that may be closed by this pull request
@andyp1per andyp1per force-pushed the pr-fast-rate-thread branch 10 times, most recently from bd0fbb4 to 5ef46d2 Compare June 6, 2024 16:26
andyp1per and others added 27 commits June 7, 2024 20:29
configure rate loop buffer based on AP_INERTIALSENSOR_RATE_LOOP_WINDOW_ENABLED
add condition/wait mutex primitive
configure rate loop based on AP_INERTIALSENSOR_RATE_LOOP_WINDOW_ENABLED
configure rate loop via HAL_INS_RATE_LOOP
add set_periodic_minimum() to WSPIDevice
rename get_primary_* to get_first_healthy_*
use primary gyro allocation to enable and disable zero waits in IMU driver
ensure fix rate attitude is enabled on arming
quickly recover from slowdown
output debug error if rate loop buffer overruns
… to occur at rate rate

add rate loop timing debug
control notch update with using_rate_thread
provide more options around attitude rates
only log attitude and IMU from main loop
@andyp1per
Copy link
Collaborator Author

andyp1per commented Jun 9, 2024

@rmackay9 this is close to being ready and I could use your input on what the configuration should look like. The basic premise is that we run the rate controller at the same rate as the gyros which is controlled by INS_GYRO_RATE (0=1Khz,1=2Khz,2=4Khz,3=8Khz). However, this is quite expensive and will not be possible on some hardware setups. In addition we need to be able to log the rate outputs at a faster rate than the main loop rate, but its unlikely that we could successfully log at the gyro rate. Finally we need to update the filters (notch filter in particular) at a faster rate than the main loop, but it does not make sense to do this any faster than at half the gyro rate.

Currently we have the following:
FLIGHT_OPTIONS=8 - enables the rate thread and dynamically schedules the relationship to the gyro rate based on load
FLIGHT_OPTIONS=16 - fixes the rate thread at the same rate as the gyro rate
ATT_FILTER_RATE - update rate of the filters in Hz or fixed at half the gyro rate if set to 0
ATT_LOG_RATE - update rate of the rate logs in Hz or set at the main loop rate if set to 0
The last two are not exact numbers - they are just the closest we can get to the required frequency by counting gyro samples so need to be an integer divisor or the gyro rate.

I'm not currently convinced about the naming or the configuration. I think this is an important enough feature that it needs its own enable flag. I also think it would be worth having a rate parameter that allows you to fix the rate. I also think that ATT is a little bit misleading. Maybe FAST_RATE_ or RATET_ or something. So an alternative might be:

FRATE_ENABLE - set to 1 to enable the rate thread
FRATE_RATE - set to 0 to dynamically throttle, fixed Hz otherwise
FRATE_LOG_RATE - as above
FRATE_FILT_RATE - as above

or something. It would also be possible to not use Hz at all but simply pick the divisor. So 2 would be gyro rate / 2 etc.
Your thoughts appreciated on this important topic!

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.

Run rate controller at full gyro rate
3 participants