In 4.0x the dynamic notch range was set by default to AUTO mode.
This would set range to low, medium or high based on the dynamic lowpass max setting, which the user was supposed to configure to suit the maximum rpm of the quad.
In 4.1 we are moving the maximum value of the dynamic gyro lowpass very high whenever the rpm filter is enabled. And, generally, it is OK to do this even on non-rpm quads.
The problem then becomes that the dynamic notch quietly shifts itself to HIGH mode, and that can cause it to not track ordinary frame and prop resonances like it should.
I think it will be better overall in medium mode, which works best for most quads out of the box. Users of very high RPM quads can choose high. XClass quads or machines with low frequency resonance should choose low, and should set the dyn_notch_min_hz value low enough to reach the resonant peak.
Refactor the gyro filtering to move the filters from the individual gyro sensor and make them part of the logical gyro object. For dual-gyro mode the sensors are averaged BEFORE and then filtering is applied. This differs from the current structure where filtering is applied individually to each sensor and the results were averaged at the end.
Significantly reduces filtering processing load and enables RPM Filtering for dual-gyro mode.
In 4.0, the dynamic gyro lowpass1 min and the static gyro lowpass1 alternative had the same values, so that if the dynamic lowpass was not active, we would get conservative static filtering.
In moving to 4.1 with PT1 filtering we have raised the dynamic gyro lowpass1 min, but not raised the static gyro lowpass1 value.
We should make them both the same, again.
The current calculation accumulates gyro data between IMU updates based on the actual time delta betwwn samples. The problem with this is that loop time jitter or delays will decrease the accuracy of the gyro rotational input into the attitude calculation. The sensor samples based on a hardware driven clock that matches the `gyro.targetLooptime`. The sensor captures samples at these intervals regardless of when we read them so the calculation should be based on the duration between samples rather then the duration between processing loops.
Will improve the accuracy of the IMU attitude estimate - particularly in cases of higher CPU load and increased looptime jitter. Bench testing shows reduced drift. Also flight tested and behaved as expected.
The original implementation:
* removed the old 'alignment' variable
* did not require 'ALIGN_CUSTOM'
* always used rotation matrix
* had no additional per-pid-loop conditional logic.
Extract currently unused code into tests.
In preparation for either deleting or re-using in validateAndFixConfig.
Fix code style of some old boardalignment code.
De-duplicate vector rotation code.
Now that rotation code is exacted from `alignBoard` and now doesn't use
`boardRotation` some if it was similar to the code in `rotateV` in
maths.c
Use DECIDEGREES for mag and gyro/acc custom alignments.
Use unnamed structure instead of `values`.
Redefine what 'custom' orientation means.
Move alignment test-only code into the tests.
Ensure gyro/mag custom alignment settings follow the enum variations.
This can't be applied to ALIGN_DEFAULT because, in the case of the MAG,
the default isn't actually known until the gyro is detected, see
`compassDetect`.
OMNIBUSF4/F7 - Don't use ALIGN_DEFAULT in target.h,
common_defaults_post.h does this now.
Comment cleanup.
Delete unused alignment code left from various tests/refactoring
efforts.
* Please do not squash this commit.
Fix SITL build by avoiding structure assignment with anonymous inner
struct.
The error from the build server was as follows:
```./src/main/common/sensor_alignment.c:49:5: error: missing initializer
for field ‘yaw’ of ‘struct <anonymous>’
[-Werror=missing-field-initializers]
*sensorAlignment = CUSTOM_ALIGN_CW0_DEG;
^
In file included from ./src/main/common/sensor_alignment.c:27:0:
./src/main/common/sensor_alignment.h:80:17: note: ‘yaw’ declared here
int16_t yaw;
^
```
Cleanup sensor_alignment API.
Evolutionary changes to the original 4.0 defaults.
Intended to reduce chance of D-mediated flyaways on arming.
Also seems to fly better due to less gyro delay.
CHanges:
- Gyro filtering dynamic reverts back to PT1, to provide less delay, and in recognition that gyro filtering was more than adequate with the biquad. Setpoints are higher due to lower reach of PT1. The static gyro biquad at 150 was lower than really needed. Markedly less gyro delay.
- Stronger D term filtering, especially at low throttle, to greatly reduce risk arming flyaways. The Dynamic D biquad is now set almost twice as low, with strong cut at 100hz where D resonance flyaways seemed to be driven from. This filter array results in a D noise contribution that is typically not much greater than the P contribution, keeping very cool motors despite the lesser gyro filters. This has been well tested using PID Toolbox.
Although there is more delay in D, this is offset by the reduced gyro delay.
Some users have reported flyaways on arming/throttling up with betaflight 4.0, in quads that fiy alright on 3.5.
This PR changes the default filtering so that D transmission more closely approximates that of 3.5.
With these defaults, quads that fly OK on 3.5 should not take-off vertically due to uncontrolled D oscillation.
Broken in e44f75b4a7.
Problem caused by not checking both of the bits after masking.
Prior to this commit the code would incorrectly attempt to use GYRO1
when only GYRO2 was detected resulting in a segfault.
Defaults will be the same regardless of whether the target has `USE_DYN_LPF` included. Previously the defaults would vary and it wouldn't be obvious why.
Defaults are as follows:
gyro lowpass 1: 150/BIQUAD
gyro lowpass 2: OFF
dterm lowpass 1: 150/BIQUAD
dterm lowpass 2: 150/BIQUAD
Nothing has changed int eh dynamic lowpass logic. If it's enabled those settings will be used in place of the static lowpass cutoff.
Needs coordination with the Configurator to change the defaults used when re-eanbling the lowpass filters as they are currently based on previous version settings and will dfault to inappropriate values.
* Introduce CLI parameter gyro_filter_debug_axis which defaults to 'ROLL',
the previous behavior. When set to either PITCH, or YAW, the debug logging
implementation in the gyro filtering will use that axis instead.
Bypass the numerous dual-gyro DEBUG_SET statements unless a related debug_mode is set. The dual-gyro debugging is rarely used so in most cases all of the statements can be bypassed. Saves 1-2% CPU load on SPRACINGF7DUAL running in `gyro_to_use = BOTH` and at 32K.
Since the gyro overflow and yaw-spin logic uses filtered gyro data they need to be after the filter application.
Currently the logic is before causing it to operate on one sample old data. This won't prevent the logic from working and it's not a critical fix, but it's better to have the checks after the filtering.
Fixes instances of hardcoded gyroSensor1 in the status functions for overflow detection, yaw spin detection, and the sensor temperature reading.
Also fixes non-reentrant code in gyroUpdateSensor() that would not behave properly when gyro_to_use = BOTH
