PID vs Normal loops

[Adam Y.]

Originally Posted by EricS-Team180

You can try a Bang-bang_control as an alternative. It works like a thermostat on a furnace. What you pick as a controller really, really, really (did I say really?) depends on the application. In 2006, we used a bang-bang controller on the turret of our poof ball shooter for 2 competitions. Then we switched it to a PID for Nationals. In the end, they both worked, but we got better shooting accuracy with the PID.

Eric

Sorry. I was a little vague on the question. I meant has anyone tried other feedback loops. Theoretically anything is possible.

[Qbranch]

Originally Posted by Adam Y.

Sorry. I was a little vague on the question. I meant has anyone tried other feedback loops. Theoretically anything is possible.

After the 2007 season ended, I had a heart->heart with PID on our '07 chassis. I was sick and tired of watching PID "get from one place to another as fast as possible". Call me a control freak, but I want to be able to call the shots for not only where something sits, but also how fast things accelerate, what the top run speed is, as well as how fast they decelerate.

Hence, an augmentation of the PID controller. I don't have the code with me, but let me explain to you how it works. First, I tuned up a really nice, very touchy PID. Touchy being it really goes nuts with a little bit of error (in the order of an inch). Then, here's where things get cool: I feed a stream of interim coordinates into the PID to generate trapezoidal velocity control while still arriving at the target. This is very useful for extreme long travels with large masses (like driving a robot from its starting position and arriving (smoothly) at the rack).

I think you can kind of understand how this works: if a stream of coordinates is fed into a pid loop at a constant interval (each time the PID updates, in my case @100Hz) you feed a new, short range target into the PID. These targets are no more than a fraction of an inch apart in my case, remember they get fed in at a rate of 100Hz. That occurs during the acceleration phase: these ramps can be precalculated or calculated at acceleration execution time... all you need is a little 1/2*A*T^2 action. When acceleration or deceleration is complete, you switch to a constant position delta so as to keep the speed constant. Deceleration functions the same way as acceleration.

Now, you may be thinking "hey, that's best suited for autonomous runs where distances can be pre calculated. what if my final target changes dynamically?"

Well, I'm working on that one. My goal is to have a fully mathematical (no precalculation) formula set that handles acceleration, constant run speed, and deceleration. v2 that I'm working on now isn't ready yet, but it operates on a summation of three PID loops, one watches acceleration, one watches velocity, and one watches position simultaneously. To decide which should be listened to, a selection structure is set up which lets whatever PID routine has the lowest power output solution access to the motor. Everything but one part works beautifully in simulation: i'm still trying to figure out how to hande deceleration without the interim-position method explained above.

Next on the list to be explored is state-space control which allows feedback from multiple sensors to factor into a single control loop and plant (motor or otherwise) action... but I might have to wait to have my curiosity satisfied till i'm in college a little while... I'm not sure how to do a Laplace Transform...

Questions? Post!

-q

[Tom Bottiglieri]

Originally Posted by Qbranch

I'm not sure how to do a Laplace Transform...

You may not, but Google does

[Salik Syed]

A cool idea would be to "learn" the (approximately) optimum PID constants over time...
You can simulate your robot arm pretty easily using a set of equations characterizing the mass distribution, and motor torques.

Next create several test goal and end states within reachable bounds of the system (a state would be angle + angular momentum for each arm segment)

Do a search through the set of all PID combinations to find the best one.To test optimality, simply use the PID constants and run them on your simulation, use a metric for how good the performance is (power usage, time to reach goal etc..) . It shouldn't take more than a few minutes on a modern computer. (of course you don't want to try every possible combination since it's infinte, but discretize the selection based on how large or small the term is probably going to end up being)

If you need help programming this feel free to post, it isn't half as complicated as it seems. In fact maybe I will make something that does this over winter break lol.

[Qbranch]

Or you could just use a rough-tuning method that's been used for decades: Ziegler-Nichols

Or, you could do something kind of like Salik said: If you have a decent physical sense about you, or just happen to have a physics book, a four-function calculator (or pad and paper) and rougly figure out what kind of numbers you need for the constants. For instance: set your P term based on how fast you want something to move for a maximum speed, with the biggest motion you might give it... aka if you are doing just a positional servo (for an arm or something) the biggest move you make you'll want to output the maximum control output for the motor... so you'd multiply (or divide) by whatever number you need to get your error to around 127 (or whatever max plant value you might have). D terms can be done similarly, but I terms are usually more of a gut feel if your doing "Tune by Feel" though they can be calculated relatively easily as well if you factor in your cycle times and characterists of your motor and the load it's moving.

See previous post for more on augmentations of PID.

-q

[Guy Davidson]

Q,

The idea of using the preferred response to tune a PID is interesting. Once I'm done getting other components of our coprocessor up and running I will probably try that as a tuning method and see how well it works.

Your idea detailed last page is also very interesting. I think it's important to decide what your goals are - lowest time to reach the target or reaching it smmothly. I don't know yet which will seem more important for this year's challenge, but until now I am tempted to say that the time it takes to go from position a to position b might be more important than the smoothness, particularly for a servo or autonomous position control. However, I am wondering about human controlled velocity PID - would you rather have a slight overshoot as you attempt to reach the target velocity, or would you prefer to reach it slower but more smoothly, perhaps taking a bit longer to get there.

The idea of having a fully mathematical computation of to handle constant accceleration and constant velocity is interesting. Again, I might mess around with that a bit before or during the build season, depending on how much time I end up having. If I do, I'll be sure to let you know what results I get. I'm also currently reading about Laplace transforms and State-Space controls (amongst other control systems) to see maybe there's a reasonably easy alternative to PID.

[Qbranch]

Originally Posted by sumadin

Your idea detailed last page is also very interesting. I think it's important to decide what your goals are - lowest time to reach the target or reaching it smmothly. I don't know yet which will seem more important for this year's challenge, but until now I am tempted to say that the time it takes to go from position a to position b might be more important than the smoothness, particularly for a servo or autonomous position control. However, I am wondering about human controlled velocity PID - would you rather have a slight overshoot as you attempt to reach the target velocity, or would you prefer to reach it slower but more smoothly, perhaps taking a bit longer to get there.

Really the need for smooth control came around last year when our (mostly) greenhorn drivetrain team decided to use two wheel drive on the robot, but still put two CIMs on each side. Definitely not a recipie for success. To keep from getting totally disoriented, I had to have controllable acceleration, or else the robot would spin its tires and I'd end up feet short of where I was supposed to be. Not to mention, analog encoders can sometimes get a little messed up when you go around slamming motors into reverse all of a sudden when there's a large mass coupled to them... talk about a gigantic EM field.

On the human control side... has anyone actually implemented this with success in competition? I've found that drivers always say it 'feels wierd'... so usualy what ends up happening is I write code so that if the robot has neutral control input for a set period of time, a servo kicks in to hold it in that spot. Has anyone successfully implemented this?

Wow I can't wait to see what the challenge is... I really hope it's more exciting that the game last year...

-q

[Guy Davidson]

Our current drive train design is a six-wheel with a lowered middle wheel, so I hope smoothness of acceleration/deceleration isn't a factor, as I'd like to tune the position PID to get to the postition as fast as possible, and the velocity one similarly to hit the maximal velocity as fast as possible. Assuming I can tune both correctly, I'll probably use the position PID to control the velocity one in autonomous - the position loop will send a value to the velocity loop which will compute the correct PID value. Hopefully this will work, but I first have to get our coprocessor working and then the encoders. If it does work though, it should work pretty well.

That's a very good question. We've never tried to implement velocity control, so I have no idea how comfortable our driver will be with it. I guess that if it is tuned well and he is not comfortable with it, I will just use ut for autonomous, and maybe use it situationally. To hold a position possibly like you suggest. Any other interesting ideas?

I can't wait either. I can't wait to see the challenge. Hopefully they also made autonomous as big as it deserves