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.
Servos marked as forwarded from RC channels and not written previously
should be written after gimbal servos and before forwarding by
FEATURE_CHANNEL_FORWARDING.
Higher feed forward improves stick responsiveness and reduces bounce back on lower authority quads.
Feed forward defaults in 4.0 were slightly conservative even for typical quads.
In association with ff_boost and ff_max_rate_limit, overshoot with even higher feed forward is less of a problem than before.
I think these values should be about right for 4.1
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.
The feed forward changes in 4.1 will bring, to all quads of reasonable control authority, reduced setpoint to gyro delay and less error. iTerm will tend to accumulate less during fast inputs so there will be less of a problem with iTerm-windup and iTerm related bounce-back.
Higher I values lead to better control during tight turns and greater stability in wind. Higher I doesn't increase the absolute amount of iTerm accumulating in the PID loop, but does allow it to change more quickly and to more quickly zero out the residual errors that are strong in tight turns.
I think this modest increase will optimise performance of the default 4.1 PIDs for most quads.
Lower authority quads will need to either reduce their I setting, or, preferably, lower the iterm_relax value to 10 or even 5, to avoid wind-up.
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.
It turns out that two calls to micros() and the calculation of
directionChangeDurationUs took 581 cycles, vs 396 cycles without the
calls to micros() and deferred calculation of the duration which is only
needed in the CLI.
This brings the time down from around 7 microseconds to 5.5 microseconds
on an F3 at 72Mhz.
This makes the difference between 100% invalid telemetry and 4% invalid
telemetry on the first motor on the F3.
Squashed commits:
* Remove the forward declaration for `pwmDshotSetDirectionInput` and make
it static.
* Remove unneeded forward declaration of `motor_DMA_IRQHandler`.
* Remove duplication in DMA IRQ Handler.
Doesn't affect resulting code but improves readability.
* Use an inline function to read DWT->CYCCNT.
* Remove unneeded forward declarations from cli.c now that the correct
header is included.
* Update DWT unlock method.
Refactoring steps were as follows:
* Duplicate pwmDshotSetDirectionOutput to pwmDshotSetDirectionInput and
remove `output` variable in preparation for removing the `output` variable from each method.
* Delete all trace of `output` flag from `pwmDshotSetDirectionInput`
* Delete all trace of `output` flag from `pwmDshotSetDirectionOutput`
* Cleanup now that pwmDshotSetDirectionInput is only called when USE_DSHOT_TELEMETRY is
enabled.
* Remove redundant code paths.
* Move #ifdef outside the method.
* Removed parameters that are never needed.
* Delete unneeded forward declarations.
Adds the RPM (ESC sensor or DSHOT telemetry), invalid packet stats (DSHOT telemetry), and ESC temperature (ESC sensor) for each motor to MSP.
Adds controlling flags and `motor_poles` to `MSP_MOTOR_CONFIG`.
Added to the MSP_MOTOR_CONFIG message:
U8 configured motor count
U8 motor poles
U8 dshot telemetry enabled (boolean)
U8 esc sensor enabled (boolean)
New MSP_MOTOR_DSHOT_TELEMETRY message
U8 motor_count - number of active motors for which data will follow
Loop for motor_count
U32 motor_rpm
U16 invalid_packet_percent - 2 decimal places. So 10000 is 100.00%
U8 esc temperature (degrees celcius)
U16 esc voltage (0.01V per unit)
U16 esc current (0.01A per unit)
U16 esc mAh consumption
