There have been a lot of threads recently about TBH and PID, but I haven’t seen many people make comparisons between them. I was wondering what other people’s thoughts are on which one is better.

I know TBH is theoretically much easier to tune than PID because there are less constants you have to set, but is PID more optimal, assuming both controllers are tuned properly?

Also, is there anyone who has played around with using filters to smooth out encoder readings and would be willing to discuss their results?

Well let’s start off with the fact that TBH is PID. In its most simple form it is just an I loop.

I would suggest reading all of James’ posts about TBH as he seemed to prefer it over full PID.

Next the question about what is optimal. It depends on what you value and define optimal. In terms of fire rate that keeps shooting full field (or any distance) nothing will compare with a bang bang controller. In terms of reproducing the same shot I can’t imagine that PID vs TBH have a huge difference as at the end I is doing all the work on PID anyway. Just because you slammed the word optimal on there it doesn’t mean that you asked anything more than “what’s better” without saying what better means.

Now filtering. At that high of a speed I am not sure how important filtering is. Are you having a lot of issue with the speed calculation of a flywheel? If so than it might be an interesting thing to discuss.

I suppose TBH is basically I, except for how it handles overshoots.

That is a good point you brought up about what optimal means. I suppose the best definition of “optimal” in this situation would be which one ultimately scores more points, which becomes a combination of accuracy and speed. Am I correct in assuming PID would be the best at regulating flywheel speed and therefore accuracy, while bang-bang would be the best at getting the flywheels back up to speed after a shot, with TBH being more of a balance between the two?

As far as filtering goes, I read a while back on this reveal that they were using an exponentially weighted moving average to calculate velocity, and was wondering if anyone else had looked into filtering.

I personally haven’t had much time to play around with the code yet, as my team is still very much involved with the design of our robot. I just barely had time to implement TBH before our first competition a week ago, and haven’t even had much time to explore the tuning for it.

Jury is still out. My initial tests showed that with the specific flywheel I was playing with TBH worked successfully. However, I was not shooting balls with the experiment, just running the flywheel. My current thought is that we may need two control loops, one that stabilizes the nominal speed of the flywheel and adjusts as the battery voltage drops. A second that compensates for a ball being fired, this may just consist of momentary (0.5 second, something like that) compensation for loss of energy. The trick here is to detect the ball being fired, there are a couple of ways I’m think of doing this but do not have enough data to discuss yet on the forum.

Alternatively if we find out that the built in PID loop that ROBOTC has is successful then all this is moot.

I think that this could be easily done using a limit switch positioned in a place where it would be triggered the moment before the ball hits the flywheel. Code wise you can just detect when the rpm drops significantly below the desired speed.

ok too thing, could one not detect when a ball was fired based on a sudden drop in Velocity with out a change in target velocity

second, what in heck is a bang-bang controller and why hasn’t some one thought of a more descriptive/technical sounding name for it

Lol, I’ve been thinking the same thing :stuck_out_tongue:

what is the benefit of this type of average, as opposed to something like just averaging the velocities from the last 5 time steps, also, how exactly would this be done.

I have done some google searches, but most of what I have been able to find relates to finance and I haven’t been able to figure out how to convert that to velocity calculations

link to paper on Bang-Bang

Yes to both.

well, now I understand why the bang bang controller does not have a fancy name, it is not a fancy control system, does it work well?

Yaaaaa. It is the classic technique people use when they have access to a sensor but have no experience with control loops. If its behind me go backwards full speed. If its in front of me go forward full speed. This creates a very noticeable sound.

When I say bang bang has the highest fire rate I am more or less saying
motor =127 will recover to any speed faster than anything else. The spacing between the balls would have to be perfect or the wheel would accelerate to being too fast. This is obviously why we use control algorithms, to approach our goal in a smooth controlled precise motion.

If your robot knew exactly how long it had until the next ball entered the shooter it could come up with different approaches to get to the correct speed.
infinite time = traditional PID /TBH
some reasonable about of time = full speed to accelerate and then traditional to stabilize which is really just an incredibly aggressively tuned kP
almost 0 time = full speed/bang bang

We had a sensor to detect a shot (with sonar) and apply recovery power for a set time. It worked, but we set it aside to try TBH, which seemed to be the better option because I thought the speed control already adjusted for battery voltage variation. Seems I am wrong in this thinking?

Color sensor…

But then I relized it’s basically a sonar as stated by tech

A velocity controller doesn’t take into account battery voltage. In its simplest form, you could say that having a velocity controller is like setting the flywheel power on a robot that is not effected by battery voltage and variations in the construction/motors. Well thats in an ideal world at least.

The way in which a velocity controller finds this speed is in its name. It checks the velocity and essentially increases or decreases the speed based on the difference between the current velocity and the target velocity (error). For instance a straight P controller takes the error and multiplies it by a constant to get a value to send to the motors.

So to answer your question. No. A TBH loop or (insert velocity controller here) will not be effected by the battery voltage (above a certain threshold). I think what jpearman was referring to is one loop to stabilize the speed at what you set it to, and another loop (tuned a bit more aggressively) to adjust for the loss of power when you shoot a ball. It would bring the speed back up or down to about where it needs to be.

I think jpearman was talking about just having this after a shot for a small amount of time. I would imagine you could also program this in that the second more aggressive loop has a deadzone around the target velocity in which it is not ‘active’ and the first loop works to stabilize the speed. Although i’m not sure how well this would work with TBH.

It’s like you want to reset the loop when you detect a sudden drop in velocity to give more power to the motors at that instant (with a nice corresponding current spike).

You could add a predicted next velocity based upon the last and current velocity and kick up the gain accordingly when you see it is slowing down on you. That would be adding a forward model to the TBH routine.

Here’s a nice read that has some more information we can look at. Disturbance Rejection Characteristics seems awfully close to the effect a ball has on the flywheel velocity…

PIV routine of PID in velocity control is the discussion here. So back to PID but in the frequency domain.

I’m going to have to read up on this one…

@EvolvingJon , I think we’re on the same page. What I meant to say was that speed control removes the need for battery voltage detection and adjustment. At first I wasn’t following, but if I read this right the take away from @jpearman 's post is that the overshoot of TBH/PID - when trying to max out recovery speed-- is a limitation. So a less aggressive closed loop control (again PID/TBH) and a more aggressive open loop control (1/2 second full gas) would combine to be the quickest overall system with least overshoot.

And don’t suddenly switch to negative values to the motor while the RPM’s are high either. It does not like that very much apparently. :expressionless: