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

EmuBoost2.0 (should perhaps have a different name) #670

Open
wants to merge 37 commits into
base: master
Choose a base branch
from

Conversation

Quick-Flash
Copy link
Member

This code is best described as a form of smart error based gain scheduling. Essentially this code does 2 things, boost/shrink Dterm and boost Pterm. The logic here is simple. There are 2 ways to improve responsiveness on a PID controller. 1 is to use more Pterm, and another is to use less Dterm. Pterm is what drives your movement and Dterm is what slows your movement (at least dterm from gyro measurement, i've worked around this for dterm from error). So what if we want the best of both worlds when it comes to improving responsiveness while not gaining the problems associated with high Pterm and a low Dterm??? Well the logic here is simple, when we want/need more response boost the Pterm and shrink the Dterm. Shrinking the Dterm gives one major advantage over just increasing Pterm. Dterm is a source of noise, and shrinking the Dterm will help alleviate some of that noise and clean up our motors during moves.

How and when does it do this? Well the code looks at the change in error (the derivative of error) and the total error. The current error and the change in error are scaled between 1 and -1 before being multiplied together. This means that error has to be increasing or decreasing rapidly and error has to somewhat large for the full effect to occur.

Here is the math for how the Pterm is boosted and how the Dterm is boosted/shrunk along with some pseudo code. scaledError is our scaled total error and our scaled change in error.
pterm = pterm + pterm * (scaledError) * emuboost2; dterm = dterm * (1 - scaledError);
Pterm is only boosted when Dterm is shrunk, and Dterm can be both boosted or shrunk. In situations where the error is growing, Dterm will be shrunk. In situations where error is shrinking the Dterm is boosted to help deal with overshoot.

What the settings do and how to tune this.

  • emuboost2: This is the percentage of how much Pterm is allowed to be boosted. A value of 100 means that 100% more Pterm can be added, or at max value your P gains will be twice as much. A value of 1 would add 1% to your P gains at max. A value of 0 disables EmuBoost2.
  • emuboost2_filter: This is the cutoff frequency for the boosting/shrinking effect.
  • emuboost2_cutoff: Once the error is greater than the emuboost2_cutoff the error scaler is at its max value.
  • emuboost2_expo: This creates a curve to go from no boosting to full boosting. A value of 0 is linear and a value of 100 is the most expo possible.

How to tune this stuff: EmuBoost2 is relatively easy to tune. If you want more responsiveness increase the EmuBoost2 value, if it feels to responsive decrease this value. EmuBoost2_filter is a bit tougher to tune. A low filter cutoff will lead to a smoother boost, but at the downside of more delay in the boosting. Lower this filter if you have excess noise. EmuBoost2_cutoff essentially places how hard you need a move to be before you get much effect from EmuBoost2. Small cutoff values (10) means the effect is active almost all the time and a high cutoff (150+) will mean its mainly active during flips and rolls. EmuBoost2_expo is essentially how aggressively you want this effect to come into play. A high expo value will mean that small movements near center stick do not really feel "boosted" as much as a lower value. For expo play with small vs high values and see what feels best. If your cutoff is already quite small, then the effect of changing your expo will be less pronounced. It may be worthwhile to play with different values for your cutoff and expo and tune both together for the feel you desire.

Quick-Flash and others added 24 commits February 24, 2021 16:13
This filter is far more precise than the previous filter was. I've currently set this up with 36 bins (so accuracy is (max-min)/36 which for defaults is, 12.5hz, the old filter had a bin size of 16 which would have given an accuracy of 28.125hz, so this is over double as accurate.) This can also track up to 5 peaks and place 5 notch filters. It is also nicer on the cpu than the older version was, so all around really good. Using this filter + abg i was easily able to raise my gyro lpf filters to 300hz with dterm filters at around 150hz. I'm really excited to see what you all think about this filter :), P.S. all credit goes to @KarateBrot for coding this into betaflight, I may want to update this later to have dynamic widths and dynamic on the number of notches it uses, but so far, hey its awesome. Probably going to stay like this for 0.4.0. Only the defaults need testing right now.
Adding EmuBoost2 adds a really nice way to boost stick feel
as error is decreasing dterm will be boosted, while error is increasing dterm will be shrunk. The amount dterm is boosted or shrunk depends on how quickly error is increasing/decreasing. The faster it is changing the more we will boost/shrink d.  As error transitions from growing to shrinking the dterm will go from being shrunk, back to normal strength, and then to boosted, then back to normal strength. Gain scheduling FTW :)
Changing sharpness in the osd to increment by 1 for Andrey
This reverts commit e21315b.
…ost2"

This reverts commit dcef34e, reversing
changes made to 3fa078c.
@Quick-Flash
Copy link
Member Author

@nerdCopter this should be tested

@nerdCopter
Copy link
Member

when i tested this on 2021-11-14, i had weird logs as such, so i did not test further. at the time i set boost v2 on top of boost v1 existing settings; i may have tested wrongly.

image

image
image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
experimental in-testing-needs-testing needs testing before merge consideration
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants