Mixer Motor Command Limit of 85% at 0% throttle

[spatzengr]

The Mixer is capping the MAX Motor Command to 85% even when MAX_THROTTLE (etc...) is set to 100%.

You can see in the below two examples when MAX_THROTTLE is set to 2000us (100% throttle --- no CAP) that at full throttle on the transmitter, you get 100% Motor Command. However, when the throttle is dropped to 0% and you input a sharp stick move, it caps the Motor Commands to 85%.

This is NOT my log file and the filters\tune needs work, but regardless, you can clearly see it. I have also run tests myself and get the same result on iNAV 5.1.

This reduces the quad power by 25%!!! to implement sharp stick moves. Of course, even at moderate max rates of 700dps you can easily require more than 85% of your max motor thrust to follow your rates on sharp stick inputs (5" quad even || much worse for larger quads).

EXAMPLE #1:

EXAMPLE #2:

To see flat caps on motor commands (just below 85%) when the PID Sum is still rising is a dead giveaway of a Mixer cap. Coordinating with @DzikuVx , we don't believe there is a variable to adjust the code to prevent this cap; which is no good.

Example 1. Log (another iNAV pilot)
LOG00088.TXT

Example A. Log from my quad where I noticed the issue.
LOG00010-TL=2000 + Punchout.TXT

[robert-b]

no comment from the inav devs.
the mixer is highly qustionable as the 'main' concern is clipping to soften the response.
this has a price.

[spatzengr]

It appears to be a bug from when Throttle Cap was implemented?

Regardless of the sources of the issue, there is no logical reason to hard code a limit to an arbitrary 85% of what the PID Controller commands which of course take any motor and reduces the control.value by 15%. Any logical reason would need to justify 85% vs 70, 60, 90, etc...

By BIGGEST concern is this is not being considered a major issue (maybe folks are just busy)? Big quads - iNAV's main audience in the quad space - always have issues with Motor Saturation. Meaning the motors cannot produce the desired thrust to keep up with the controllers commands. This makes that issue 15% worse! It will also however affect all quad classes (as we can see in the two above examples on 5") and will make iNAV feel disconnected (lagged) from sharp stick inputs. Basically, negating the purpose of implementing Feedforward. So implementing FF and having an arbitrary Controller / Mixer command cap is not logical.

I fear iNAV is dying in the quad space so there is a lack of interest? Personally a struggle to devote the time myself to try to find and rectify as BF looks to be on a path to implementing GPS functionality. I hope would be easy for someone familiar with the Controller / Mixer code? 😬

[robert-b]

yes, i agree.

[OptimusTi]

Have you guys looked at closed issues? For some reason, this sounds familiar.

[spatzengr]

Have you guys looked at closed issues? For some reason, this sounds familiar.

I did look and talked to Pawel prior to posting as an issue. Understanding working hard to get iNAV 6.0 out the door, I figured it was not the top priority.