The calculation used to transform the rcCommand[THROTTLE] value to a throttle value used in the mixer was incorrectly applying the `min_check` range a second time. This leads to the mixer throttle value scaling incorrectly and adds an additional deadzone at the low range that basically doubles the `min_check` range.
Currently only rcCommand values are included in the log data and the configurator calculates the actual setpoint values based on rates values added to the blackbox header. The problem with this is that the rates information is only written at arming so if the rates change during the log (rateprofile change, in-flight adjustments, etc.) then the calculated setpoints will be incorrect. There's no way to tell from the log that this happened. This often causes confusion because it will suddenly make it appear in the log that the PID controller is not acheiving the requested rates when it's just a presentation error. Also the rates will be incorrectly calculated when the user selects Raceflight style rates as the rates type is not supplied in the log header (and the viewer doesn't have the forumla for them anyway).
This change adds the actual setpoint values for each axis as used by the PID controller, removing the necessity for the viewer to perform any calculations. In addition to showing any rate changes, it will also show any cases where other flight features have modified the setpoints from the user's input. These were invisible previously (examples include level modes, Acro Trainer, GPS Rescue, yaw spin recovery, etc.).
Also the throttle value used in the mixer is included in the throttle axis. This allow visualization of things that affect the commanded throttle like throttle boost, throttle limit, GPS Rescue, angle level strength, etc.
The DSHOT digital idle value is quite low (4.5%) and is often the cause of support issues as users are unaware that they may have to adjust this based on their motor/ESC requirements - leading to de-syncs and "death rolls" or other flip-outs.
While DSHOT capable ESC's (BLHeli_S & BLHeli32) have faster MCU's and are often capable of smoother low speed idling, 4.5% is still quite low. For comparison the `min_throttle` default is 1070 equating to a 7% idle.
I propose raising the digital idle to 5.5% to reduce occurrences of de-syncs from too low idle speed.
Current logic produces excessive load because it updates the filter cutoffs every PID loop based on the throttle value.
The throttle values only change based on receive RX packets so they change relatively infrequently compared to the PID loop. However with rc smoothing on throttle the value can change every PID loop. But in reality we don't really need to adjust the filter cutoffs for every tiny change to the floating point throttle value.
This change quantizes the throttle in to 100 steps and uses that to compare to the previous value to decide if the filter cutoffs need to be updated. While this reduces the resolution of the filter cutoffs it in turn dramatically reduces the processing overhead. IF needed the quantization steps can be increased for more resolution but at the cost of some performance.
Adds a race start assistance system that allows the pilot to pitch forward and then release the sticks with the quad holding position for the race start.
The MOTOR_STOP logic is designed to stop the motors if:
1. MOTOR_STOP feature is enabled
2. Airmode is disabled
3. Throttle is at minimum
The problem is that this also applied during GPS Rescue and if the pilot had these conditions the motors would stop. Changed to disable MOTOR_STOP while GPS Rescue is active.
Also if stick-arming is used the MOTOR_STOP logic also will auto-disarm after 5 seconds (auto_disarm_delay). Disable this also when GPS Rescue is active.
When using switched 3D modes the throttle stick ranges from 0-100% controlling the motors in only one direction. The problem was that the 3D Throttle Deadband was being applied to the minimum throttle making a much larger throttle deadband from zero throttle. So in the case of the default deadband of 50, the throttle stick movement would be equivalent to 100us of deadband (output is halved so requires double the input). This would be like trying to fly with `min_check` set to 1100.
The fix uses `min_check` to set the deadband when in switched 3D modes. This produces the same throttle deadband as normal non-3D flight.
Change the logic to not modify rcCommand directly and instead apply the additional throttle directly in the mixer.
Also move the logic to the attitude task instead of having it calculate in the PID loop. The logic relies on an angle that's only updated in the attitude task so there was no point in running the calculation every PID loop.
Injecting new values directly into rcCommand to override pilot inputs does not work correctly when rc interpolation or smoothing is enabled. This is because the smoothing functions maintain an internal state that is used to produce the final rcCommand values. So in effect it re-overrides the values set by GPS Rescue.
Additionally, modifying rcCommand directly is undesirable because:
- It happens before rates are applied. So the pilot's rates will effect the control commanded by GPS Rescue.
- rcCommand values are used for more than input in the flight control. They also are used for stick commands, etc.
- In the case of throttle, various modifications can be additionally applied like throttle boost and throttle limit that may negatively effect GPS Rescue.
These changes revise the logic to only modify the commanded values used in the PID controller (yaw) and mixer (throttle) rather than attempting to override rcCommand.
The telemetry data provides eRPM/100. Added a `motor_poles` parameter (defaulting to 14) that is used to calculate the physical RPM.
RPM = (telemetry_rpm * 100) / (motor_poles / 2)
Most motors we commonly use are 14 poles, but the user can adjust if needed for their setup.
Also calculate actual RPM for DEBUG_ESC_SENSOR_RPM, but to fit with in int16 the log value will be RPM/10.
