if the user arms within 30s of startup then stop the re-init of the
sensors. This can give less accurate frequency as the sample rate may
not have settled yet, but it is better than doing init of the filters
while the vehicle may be flying
also fix a 32 bit millis wrap
Issue introduced in https://github.com/ArduPilot/ardupilot/pull/27370
and partially fixed in https://github.com/ArduPilot/ardupilot/pull/27762,
though evidently not properly tested.
Failing to track the maximum can result in dangerously low values being
calculated for `ATC_ACCEL_[RPY]_MAX` and the vehicle becoming unflyable.
Make the variable a reference so that the maximum value is preserved
between function calls.
When an airspeed sensor is not used, during a takeoff, the pitch angle
is asymptotically driven to 0 as the takeoff altitude is approached.
Some airplanes will then stop climbing and fail to reach altitude.
To prevent an indefinite wait for the takeoff altitude to be reached, a
dedicated level-off timeout has been introduced.
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 <andrew@tridgell.net>
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 <andrew@tridgell.net>
santhoshini
Andrew Tridgell
Iampete1
shen
Andy Piper
Randy Mackay
Thomas Watson
George Zogopoulos
Tom Pittenger