Copter: run rate loop at full filter rate in its own thread #27029
Conversation
andyp1per
force-pushed
the
pr-fast-rate-thread
branch
6 times, most recently
from
e67b845
to
679611b
Compare
|
Flow today on top of 4.5 - working well. |
andyp1per
force-pushed
the
pr-fast-rate-thread
branch
13 times, most recently
from
2370654
to
6398bd3
Compare
|
@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 Currently we have the following: 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:
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. |
There was a problem hiding this comment.
please check we always pair cork/push together (@peterbarker suggested an internal error if we push without cork)
|
i'm happy with the system level and the AP_InertialSensor and AP_Vehicle changes, so from the point of view of plane which doesn't use this I'm happy with this PR |
run motors output at rate thread loop rate allow rate thread to be enabled/disabled at runtime for in-flight impact testing setup the right PID notch sample rate when using the rate thread the PID notches run at a very different sample rate call update_dynamic_notch_at_specified_rate() in rate thread log RTDT messages to track rate loop performance set dt each cycle of the rate loop thread run rate controller on samples as soon as they are ready detect overload conditions in both the rate loop and main loop decimate the rate thread if the CPU appears overloaded decimate the gyro window inside the IMU add in gyro drift to attitude rate thread add fixed-rate thread option configure rate loop based on AP_INERTIALSENSOR_FAST_SAMPLE_WINDOW_ENABLED better rate loop thread decimation management ensure fix rate attitude is enabled on arming add rate loop timing debug update backend filters rather than all the backends provide more options around attitude rates only log attitude and IMU from main loop force trigger_groups() and reduce attitude thread priority migrate fast rate enablement to FSTRATE_ENABLE remove rate thread logging configuration and choose sensible logging rates conditionally compile rate thread pieces allow fast rate decimation to be user throttled if target rate changes immediately jump to target rate recover quickly from rate changes ensure fixed rate always prints the rate on arming and is always up to date add support for fixed rate attitude that does not change when disarmed only push to subsystems at main loop rate add logging and motor timing debug correctly round gyro decimation rates set dshot rate when changing attitude rate fallback to higher dshot rates at lower loop rates re-factor rate loop rate updates log rates in systemid mode reset target modifiers at loop rate don't compile in support on tradheli move rate thread into its own compilation unit add rate loop config abstraction that allows code to be elided on non-copter builds dynamically enable/disable rate thread correctly add design comment for the rate thread Co-authored-by: Andrew Tridgell <[email protected]>
restrict rate loop to H7 and F7
honour the requested dshot rate as near as possible
…tions.py and extract_features.py
…n non-copter builds
…hread decimate the gyro window locally configure rate loop buffer based on AP_INERTIALSENSOR_FAST_SAMPLE_WINDOW_ENABLED allow backends to be updated from rate thread output debug error if rate loop buffer overruns add support for updating filter parameters independently of propagating samples add rate loop config abstraction that allows code to be elided on non-copter builds must be using harmonic notch to use rate thread mediate fast rate loop buffer using mutex and binary semaphore ensure gyro samples are used when the rate loop buffer isn't Co-Authored-By: Andrew Tridgell <[email protected]>
add nullptr checks and comments to FastRateBuffer
log after motor output in fast rate thread
andyp1per
force-pushed
the
pr-fast-rate-thread
branch
from
63d3797
to
89bc8ce
Compare
| // @Description: Enable the fast Rate thread. In the default case the fast rate divisor, which controls the update frequency of the thread, is dynamically scaled from FSTRATE_DIV to avoid overrun in the gyro sample buffer and main loop slow-downs. Other values can be selected to fix the divisor to FSTRATE_DIV on arming or always. | ||
| // @User: Advanced | ||
| // @Values: 0:Disabled,1:Enabled-Dynamic,2:Enabled-FixedWhenArmed,3:Enabled-Fixed | ||
| AP_GROUPINFO("FSTRATE_ENABLE", 9, ParametersG2, att_enable, 0), |
There was a problem hiding this comment.
Do you forsee more params here in the future? It would be nice to make this a enable in a little sub tree.
| FAST_RATE_FIXED = 3, | ||
| }; | ||
|
|
||
| FastRateType get_fast_rate_type() const { return FastRateType(g2.att_enable.get()); } |
There was a problem hiding this comment.
What happens if I set a out of range value? Lots of places are checking != FAST_RATE_DISABLED what would a values of -1 result in? Unfortunately we have a presdent that -1 is the same as disabled for lots of params.
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:
which gives a variable attitude rate depending on load, and:
which gives an attitude rate locked to the gyro rate, but dynamic while disarmed. For testing there is also:
which is a locked rate at all times.
The output rate can be adjusted using
FSTRATE_DIVwhich is a gyro divisor (default 1).Two different rates - and therefore tunes - can be compared by using the lua applet
switch_rates.luawhich will persistently switch the appropriate tune/rate parameters with ones saved in names beginning withX_