tbh tuning

Hey guys/gals
How would I tune a TBH loop?

I’ll assume that you are using something similar to jpearman’s velocity control.

The variable is “gain”. It is at 0.00025 by default.

First, I would double the number. It will now be 0.0005. Now run the flywheel and shoot some balls, while writing velocity into the debug stream. Then, use an Excel (or whatever you prefer) spreadsheet to make a graph. See if the speed up is overcompensating. If it is, lower the gain by 0.0001, and raise it if it can gain more. Keep tuning. I would go for 0.000X0 or 0.000X5 because that is relatively quick to get to.

If you are referring to JPearmans implementation of TBH (or similar) you can adjust the gain.

I haven’t tuned any TBH loops myself, but I have tuned some PID ones. What you basically have to do is experiment with the constants/gains and see what works best. It’s kind of a guess and check process.

Hello, guy who brought Take Back Half to this forum in the middle of this thread. (I unfortunately did a poor job of explaining it so JPearman came to the rescue.)

Take Back Half is nice because there is very little tuning to do. PID requires a lot of fancy math, or a lot of trial and error to get it tuned right because there are three gains.

Take Back Half only has one gain, and for flywheels it’s almost universally around 10^-5. (Vex flywheel launchers have less torque than the larger FRC robots I’ve used it on so this value will need change a tad bit.)

Once you do start tuning however, it essentially takes 5 minutes to get the value right, and your flywheel should be golden.

How would you recommend going about tuning it? Is it just trial and error? In your experience, how well can one actually tune a TBH loop? In other words, what is the average variance one should expect on a flywheel with a properly tuned TBH loop?

Trial and error works well. The gain is never more than an order of magnitude off, and I’ve generally had it working rather well after a dozen trials.

I presume by variance you mean how far the flywheel’s velocity deviates from your goal velocity and how often. JPearman’s thread on the matter reflects the results I’ve generally gotten.

Thanks. Our team just finished coding/building a launcher, but haven’t had time to tune it yet, so hopefully I’ll be able to successfully tune it tomorrow.

thanks guys for all your help. :slight_smile:

is this the only way to tune a flywheel? We were unable to figure out the proper gain for our flywheel (but now that you say this, we will give this method of tuning a try!) but i’m curious how other teams went about it? what is the point of doubling the original gain? with the original gain our robot continually overcompensates as we shoot. (i figured it overcompensates just because of our fast fire rate and it couldn’t handle that quickly of changing variables? but even if we slow down the fire rate it still overcompensates)

No, this is not the only way. Another way is to keep adding (or subtracting) just a bit every time.
I double the original gain first out of habit. I feel like it’s less tedious than adding .00005 each step.

interesting. I’m kinda a noob at this so how would you write the velocity in the debug stream and analyze it from there. Also what about the predicted drive.

Our tbh was mostly just tuning the gain to prevent the motor inputs from oscillating too much. Watch your debug windows to see if you constantly seem to be overcompensating or undercompensating for your flywheel and once you have a good gain, then adjust the target velocity that you want.

I tried working with tbh but found it to be inconsistent for a flywheel. I feel that this a tiny bit because the encoders don’t have enough resolution, but mostly because the program assumes that it is just as easy to go from velocity 69->70 as it is to go from 70->71 which means that the robot is constantly undercompensating and then slowly overcompensating.

I don’t think its impossible, but I had a really hard time with it. If you want to see what I came up with, it’s on github.

You would just paste something like this into your code (after calculating the velocity).

writeDebugStream("velocity: %d", velocity);

then open up your debug stream (one of the debugger windows) and copy and paste what comes up (when running the flywheel) into a program like excel. Use Find & replace to remove "Velocity: " from your text and graph the data.

JPearman explained predicted drive as “Another way of looking at this number is that this would be the motor control value if there were no other variables, battery voltage was constant, friction did not change etc. remember, I work with a 0 to 1.0 scale, a predicted drive of 0.55 means a motor control value of 70 (0.55 x 127).” on the original TBH thread.