Help with TBH Tuning

With every iteration of our flywheel design, it seems like we become less and less able to properly tune our TBH algorithm. Is there something we’re missing?

Our new flywheel uses 2 four-inch wheels covered with rubber bands on each side and speed motors.

One side of the flywheel seems to have much less friction (or the other side has a lot more friction), so one side will run at 60 power and the other at 90 power, and they rotate at about the same RPM.

However, when we try to tune the TBH, the balls don’t just miss, they go too short, too long, left and right. It’s frustrating because it seems like no matter how we tinker with the gain for each side, the end result is still essentially the same.

We’ve been graphing our data in Google Sheets; here’s an example graph of shooting about 1 ball/sec (as fast as our intake will allow right now)

(We have many more graphs if you are interested in seeing some more.)

The TBH code:
Robot code
TBH controller

We’ve been getting about 20% accuracy. The gains were .000275 for the left side and 0.000200 for the right side (the difference is supposed to account for the differences in friction for each side).

What would be the best steps to take to troubleshoot what’s happening and to continue searching for the right gain? It seemed like on our first flywheel, tuning the TBH algorithm was much easier. Is it possible that we are overthinking this?

Thanks in advance for your help!

One thing our team did was to mechanically tie the left and right flywheels together using gears and then controlling the velocity using one IME and slaving all the motors (we have 4 on our launcher). Since the flywheels are locked together, they will always be turning at the same speed relative to one another. Doing this improved our shot accuracy and also simplified tuning the code.

We’re considering that, but we don’t have much time before our next competition, so that’s not feasible for right now. However, today we replaced a motor (it was probably bad) and reverted back to the TBH code we used at our first competition, and it seems like it’s working better. I haven’t had time to investigate what might have been causing issues with the new TBH code we had.

I powered the flywheel motors off of a Y harness which allows you to save cortex ports and simplify programming.
You definitely need to fix the the slower side.

It appears you have a swing of 50 rpms at any given moment, which must be the reason you are experiencing over and under shooting. We recently (tonight) got our flywheel motors to be able to stay within about 6-7 rpms of the target velocity. We used this post as a guideline to do that:

Velocity Calculation Traps

Edit: I just looked at your graph again and now I’m not sure if the top or bottom lines represent RPM’s. Perhaps you are not experience a 50 rpm swing?

After seeing how much reverting to our old code seems to have worked, I think I will take it slowly as I add things back. Before, the balls would go up to 2 feet apart in one run; now they all end up in about the same spot.

I haven’t graphed any of our more recent runs just yet, but I might re-implement the velocity calculation with @jpearman 's tips in mind.

One question though - for shooting driver loads across the field, do you (personally) use a lower setpoint and shoot at a faster rate (taking advantage of overcorrection, essentially), or do you let the flywheel correct fully after each shot? What about for closer shots when out in the field?

How many motors do you use on your flywheel?

2 speed motors on each side

Nice ! What do you have your current gain values as just out of interest ?

We used .0006 for long shots, .0002975 for close shots (a little in front of the low goal bar), and .00085 to shoot rapidly from the red tile to the blue goal (purple shooting) and vice versa for skills. The purple shooting worked really well, but our drivetrain would allow balls to get stuck under it, which wasted time during robot skills. We actually tied for the highest robot skills score at our competition yesterday but got 2nd place because of the tie breaker factors (sigh…).

Yeah, so we replaced a motor and both sides started running at the same speed. Bad motors are annoying.

No, you were correct in thinking that the top two lines were RPM readings. The lower ones are the motor powers.

Also, those reading were from an older RPM controller that doesn’t take jpearman’s advice. The older controller would also slowly rise from 50 motor power to 70 (like at 2 second intervals, for both sides even though that was actually changing the RPM) regardless of the gain. When I went back to my newer TBH controller* that’s a struct and uses IEM timestamps (thanks @jpearman), the weird motor power rises were gone.

Our flywheels were mediocre in general at our last competition. I’m beginning to think that TBH a bit simple for our needs and can’t handle the fast recovery times (with minimal overshoot) that we’re looking for. Based on my research, it sounds like a PI controller will be a good next step that is feasible. We tried PID back in December, but it was our first time and we actually implemented it incorrectly. That sort of scared me away, but now my expectations for TBH are probably too high (when we first used it, we were coming from what were essentially motor powers). If you know any good forum posts here about PI(D) or tuning it, I’d appreciate that.

*So if you look at that link, you’ll see that the file name includes “with Averaging RPM.” It does, but we have that disabled because it just seemed to slow down response time with minimal benefit. There’s still an


variable that lets you adjust the aggressiveness of the exponential weighted average. Also, this TBH implementation requires a controller task for each independently moving flywheel side in the main robot code - example in line 99 of this file - and a function to control the motors for each side.