Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Thrust Linearization #7304

Merged
merged 3 commits into from Jan 8, 2019

Conversation

@joelucid
Copy link
Contributor

joelucid commented Dec 28, 2018

This is a genius feature developed by Markus Gritsch of the SilverWare community. Full credits to him.

First we note that pids deal best with linear control systems. If control response is linear the same pid tune works well across the entire control range.

Next we note that thrust is proportional to rpm^2. While rpm isn't proportional to throttle it's also not the sqrt of throttle. The thrust to throttle curve looks something like this:

image

Clearly this results in weaker pids at low throttle than at the top of the throttle range. Something we've traditionally counteracted with TPA.

Now all we have to do to present the pids with a linear system again is to compensate for this non-linearity. This feature does this. Start with set thrust_linear=50 and watch your quad miraculously solve many of the issues we've struggled with for ages. You need to then reduce D, or add FF to take full advantage of the feature.

I was able to reduce my quad's latency from 7ms to 4ms by enabling this. Quad starts moving much earlier due to the quicker motor signal rise at the beginning of a move.

This really seems like a break-through. See discussion at: https://www.rcgroups.com/forums/showpost.php?p=40714995&postcount=5378

@RipperDrone

This comment has been minimized.

Copy link

RipperDrone commented Dec 28, 2018

Sounds so logical - why has nobody thought about this before? Non-linear systems are hard to be managed by low parameter controllers, so why not transform system behavior to good ol' linear first? Love it, kudos to @markusgritsch for this idea and also to @joelucid for introducing it in BF as a commitment without any 'not invented here' notion... 😀👍

Show resolved Hide resolved src/main/common/maths.c Outdated
@joelucid

This comment has been minimized.

Copy link
Contributor Author

joelucid commented Dec 28, 2018

@RipperDrone, I actually have thought about this before, but always thought that the non linearity of the rpm to throttle curve would sufficiently compensate. So shame on me for not being thorough with this.

And @markusgritsch really deserves a lot of credit! Consider: SilverWare doesn't have logging, so all of this is based on keen observation of flight behavior.

@McGiverGim

This comment has been minimized.

Copy link
Member

McGiverGim commented Dec 28, 2018

What is the idea about how to calculate the linear value? Is a test and error to see what suits best? Or there is one that can work for major part of setups?

@RipperDrone

This comment has been minimized.

Copy link

RipperDrone commented Dec 28, 2018

@joelucid now that we are talking: Once there will be ESC telemetry 'realtime' rpm available, how will this match up with the non linearities dealt with here? You can then easily factor in the real rpm instead of non linear throttle2rpm relationship...?

@joelucid

This comment has been minimized.

Copy link
Contributor Author

joelucid commented Dec 28, 2018

@McGiverGim, @markusgritsch recommends 50. It's partly a question of your idle setting since that causes the curve to be less quadratic: https://www.rcgroups.com/forums/showpost.php?p=40770933&postcount=5418.

I used 50 and it worked well. 70 started to unduly amplify low throttle noise, so too much given my idle of 6%.

@joelucid

This comment has been minimized.

Copy link
Contributor Author

joelucid commented Dec 28, 2018

@RipperDrone:

@joelucid now that we are talking: Once there will be ESC telemetry 'realtime' rpm available, how will this match up with the non linearities dealt with here? You can then easily factor in the real rpm instead of non linear throttle2rpm relationship...?

Yeah, that occurred to me, too. I want to build PIDs for RPM on the FC. Then the mixer could perfectly compensate by feeding the sqrt of desired thrust to the motor pids.

@joelucid

This comment has been minimized.

Copy link
Contributor Author

joelucid commented Dec 28, 2018

One drawback is that yaw is actually based on d rpm / d t which I addressed with integrated yaw. So at some point integrated yaw needs to be compensated for this compensation. I'll probably leave that for when the motor PIDs have arrived.

@butterSnake

This comment has been minimized.

Copy link

butterSnake commented Dec 28, 2018

another drawback is you have other stuff to finish before starting down another path @joelucid ;D

@joelucid

This comment has been minimized.

Copy link
Contributor Author

joelucid commented Dec 28, 2018

@butterSnake,

😃 - well at least this will make dterm_boost much simpler I hope. Which is yet another ball in the air.

@butterSnake

This comment has been minimized.

Copy link

butterSnake commented Dec 28, 2018

I'm flying it already @joelucid ;)

Show resolved Hide resolved src/main/flight/mixer.c Outdated
@markusgritsch

This comment has been minimized.

Copy link

markusgritsch commented Dec 28, 2018

I used 50 and it worked well. 70 started to unduly amplify low throttle noise, so too much given my idle of 6%.

@joelucid With an idle offset of 6%, an idealized quadratic motor curve would yield a linearization value of a bit over 60, see https://www.desmos.com/calculator/jjbqept6os

Here you can drag the blue slider knob of the o (idle offset) parameter to fit the offset you use and watch how the ideal quadratic curve shifts. So for your offset anything above 60 will definitely over compensate, and some smaller value will probably be the correct compensation due to non-linear motor_mix/RPM relationship.

So I think 50 is a good default value.

Show resolved Hide resolved src/main/common/maths.c Outdated
Show resolved Hide resolved src/main/flight/mixer.c Outdated
Show resolved Hide resolved src/main/flight/mixer.c Outdated
Show resolved Hide resolved src/main/interface/settings.c Outdated
Show resolved Hide resolved src/main/flight/mixer.c Outdated
Show resolved Hide resolved src/main/common/maths.c Outdated
@ledvinap
Copy link
Contributor

ledvinap left a comment

Some minor notes for consideration

Show resolved Hide resolved src/main/flight/mixer.c Outdated
Show resolved Hide resolved src/main/flight/mixer.c Outdated
Show resolved Hide resolved src/main/flight/mixer.c Outdated
Show resolved Hide resolved src/main/interface/settings.c Outdated
@mikeller
Copy link
Member

mikeller left a comment

Looking mostly good. This is blowing out flash space on more F3 boards already - I am wondering if we should make this F4 only?

Show resolved Hide resolved src/main/common/maths.c Outdated
Show resolved Hide resolved src/main/flight/mixer.c Outdated
Show resolved Hide resolved src/main/flight/pid.c Outdated
@joelucid

This comment has been minimized.

Copy link
Contributor Author

joelucid commented Dec 29, 2018

@mikeller this feature is pretty minimal in code size and might turn out to be pretty important. Appreciate the f3 code size issues. Is there something we can cut instead? I know it's difficult. Maybe another spin of the "performance edition".

@mikeller mikeller added this to the 4.0 milestone Dec 30, 2018

@joelucid joelucid force-pushed the joelucid:linear_pids branch 2 times, most recently from 8aa03e5 to 9cba857 Dec 30, 2018

@joelucid joelucid force-pushed the joelucid:linear_pids branch from 17bc706 to ad253c1 Jan 3, 2019

@joelucid

This comment has been minimized.

Copy link
Contributor Author

joelucid commented Jan 3, 2019

Rebased and squashed

@etracer65

This comment has been minimized.

Copy link
Member

etracer65 commented Jan 7, 2019

@joelucid I lost track of the discussion, but I recall some discussions in Slack about some unexplained (low frequency I think) throttle oscillations when testing this. Has the cause been understood?

Show resolved Hide resolved src/main/flight/pid.c
Show resolved Hide resolved src/main/flight/pid.c Outdated
Show resolved Hide resolved src/main/flight/pid.c
Show resolved Hide resolved src/main/target/common_pre.h
@mikeller

This comment has been minimized.

Copy link
Member

mikeller commented Jan 8, 2019

@etracer65: Have your concerns with this been addressed?

@mikeller mikeller merged commit a136f0b into betaflight:master Jan 8, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.