Jaguar Speed Control Only Reaches 50% of Setpoint

[Mr. Lim]

We've "successfully" gotten our CAN Jaguars working under speed control.

We've tuned the PID constants to get a system that seems to react nicely, and is stable.

The only problem, our system only reaches 50% of the setpoint speed.

Anyone else notice this?

When we setX() at 60 RPM, getSpeed() shows only 30 RPM is attained.

I'm pretty sure I know why this is happening, but I'd like to confirm others are seeing this too.

[kamocat]

There's two possible causes:
Either you're going as fast as the motor can, or you need to include some Integral into your tuning.

If you're providing full power, then the Jaguar LED will be solid green (or solid Red if you're in reverse)

[Mr. Lim]

Can you confirm that a P-Only control loop will only get you half-way to the setpoint?

I have some concerns that the speed control mode on the Jags is missing some important functionality.

If the P term doesn't accumulate in velocity control, it will go to 0 as it gets closer to the setpoint. This usually results in a P-only loop appearing stable, but only hitting about 50% of the setpoint.

A workaround is to have an I term that will get you all the way to the setpoint. However, I've heard elsewhere that the I term goes to zero as soon as the setpoint is attained, so as to prevent overshoot/wind-up. I can't confirm this 100%, but based on some initial testing I'm led to believe this is the case, as an I-only loop seems to hit the setpoint, then cuts out, only to accelerate up to the setpoint and cut out again.

Right now, we're using a P-only loop, setting the setpoint twice as high as we really want it. It's a sloppy workaround, but the best we've come across so far.

[RyanCahoon]

I've not used CAN on the Jags before, much less the PID control, but is there a configuration that has to be set for number of clicks/rev on the encoders?

[kamocat]

Can you confirm that a P-Only control loop will only get you half-way to the setpoint?

I have some concerns that the speed control mode on the Jags is missing some important functionality.

If the P term doesn't accumulate in velocity control, it will go to 0 as it gets closer to the setpoint. This usually results in a P-only loop appearing stable, but only hitting about 50% of the setpoint.

A workaround is to have an I term that will get you all the way to the setpoint. However, I've heard elsewhere that the I term goes to zero as soon as the setpoint is attained, so as to prevent overshoot/wind-up. I can't confirm this 100%, but based on some initial testing I'm led to believe this is the case, as an I-only loop seems to hit the setpoint, then cuts out, only to accelerate up to the setpoint and cut out again.

Right now, we're using a P-only loop, setting the setpoint twice as high as we really want it. It's a sloppy workaround, but the best we've come across so far.
Yes, without an I coefficient, you can't expect to ever reach the setpoint; you get partway there, and then don't go any further.

I haven't tried an I-only loop.

If you're intent on using P only, what happens when you double your P coefficient? Is that the point where it starts to oscillate?

[wmarshall]

I'm in the process of tuning the Speed PID loop on my team's Jaguars, and I'm having a similar issue. Using BDC-COMM to set the PID values, I can increase P until I get to just under my setpoint, but when the loop actually hits the setpoint, the Jags start freaking out and flipping the motor direction very quickly, before faulting. This has made it nigh impossible to get anywhere, as the method I'm using to tune the loop (Wikipedia (http://en.wikipedia.org/wiki/PID_controller#Manual_tuning)) needs the loop to hit the setpoint.

At a stable P(no sad gear grinding) the output is much lower than the setpoint, and as P is increased to hit the setpoint, the loop gets more prone to the gear grinding. I've yet to even begin to play with the I value, as I fear it may lead to more instability.

[EricVanWyk]

By definition, it is impossible to stably hit your set point with a P only control loop. You must have an I term.

A PID loop is calculated with respect to the error, or difference between what you want and what you have. As you approach the setpoint, the error approaches 0. Therefore, the output of the P term approaches 0. Therefore, with a P only loop you will always undershoot your target. You can jack the P gain up to reduce the undershoot, but it will never be zero. If you jack it up too high, noise will dominate and the whole thing will go unstable.

Keep the P where you have it (hitting half your goal) and add a bit of I.

[Mr. Lim]

I'm in the process of tuning the Speed PID loop on my team's Jaguars, and I'm having a similar issue. Using BDC-COMM to set the PID values, I can increase P until I get to just under my setpoint, but when the loop actually hits the setpoint, the Jags start freaking out and flipping the motor direction very quickly, before faulting. This has made it nigh impossible to get anywhere, as the method I'm using to tune the loop (Wikipedia (http://en.wikipedia.org/wiki/PID_controller#Manual_tuning)) needs the loop to hit the setpoint.

At a stable P(no sad gear grinding) the output is much lower than the setpoint, and as P is increased to hit the setpoint, the loop gets more prone to the gear grinding. I've yet to even begin to play with the I value, as I fear it may lead to more instability.

My workaround has been to tune the P-only loop to react as best as can be to exactly half the setpoint.

I can confirm that when you crank the P to actually try and hit the setpoint, bad things happen. It'll get you there, only to slam in reverse, and oscillate around the setpoint...

I'll get a chance to add I term to see if it will actually get me to the setpoint in a stable manner.

I'm curious if anyone know exactly how the Jaguars deal with Integral wind-up. Whether it reduces the I-term to 0 once the setpoint is hit, or does it cap the accumulated I value to some kind of ceiling?

Either way, I think we'll get a chance to find out tomorrow!

[techhelpbb]

I'm curious if anyone know exactly how the Jaguars deal with Integral wind-up. Whether it reduces the I-term to 0 once the setpoint is hit, or does it cap the accumulated I value to some kind of ceiling?


I'm a mentor for wmarshall's team and I have a request into TI for actual documentation on the transfer function, LaPlace or block diagram for the FIRST firmware Jaguar PID functions.

It's more curious to me that the P loop doesn't always reach the point of instability eventually for any given value of P.
In theory, a small P should move more slowly toward the set point but still get there eventually.
This does not seem to be the case and that leads me to believe this is not a parallel PID algorithm.

If I get anywhere I'll let you all know.

Not only do we not know how they handle integral wind up (if they handle it at all), we don't know if they have a deadzone or a D filter.

Also I'm not a fan of tuning using the Ziegler Nichols method the way I suspect we're going to get told to use it.
I'd not like to end up with marginal tuning.

[Joe Ross]

I'm a mentor for wmarshall's team and I have a request into TI for actual documentation on the transfer function, LaPlace or block diagram for the FIRST firmware Jaguar PID functions.

...

Not only do we not know how they handle integral wind up (if they handle it at all), we don't know if they have a deadzone or a D filter.

The jaguar source code is available for download. http://www.luminarymicro.com/products/rdk-bdc24.html

[Ether]

Whether it reduces the I-term to 0 once the setpoint is hit

I've never heard of such a thing. It would seem to defeat the whole purpose of the integral controller.

[techhelpbb]

The jaguar source code is available for download. http://www.luminarymicro.com/products/rdk-bdc24.html

It is my understanding, though I could be wrong, that the FIRST firmware differs from the commercial firmware.

I know that the FIRST firmware operates in trusted mode where as I'm fairly sure the commercial firmware does not.

Also I've noted that TI has mentioned to other people using the 'Jaguar' for non-FRC purpose they shouldn't use the FIRST firmware as the FIRST firmware has 'safety features' for FIRST (basically).

This leads me to wonder if I'd be wasting my time reverse engineering the source code. Though frankly, in a more commercial sense, I can't imagine being told to reverse engineer the source code for a commercial controller just to get a block diagram of the transfer function or the proper tuning procedure.

Is it just me or does this link not work:
"Stellaris® RDK-BDC24 Brushed DC Motor Control Module User's Manual"

[techhelpbb]

I've never heard of such a thing. It would seem to defeat the whole purpose of the integral controller.




I suspect what they are hoping to communicate would be to eliminate noise induced run away. If you get noise that interferes with your return function then over a duration then...for example...you might end up 'winding up' the I in such a way that even though you've limited it...it's still way too high and because of it getting to high over and over from disturbance and noise it may never come down and the result might be perceived as erratic movement.

If you can 'reset' the I (not necessarily make the I constant 0), and do it when the I is perceived to have 'wound up' too often, then you can effectively prevent yourself from having to reset the entire PID loop to eliminate what appears to be erratic function.

As an example...
http://community.mybb.com/thread-78886.html

[Mr. Lim]

I've never heard of such a thing. It would seem to defeat the whole purpose of the integral controller.




The crux of this issue is that the PID implementation seems to be more suited to position control, rather than speed control.

Killing the I term when the setpoint has been reached is commonly employed in position control - particularly in systems where there is a lot of resistance as you slowly reach your desired position. When you are finally reach the setpoint, your P is already 0, and it's in your best interests to 0 the I term to prevent overshoot. The I has already done its job to get to the setpoint, to overcome any resistance encountered on the way there.

Regardless, I can't 100% confirm what the I term behaviour is until later this afternoon, but I'm hoping the I-term is capped, rather than 0'ed.

[techhelpbb]

I've never heard of such a thing. It would seem
to defeat the whole purpose of the integral controller.


(I posted this last night, but it claimed it needed approval so I'll try again).

I suspect what they are hoping to communicate would be to eliminate
noise induced run away. If you get noise that interferes with your
return function then over a duration then...for example...you might
end up 'winding up' the I in such a way that even though you've
limited it...it's still way too high and because of it getting too high
over and over from disturbance and noise it may never come down and
the result might be perceived as erratic movement.

If you can 'reset' the I (not necessarily make the I constant 0), and
do it when the I is perceived to have 'wound up' too often, then you
can effectively prevent yourself from having to reset the entire PID
loop to eliminate what appears to be erratic function.

As an example...
http://community.mybb.com/thread-78886.html

When the goal is to achieve a set point of a fixed speed, then I can see how this helps when the prime concern is the change in set point.

As noted above, when the prime concern is achieving the set point position it makes sense when the loading is prone to bind at the last second. Though, the kind of binding matters. If for example the mechanism is prone to binding and then runaway (the motors are overloaded and then break free) then you're probably too close to the limits of the ideal, serial or parallel algorithms for the stable D to be achieved anyway in which case now you have a special case.

[dyanoshak]

It is my understanding, though I could be wrong, that the FIRST firmware differs from the commercial firmware.

I know that the FIRST firmware operates in trusted mode where as I'm fairly sure the commercial firmware does not.

Also I've noted that TI has mentioned to other people using the 'Jaguar' for non-FRC purpose they shouldn't use the FIRST firmware as the FIRST firmware has 'safety features' for FIRST (basically).

FIRST firmware versions implement safety features that allow the cRIO to disable the Jaguars when it needs to. All the operation code (PID, H-Bridge, etc.) is the same as the non-FIRST release and is available for download off of www.ti.com/rdk-bdc24.


Is it just me or does this link not work:
"Stellaris® RDK-BDC24 Brushed DC Motor Control Module User's Manual"

The broken links are happening because we are slowly transitioning to TI web. You can find the getting started guides and manuals on the Jaguar Microsite either at www.luminarymicro.com/jaguar or www.ti.com/jaguar. You can also find the most up-to-date product pages at www.ti.com/mdl-bdc24 and www.ti.com/rdk-bdc24.

Note the two different pages, 'mdl' and 'rdk'. MDL is the module version (same exact firmware, but sold as an individual unit) and RDK is the Reference Design Kit that comes with more development tools to develop with Jaguar. That is why the source code is listed on the RDK page and not the MDL page.

[Ether]

Killing the I term when the setpoint has been reached is commonly employed in position control - particularly in systems where there is a lot of resistance as you slowly reach your desired position. When you are finally reach the setpoint, your P is already 0, and it's in your best interests to 0 the I term

OK, I can see doing that if trying to position a plant with no load, or with a friction load that exceeds other load forces.

But if you are are trying to hold position against an external load, and you zero the I term when you reach the target, then the position will change and the controller will have to re-seek the target.

[techhelpbb]

OK, I can see doing that if trying to position a plant with no load, or with a friction load that exceeds other load forces.

But if you are are trying to hold position against an external load, and you zero the I term when you reach the target, then the position will change and the controller will have to re-seek the target.


Might not matter if there's frequent changes in the set point.

[Ether]

Might not matter if there's frequent changes in the set point.

I suppose if they're frequent enough, you don't need a PID at all :-)

[techhelpbb]

I suppose if they're frequent enough, you don't need a PID at all :-)




Depends. It might be a cascaded system :ahh:

[techhelpbb]

FIRST firmware versions implement safety features that allow the cRIO to disable the Jaguars when it needs to. All the operation code (PID, H-Bridge, etc.) is the same as the non-FIRST release and is available for download off of www.ti.com/rdk-bdc24.



The broken links are happening because we are slowly transitioning to TI web. You can find the getting started guides and manuals on the Jaguar Microsite either at www.luminarymicro.com/jaguar or www.ti.com/jaguar. You can also find the most up-to-date product pages at www.ti.com/mdl-bdc24 and www.ti.com/rdk-bdc24.

Note the two different pages, 'mdl' and 'rdk'. MDL is the module version (same exact firmware, but sold as an individual unit) and RDK is the Reference Design Kit that comes with more development tools to develop with Jaguar. That is why the source code is listed on the RDK page and not the MDL page.

Just hold on a second here.

Are you telling me I have to pay you $200+ to get the source code so I can analyze it and determine what should be a readily available piece of information to the people that programed this PID function?

::ouch::

Please tell me that's not what you're telling me.

What is the difference between the links you just provided and this:
http://www.luminarymicro.com/products/rdk-bdc24.html

Because on that previously provided link the RDK CD is available for free download.

[dyanoshak]

Just hold on a second here.

Are you telling me I have to pay you $200+ to get the source code so I can analyze it and determine what should be a readily available piece of information to the people that programed this PID function?

::ouch::

Please tell me that's not what you're telling me.

Not at all. You click the link on the page that says "Reference design kit CD (http://focus.ti.com/docs/toolsw/folders/print/rdk-bdc24-cd.html)" and download the CD that comes with the kit, for free.

You can also click on the Software Updates link.

[techhelpbb]

Not at all. You click the link on the page that says "Reference design kit CD (http://focus.ti.com/docs/toolsw/folders/print/rdk-bdc24-cd.html)" and download the CD that comes with the kit, for free.

You can also click on the Software Updates link.

Okay, I'm downloading the link Joe Ross provided and the link from the TI website now and I'll check them against each other and then tear the code apart.

I suspect I'm going to find that the ideal PID algorithm was implemented as I've seen with other TI PID loops in the past.

[techhelpbb]

From the RDK (pid.c):

// By using a derivitive gain of zero, this reduces to a simple PI controller.
// By using a integral and derivitive gain of zero, it reduces to an even
// simpler P controller. The response requirements of the process being
// controlled determines the terms required to achieve that level of response.
// Controlling motors can typically be done with a simple PI controller.

Yeah okay. Now in reality when you set the I and D to zero whatever those units are supposed to be, not only does it not reach the set point even with a small value, but when you make the P value too large it overshoots and becomes unstable.

So no...this comment is not correct, we can confirm this as our system is one CIM in a gear box driving a tire with an optical encoder on the output of the gear box and the tire is suspended in mid air.

We should be able to reach the desired set point like this if this comment from the Jaguar source code is to be believed. Even if we become unstable at the set point, the actual Jaguar doesn't actually get there it stops short of that goal by a not so trivial amount.

Normally P loops do experience offset from the disturbances that weren't factored into reaching the set point, but in this case what is the source of the disturbance? The gear box maybe? Course I'll have to dig more, but maybe the Jaguar thinks the motor response is linear and it's really not, so it when it tries to compensate it misses but can't continue to reduce the value as it now see's zero in the P gain.

P is gain so it's essentially without a unit (at least if I believe the way the source code names the variables).
I allows you to change the I gain, but it doesn't tell you the repeat time.
D allows you to change the D gain, but it doesn't tell you the preact time or rate time.

So this brings me back to the question of actual Jaguar PID characteristics...
The deadtime or deadzone isn't just a product of code.
The I and D are dependent on the speed at with the PID loop can execute.

[drakesword]

I have noticed that with position control that PID works correctly. When using speed on the other hand it isn't quite where it should be. Maybe the PID in the speed loop isnt looking at speed properly . . . meh.

Our solution was to tune the loop to be "quiet" as in no chatter on the drive train at low and high speeds. In the robot code once output stabilized we calculated the error and just increased our set-point by the same percentage.

Eventually we got the output we wanted . . . eventually.

[techhelpbb]

Course I suppose we can get quick and dirty by taking P up to instability (with I and D at 0), then backing off 30%. Then taking I up to instability (with D at 0 and that 30% reduced value of P) and backing off 30%. Then finally taking D to instability and backing off 30% if we even need a D.

[techhelpbb]

I have noticed that with position control that PID works correctly. When using speed on the other hand it isn't quite where it should be. Maybe the PID in the speed loop isnt looking at speed properly . . . meh.

Our solution was to tune the loop to be "quiet" as in no chatter on the drive train at low and high speeds. In the robot code once output stabilized we calculated the error and just increased our set-point by the same percentage.

Eventually we got the output we wanted . . . eventually.

Assuming you've only implemented P, I is effectively 'automatic reset'.

What you're doing by shifting the set point is a 'manual reset'.

With just 2 speeds it's not so bad, but if you have a lot of speeds you'd have a heck of a time making the changes because...if I'm right...the algorithm doesn't account for the way the motors actually respond to the change in output. It basically thinks the response is more linear than it really is. I expect this to a small extent...but to this extent it makes me wonder if the feedback is really correct...especially in the case of the older Jaguar hardware.

However, that is what the I does. It's an 'automatic reset'. Basically the I recognizes that when the loop repeats it didn't get to it's desired output the last time(s) and compensates by 'pushing' the output. The amount of 'pushing' is a combination of the gain (which they apparently let you set) and is scaled by time (repetition rate). However, I don't see as they specify the repetition rate for this code and usually it's something that is measured, not just programmed.

The I has a draw back in the sense that if the I 'pushes' too hard it overshoots the set point. In a drive train, that sort of thing might happen because you had a momentary impact and so the I climbed rapidly but then...suddenly...the resistance is lost and now the I is too high. So I is usually capped. As mentioned earlier in cases like that where the disturbance (the impact) happens often you might find that 'reseting' the I is a good idea because if you let I climb to a maximum it'll stay there for a bit till the last few operations even it out. If you don't reset the I in situations were repeated disturbances of noise (especially at a fundamental frequency) you'll get into a situation where the control appear to become erratic or less responsive until the loop figures out that the integration needs to reset.

[AustinSchuh]

Yeah okay. Now in reality when you set the I and D to zero whatever those units are supposed to be, not only does it not reach the set point even with a small value, but when you make the P value too large it overshoots and becomes unstable.


Physics dictates that this is true.

Here are the differential equations governing a motor, if you ignore the effect of the inductance in the motor (a pretty good assumption for most things.) I'll stick with differential equations to make it easier to follow rather than using the laplace transform.

V - Km * d/dt theta = R I
Kt I = torque

Lets connect that motor to a rotating mass, with a moment of inertia of J for simplicity.

torque = J * d^2/dt^2 theta


Lets then connect it up to a P controller.

V = P * (goal - d/dt theta)

Plug that into the system of equations above, and simplify a bunch.

P * goal - R / Kt * J * d^2/dt^2 theta = d/dt theta * (P + Km)

At steady state, d^2/dt^2 theta = 0, so this simplifies to

goal * P / (P + Km) = d/dt theta

This says that you will only get to the goal if you crank the P constant up to infinity, which isn't practical. When you break the assumption that you are working in continuous time with a perfect system, it goes unstable. So, the loop is behaving exactly like I would expect it to.

A similar analysis can be used to show that you absolutely need the I term in order to get 0 steady state error. I can go through that math if it isn't clear. Treat the I term when doing a velocity loop as if it were the P term when you tune a position loop, and the P term as though it were the D term when tuning a position loop.

[techhelpbb]

Physics dictates that this is true.

Here are the differential equations governing a motor, if you ignore the effect of the inductance in the motor (a pretty good assumption for most things.) I'll stick with differential equations to make it easier to follow rather than using the laplace transform.

V - Km * d/dt theta = R I
Kt I = torque

Lets connect that motor to a rotating mass, with a moment of inertia of J for simplicity.

torque = J * d^2/dt^2 theta


Lets then connect it up to a P controller.

V = P * (goal - d/dt theta)

Plug that into the system of equations above, and simplify a bunch.

P * goal - R / Kt * J * d^2/dt^2 theta = d/dt theta * (P + Km)

At steady state, d^2/dt^2 theta = 0, so this simplifies to

goal * P / (P + Km) = d/dt theta

This says that you will only get to the goal if you crank the P constant up to infinity, which isn't practical. When you break the assumption that you are working in continuous time with a perfect system, it goes unstable. So, the loop is behaving exactly like I would expect it to.

A similar analysis can be used to show that you absolutely need the I term in order to get 0 steady state error. I can go through that math if it isn't clear. Treat the I term when doing a velocity loop as if it were the P term when you tune a position loop, and the P term as though it were the D term when tuning a position loop.

This is correct in a strictly academic sense physics prevents perfectly achieving the set point with just the P. The P loop should not get exactly to the goal and should be offset usually below the goal short of disturbance with a motor.

However, why such a huge error?

I mean if you've got people with 50% error is the feedback that far off the actual measurements?

At least our system (one CIM, one Jaguar, one gear box, one tire, encoder on the output) is sitting at 10-15% error (when suspended in the air) at least on one version of the Jaguar as long as we keep the P gain low enough to avoid instability and that's with I and D set to 0.

I wonder if they are tuning for speed under load on the ground. That would do it because the noise and disruptions would increase.

[AustinSchuh]

I'm getting lazy, so I'm going to switch to the laplace domain in this following explanation. If you or anyone has trouble following, I'll clarify by request. After a while working with differential equations, I get tired of typing d/dt... (Without going into the details, you can pretty much replace s with d/dt, and 1/s with an integral)

This is correct in a strictly academic sense physics prevents perfectly achieving the set point with just the P. The P loop should not get exactly to the goal and should be offset usually below the goal short of disturbance.

However, why such a huge error?


For our robot last year, the actual constants we have successfully used are as follows.

num_motors = 4
m = 150 / 2.20462262
r = 0.0508
R = 12.0 / 133.0 / num_motors / 0.85 + 0.024 + .003
Kt = 0.0182326082
Km = (12.0 - R * 2.7) / (5310.0 / 60.0 * 2.0 * math.pi)
G = 40.0 / 12.0 * 48.0 / 15.0 * 22.0 / 15.0

The transfer function for the robot driving strait controlled by a voltage is


V = Km * G / r * s * x + R * r / (Kt * G) * s^2 * x


Let's let V = (ref - s * x) * Kp

The transfer function from ref to s * x (ie, if you ask for a velocity, what do you actually get) is then

s * x / ref = Kp/(Km * G / r + Kp + R * r / (Kt * G) * s)

At steady state, (ie s=0), this evaluates to

Kp / (Km * G / r + Kp)

This is different from what you get if you try to do position control with V = (ref - x) * Kp

x / ref = Kp/(s Km * G / r + Kp + R * r / (Kt * G) * s^2)

At steady state (ignoring friction, and s=0), this says that for any Kp, the transfer function will be 1. This means that ideally, a P loop with position control will seek to the goal perfectly. Now we know that not to be true if there is a bit of coulomb friction in the system, but that is distinctly different from using a P controller on the velocity loop. On the ideal velocity loop, you only get 0 steady state error if Kp -> infinity.


I mean if you've got people with 50% error is the feedback that far off the actual measurements?


To me, that sounds like Mr Lin has set Kp = Km * G / r, which gives you a steady state error of 50%. That would evaluate to about 6.6 for our 2010 robot in low gear. Assuming velocity is measured in meters/sec, and the jaguar takes volts as it's input, which is probably not the case for the supplied control loop. This doesn't surprise me at all. A P controller driving the robot at a velocity will start to exhibit discrete time oscillation effects if the P constant is too high. (I can show this if you don't believe me)



At least our system is sitting at 10-15% error at least on one version of the Jaguar as long as we keep the P gain low enough to avoid instability and that's with I and D set to 0.

I wonder if they are tuning under load on the ground. That would do it.

It sounds like your P constant is higher than Mr Lin's. Since the Jaguar is implementing a discrete time PID controller, if you crank up the P constant too high, it will go unstable. This is due to the discrete time poles leaving the unit circle, even though the laplace poles are in the left half plane.

I'm going to take the position that if someone is using just a P controller to try to get the robot to drive at a velocity, they are doing it wrong. They should first start with the I term, and leave the rest of them 0. Would you every try just using the D term in a PID loop when trying to go to position? You'd say that the person was doing it wrong if they did that.

Lets show this. Let V = (ref - s * x) * 1/s * Ki, ie a simple I controller.

This gives

sx / ref = Ki / (Ki + Km * G / r * s + R * r / Kt * G * s^2)

Evaluating the transfer function at steady state says that for all Ki, the transfer function is 1. This means that Ki will get you to the desired velocity. That is a good thing. Too much Ki will give you overshoot, but that's the same thing as a position P controller.

If you pattern match, this I controller for velocity control has the same form as the P controller when doing position control. This says that the I term in the Jaguar's velocity loop acts like the P term in the Jaguar's position loop. A similar analysis will show that the P term in the Jaguar's velocity loop acts like the D term in the Jaguar's position loop.

[techhelpbb]

I'm going to take the position that if someone is using just a P controller to try to get the robot to drive at a velocity, they are doing it wrong. They should first start with the I term, and leave the rest of them 0. Would you every try just using the D term in a PID loop when trying to go to position? You'd say that the person was doing it wrong if they did that.


Not really stating that the P loop alone should drive the robot. Merely looking for an optimal tuning procedure based on the Jaguar's implementation of PID.

If you read the available information, without wandering into this topic, I suspect you'd try tuning the P loop alone first as a student as well (I can prove that easily because that's exactly what 2 students on our team did independently after trying to work out the presented information within the limits of their math skills).

Hence the reason I seek clarification and the others seek to compare notes. I recognize you feel that this is burdensome math to some extent, but the issue is not whether or not I understand it (or believe you as you put it), it's how anyone expects teams to tune these PID loops with the available information unless they have someone much more familiar with the subject to refer to. To put it bluntly, show me where the section with suggestions on tuning the parameters for the Jaguar PID loop is in their documentation.

I'll confirm with the students tonight, but I'm fairly sure they didn't use a P gain higher than 7 before instability occurred.
I'm pretty sure that we didn't have 50% error at that point. I could be wrong, but we'll surely find out.

UPDATED: They were never able to exceed 6 with one or 6.3 with another for the P gain before instability. Around those values the error was 10%-15% for us.

Of course the point of this discussion about the Jaguars and how they work was to wring out issues like this:

Assuming velocity is measured in meters/sec, and the jaguar takes volts as it's input, which is probably not the case for the supplied control loop.


Obviously the discussion itself hinges on finer details like you wrote above. As tuning into the marginal is effected by the actual feedback and the inconsistencies that it may create.

[Mr. Lim]

Okay, last post on the topic form me, as I think we've found a solution, although not ideal.

The workaround is to tune the P-term to attain 50% of the setpoint, then bump up the I to get you the rest of the way. Add D to smooth out oscillations and overshoot, if needed (it wasn't needed for us). After an evening of tuning, we have something workable, but not great. I is slow to react to get you from 50% of the setpoint to the setpoint, and it makes the controls feel delayed and sluggish. Because it is slow, there is also a tendency to wind-up and overshoot. Increase the I, the system reacts a bit faster, but ends up overshooting more. Bottom line, the I is responsible for making up too much error.

As an aside, I'm happy to report that the I term is capped - we felt a bit of wind-up and overshoot, but it was obviously capped, as we had no real runaways. It doesn't seem to get reset, as we were running pretty smoothly around the setpoint once we finished our tuning.

Now, if a TI / Luminary Micro person is reading this:

I think the REAL solution is that a simple linear feed-forward (ff) feature should be added, where (Kff * setpoint) is added directly to the PID's output.

The rationale is that the linear feed-forward can be roughly tuned to get us close to the desired speed, open loop. Then the PID is responsible for making up the difference between the feed-forward open loop result, and the set-point.

If you feel really enterprising, you can give us non-linear feed-forward too, and allow us to specify an exponential response.

This would make me very happy...

[drakesword]

Assuming you've only implemented P, I is effectively 'automatic reset'.

What you're doing by shifting the set point is a 'manual reset'.

With just 2 speeds it's not so bad, but if you have a lot of speeds you'd have a heck of a time making the changes because...if I'm right...the algorithm doesn't account for the way the motors actually respond to the change in output. It basically thinks the response is more linear than it really is. I expect this to a small extent...but to this extent it makes me wonder if the feedback is really correct...especially in the case of the older Jaguar hardware.

However, that is what the I does. It's an 'automatic reset'. Basically the I recognizes that when the loop repeats it didn't get to it's desired output the last time(s) and compensates by 'pushing' the output. The amount of 'pushing' is a combination of the gain (which they apparently let you set) and is scaled by time (repetition rate). However, I don't see as they specify the repetition rate for this code and usually it's something that is measured, not just programmed.

The I has a draw back in the sense that if the I 'pushes' too hard it overshoots the set point. In a drive train, that sort of thing might happen because you had a momentary impact and so the I climbed rapidly but then...suddenly...the resistance is lost and now the I is too high. So I is usually capped. As mentioned earlier in cases like that where the disturbance (the impact) happens often you might find that 'reseting' the I is a good idea because if you let I climb to a maximum it'll stay there for a bit till the last few operations even it out. If you don't reset the I in situations were repeated disturbances of noise (especially at a fundamental frequency) you'll get into a situation where the control appear to become erratic or less responsive until the loop figures out that the integration needs to reset.

Not to undermine what you said but we are using a PD only loop.

When I say eventually I mean within a second or two.

Motor output isn't really relevant because we are moving our set point until we hit our speed. the change in speed to the change in set point is linear enough for our drive system. We push both joysticks forward and the robot drive straight.

[AustinSchuh]

Okay, last post on the topic form me, as I think we've found a solution, although not ideal.

The workaround is to tune the P-term to attain 50% of the setpoint, then bump up the I to get you the rest of the way. Add D to smooth out oscillations and overshoot, if needed (it wasn't needed for us). After an evening of tuning, we have something workable, but not great. I is slow to react to get you from 50% of the setpoint to the setpoint, and it makes the controls feel delayed and sluggish. Because it is slow, there is also a tendency to wind-up and overshoot. Increase the I, the system reacts a bit faster, but ends up overshooting more. Bottom line, the I is responsible for making up too much error.


If you are still interested in working on this, here's another way to tune the velocity loop, and some plots to illustrate what you should be seeing.

Start with Kp = 0, and Ki a very small number. Increase it until you get a reasonable amount of oscillation. (Ki.jpg, first plot)

Once you have something with a bit of oscillation, increase Kp until you get no oscillation. Kp will act like you would expect Kd to act, i.e. it will reduce overshoot. (Kp.jpg, second plot)

The constants I used are in the plots, but will very likely be different than ones you will see in practice due to unit differences. If anyone wants the python I used to generate this to try stuff out, let me know.

[techhelpbb]

Courtesy of TI in regards to my questions...

http://www.eetimes.com/ContentEETimes/Documents/Embedded.com/2000/f-wescot.pdf

Once again this suggests you start by tuning P first specifically with regards to a motor and gear box example.

I'm not saying that either way is without merit, mind you, just passing along what I was given.

[Ether]

Courtesy of TI in regards to my questions...

http://www.eetimes.com/ContentEETimes/Documents/Embedded.com/2000/f-wescot.pdf

Once again this suggests you start by tuning P first specifically with regards to a motor and gear box example.

The difference is, the example given is controlling the position of the output, not the speed.

[techhelpbb]

The difference is, the example given is controlling the position of the output, not the speed.




Yes but...when you build a product with a PID loop...

And you know that loop can target a set point of speed or position.

You'd think when you ask the manufacture's specifications for their PID loop like the I repeats per minute or the D rate in minutes. You'd get that.

Not a response with an article that further ignores the available modes.

The difference is not lost on me. I'm merely passing it along, in the hopes that in the future less people will rip their hair out trying to figure out why this isn't better documented most importantly not the PID loop itself which is the subject of whole branches of knowledge, but the Jaguar implementation specifically.

[techhelpbb]

http://e2e.ti.com/support/microcontrollers/stellaris_arm_cortex-m3_microcontroller/f/471/p/46325/163005.aspx

I don't suppose he ever got anywhere with this?

[Ether]

Yes but...when you build a product with a PID loop...

And you know that loop can target a set point of speed or position.

You'd think when you ask the manufacture's specifications for their PID loop like the I repeats per minute or the D rate in minutes. You'd get that.

Not a response with an article that further ignores the available modes.

OK, valid point.

[techhelpbb]

The real problems I have with the Ziegles Nichols method (http://en.wikipedia.org/wiki/Ziegler%E2%80%93Nichols_method) (the closed loop version...not all the versions like these (http://www.jashaw.com/tutorial/pid6.html))and any 'educated guess closed loop' tuning methods are:

1. You need the system and you must push the system close to malfunction or worse to the point of malfunction.

2. In a very real way you are ignoring the capability of the actual controller, because of course, you must 'dance with the devil' in an actual system and try to avoid ripping it to pieces and, as is likely in this case, you probably aren't monitoring the open loop performance of the PID loop controller or have the data collection to see the actual results.

Now surely, the logic, well known theory and math for PID loops applies. Surely if you try enough settings, you'll find one that'll be tuned well enough to 'work'. However, as I stated before the problem with that theory is that you can't always predict the disturbances the PID loop might encounter.

For example: How long and how many times do you try to test your gain for a specific system? If you don't do it long enough, perhaps the chain on the output with a master link that rubs doesn't get to the point where it rubs. So maybe you find a nice tune...till that happens. Maybe your values don't leave the room for the PID loop to compensate and then...bad things happen.

I'd really like to get parameters and measurements for the I repeats per minute and the D rate in minutes. I'd really hope that I can get them from TI, or they can help work out a good way to test them.

Because, we can all quote sections out of books until we are blue in the face, but the controller is only capable of so much open loop and I'd like to know where those limits are.

Perhaps I'm missing something, and there's a way to retrieve these I and D parameters without performing an actual measurement?

(As other people are reading this and it's a public forum, I'll give this as an example to follow along:
http://www.jashaw.com/pid/tutorial/pid3.html)

[dyanoshak]

Taken directly from the Jaguar source code:

//
// Compute the new control value.
//
llOutput = (((long long)psState->lPGain * (long long)lError) +
((long long)psState->lIGain *
(long long)psState->lIntegrator) +
((long long)psState->lDGain *
(long long)(lError - psState->lPrevError)));

Which translates into: P*Error + I*Integrator + D*(Error - Previous Error)

Error is passed in to the PIDUpdate() function and is calculated as your Target Speed - Current Speed, Target Position - Current Position, and so on.

Integrator is calculated every time PIDUpdate is called:


//
// Add the error to the integrator.
//
psState->lIntegrator += lError;
New Integrator = Current Integrator + Error

Previous Error is the previously stored error.

The PIDUpdate is called every time ControllerSpeedMode() is called (or any closed loop mode).


//************************************************** ***************************
//
// This function handles the periodic processing for speed control mode.
//
//************************************************** ***************************
static void
ControllerSpeedMode(void)
{
[Omitted Code]

//
// Run the PID controller, with the output being the output voltage
// that should be driven to the motor.
//
lTemp = PIDUpdate(&g_sSpeedPID, lTemp) / 256;

[Omitted Code]

//
// Send the new output voltage to the H-bridge.
//
HBridgeVoltageSet(g_lVoltage);
}

Which is called by the Controller Interrupt Handler which is triggered every 1ms by the H-Bridge.

//************************************************** ***************************
//
// This function is called to handle the timer interrupt from the PWM module,
// which generates the 1 ms system timing.
//
//************************************************** ***************************
void
ControllerIntHandler(void)
{
[Omitted Code]
//
// Call the appropriate control method based on the control mode
// that is currently enabled.
//
if(HWREGBITW(&g_ulFlags, FLAG_VCOMP_MODE))
{
ControllerVCompMode();
}
else if(HWREGBITW(&g_ulFlags, FLAG_CURRENT_MODE))
{
ControllerCurrentMode();
}
else if(HWREGBITW(&g_ulFlags, FLAG_SPEED_MODE))
{
ControllerSpeedMode();
}
else if(HWREGBITW(&g_ulFlags, FLAG_POSITION_MODE))
{
ControllerPositionMode();
}
else
{
ControllerVoltageMode();
}
[Omitted Code]
}
Note: I left out code so that this wouldn't be too long.

In each mode the error is in terms of the mode you're in (speed, current, position, voltage). When the PID is updated, the output is converted to a voltage command to the H-Bridge.

[techhelpbb]

Taken directly from the Jaguar source code:
...


Reading the code is not my problem.

The code can only actually execute so fast.

PID loop performance is partially dictated by how fast the controller can respond...and it's not a function of your CPU clock (at least not entirely).

The entire reason we want to use the PID loop in the Jaguar is because last year a talented student and myself implemented a complete special case PID loop in Java on the cRIO and eventually it became monumentally clear the cRIO's software payload makes something like this problematic *PARTICULARLY* because of massive code execution speed issues. I want to avoid having to ever try to do something like this during a build season again. Not only because the actual control theory takes up volumes and I have to cut corners explaining it, but because these students are under immense external pressure and it's not fair to toss them under this bus without the mathematics to cover for it.

You can't get the parameters I want like this...unless you can assure me...how many steps of integration and derivative you'll make and how long each iteration called every...apparently 1ms...takes.

The question I'm basically asking is how fast can the Jaguar actually integrate in response to a change in the input and how fast can it do the derivative. Not whether or not the code can actually do it.

If you tune using a closed loop, you can only tune within the context of the limits of instability you observe or happen to measure. If you tune using the open loop performance as key criteria you can tune so that the system will be able to close the loop as best it can because you're also working within the parameters of the actual controller, not merely some information you gathered once upon a time in a galaxy far...far...away that 'seems to work'.

Please read this:
http://www.jashaw.com/pid/tutorial/pid3.html

Specifically:
"Units used to set integral or reset" and the section that follows if immediately about the derivative.

I would like to find out or be told how to measure:
I repeats per minute and the D rate in minutes for the Jaguar PID loop.

[Ether]

...The code can only actually execute so fast.

...PID loop performance is partially dictated by how fast the controller can respond

...You can't get the parameters I want like this...unless you can assure me...how many steps of integration and derivative you'll make and how long each iteration called every...apparently 1ms...takes.

...The question I'm basically asking is how fast can the Jaguar actually integrate in response to a change in the input and how fast can it do the derivative.


The iteration rate is 1000Hz.

Assume that there's one input, one calculation, and one change in the output every iteration*.

Assume the input, calculation, and output can occur in any order and can take the entire 1ms.

Design around that. It ought to be plenty fast for anything FRC related.


*
[edit]
to be clearer:
- "one input" meaning "one reading of the necessary inputs for the computation"
- "one calculation" meaning one crunching of the inputs (including P,I,&D etc) to generate a new output
- "one output" meaning the new calculated output is returned by the function
[edit]

[Alan Anderson]

The code can only actually execute so fast.

It can actually execute faster than it is regulated to execute in the Jaguar.

You can't get the parameters I want like this...unless you can assure me...how many steps of integration and derivative you'll make and how long each iteration called every...apparently 1ms...takes.

It makes integration and derivative steps for as long as it's running. It does one iteration every millisecond.

The question I'm basically asking is how fast can the Jaguar actually integrate in response to a change in the input and how fast can it do the derivative. Not whether or not the code can actually do it.

I'm not grasping the distinction you seem to be making. For the purposes of the control algorithm, the code is the Jaguar.

I would like to find out or be told how to measure:
I repeats per minute and the D rate in minutes for the Jaguar PID loop.

It does one step every millisecond. Is that not sufficient information?

[techhelpbb]

It doesn't matter that it makes one change per 1ms (even if that's accurate).

It matters how long it takes for it run the gambit full range for it's output open loop. That matters because it dictates how wide the range of control the Jaguar actually has.

Even if you want to argue that it's related to it being about to make 1,000 changes in 1 second. That doesn't actually tell me how far it can drive it's output before it knows it's must back off.

Hence you can't get this from the code. Unless of course you make some wild assumptions or they have it in a comment I haven't seen.

For example:

Perhaps my output system (generically speaking and I'm limiting this to the guts of the Jaguar) is capable of producing 1,000 discrete states.

I can change that state 1,000 times a second.

Even then....the I repeats per minute parameters...actually is controlled by how far the integration can drive the output in the working band.

There's a working example of what I'm getting at, at the link I pointed to above. These parameter effectively characterizes the 'envelope' of the output of the controller, both in regards to how long it will take to achieve the maximum number of steps of the integrations it can achieve (output characteristics being a part of that and because it's discrete interval of 1ms) and then repeats and how long it can drive the derivative for. Not just how often it can do the process steps that happen to form a PID loop. How far can it actually do (how many 1ms steps) it before it's outside of it's actually available working parameters for output and it knows that so it starts all over...or repeats.

I mean it can obviously do this 1,000 times a second forever (or at least until someone turns it off or the sun goes cold). However, at some point there's a limit to where the integration or derivative can go and that limit is dictated by the output, the PID implementation or both...not just the system it's attached to (outside the Jaguar).

If you know this...and it can be measured...you can put yourself within the scope of the available control of the Jaguar more accurately...then say guessing because it 'doesn't appear' to be on fire yet.

[Ether]

It matters how long it takes for it run the gambit full range for it's output open loop. That matters because it dictates how wide the range of control the Jaguar actually has.

Are you asking how quickly the Jag hardware can change from 100% reverse duty cycle to 100% forward duty cycle? If not, please clarify what you are asking.

Even if you want to argue that it's related to it being about to make 1,000 changes in 1 second. That doesn't actually tell me how far it can drive it's output before it knows it's must back off.

It can drive its output from 100% duty cycle of reverse supply voltage to 100% duty cycle of forward supply voltage.

Hence you can't get this from the code.

The hardware schematic is freely available, is that what you're looking for?


For example:

Perhaps my output system (generically speaking and I'm limiting this to the guts of the Jaguar) is capable of producing 1,000 discrete states.

I can change that state 1,000 times a second.

Even then....the I repeats per minute parameters...actually is controlled by how far the integration can drive the output in the working band.

Are you asking what is the resolution of the Jag's output? i.e. What is the smallest step it can take in the range -100% to +100% ?


I mean it can obviously do this 1,000 times a second forever (or at least until someone turns it off or the sun goes nova). However, at some point there's a limit to where the integration or derivative can go and that limit is dictated by the output

The output is a Pulse-Width modulation of the supply voltage. The duty cycle (% "on" time) of the pulse can range from 0 to 100%, with either forward or reverse supply voltage. I do not know if there is a firmware limitation on how fast the hardware is allowed to change the duty cycle. Is that what you are asking??

[techhelpbb]

Are you asking how quickly the Jag hardware can change from 100% reverse duty cycle to 100% forward duty cycle? If not, please clarify what you are asking.

It can drive its output from 100% duty cycle of reverse supply voltage to 100% duty cycle of forward supply voltage.


No. Not at all. Might be a nice parameter to have measured tough it's not directly what I seek.


The hardware schematic is freely available, is that what you're looking for?


If you feed a schematic to PSpice will it give you actual real world measurements on production parts and consider tolerance? No.


Are you asking what is the resolution of the Jag's output? i.e. What is the smallest step it can take in the range -100% to +100% ?


Well at least if I knew the resolution of the Jaguar's output...the real resolution considering all the gate drive issues for the N channel FETs and their associated capacitive characteristics...and I knew the upper and lower saturation values with regards to the power supply and of course the upper and lower parameters of the PWM into the gate drive circuit, I could probably make an educated guess at what I want.


The output is a Pulse-Width modulation of the supply voltage. The duty cycle (% "on" time) of the pulse can range from 0 to 100%, with either forward or reverse supply voltage. I do not know if there is a firmware limitation on how fast the hardware is allowed to change the duty cycle. Is that what you are asking??


No. Frankly I'd be amazed if in the real Jaguar hardware they have the ability to drive the entire 0-100% PWM spectrum into their N channel gate drive and not have issues sooner or later all of which matter to the open loop measurements that will effect what I'm looking for.

[EricVanWyk]

I humbly ask that you re-read your posts. The effectiveness of your communication is impaired by the passion of your posts, and as such I am finding them rather unhelpful. I have great respect for the people who have responded in this thread, and they deserve your patience.

As others have stated, the Jaguar implements a very vanilla PID loop with an internal rate of 1kHz.

[techhelpbb]

The parameter I'm looking for is described here:

http://www.jashaw.com/pid/tutorial/pid3.html

Look for the part that starts with:
"Units used to set integral or reset"

The only way to get this with a schematic would be simulation that I doubt would be worth the effort once you consider all the spurious issues created by the high gate resistance, the high gate capacitance and a host of other issues you'd have to Monte Carlo to even try to simulate.

[Alan Anderson]

It doesn't matter that it makes one change per 1ms (even if that's accurate).

You said reading the code is not your problem. Whose problem is it? David explained it quite well. The PID update is done every millisecond. That is an accurate number.

It matters how long it takes for it run the gambit full range for it's output open loop. That matters because it dictates how wide the range of control the Jaguar actually has.

("run the gambit full range"? I'm not familiar with that phrase. I assume you mean force the output to its maximum -- or minimum -- value.)

It seems to me that the time it takes to go full scale depends on the error and on the gain parameters. The gains are fully under your control, but the error is an arbitrary number.

But the range of control isn't really related to time, is it? Full range is full range, whether it takes one millisecond, or a thousand, to reach it. I suspect there's a mismatch in terminology that's keeping us talking past one another.

Even if you want to argue that it's related to it being about to make 1,000 changes in 1 second. That doesn't actually tell me how far it can drive it's output before it knows it's must back off.

I'm not following you. It doesn't "back off" until the error term changes sign. Nothing in the controller can tell you when that will happen.

Hence you can't get this from the code. Unless of course you make some wild assumptions or they have it in a comment I haven't seen.

Of course you can't get it from the code; the error depends on the state of what you are controlling. The "assumptions" you must make are not wild; they are based on the response of what the controller is controlling.

There's clearly some idea which you think is obvious but which you are not succeeding in getting across to us. I still do not understand the distinction you apparently are maintaining between the implementation of the controller and the controller itself.

[techhelpbb]

I humbly ask that you re-read your posts. The effectiveness of your communication is impaired by the passion of your posts, and as such I am finding them rather unhelpful. I have great respect for the people who have responded in this thread, and they deserve your patience.

As others have stated, the Jaguar implements a very vanilla PID loop with an internal rate of 1kHz.

There is no disrespect in what I'm writing to these people. This is a complicated subject and I am merely trying to get to the meat of it.

I have not, at any point, clearly disputed that the Jaguar has a software timed iteration of the PID loop at 1ms intervals.

The parameter I seek is clearly defined at the link I presented several times. It is not an instantaneous parameter for a iteration around the Jaguar's loop.

The Jaguar will not continue to integrate forever in 1ms steps.
It can't.

[Alan Anderson]

The parameter I'm looking for is described here:

http://www.jashaw.com/pid/tutorial/pid3.html

Look for the part that starts with:
"Units used to set integral or reset"

It looks to me like you're asking for numbers that depend on the gain parameters. They are not an inherent feature of the PID controller implementation.

[Mr. Lim]

The Jaguar will not continue to integrate forever in 1ms steps.
It can't.

And it does not. Empirically, I can physically hold my robot back from hitting its setpoint for several seconds - or even minutes. The moment I release it, it does not runaway an appreciable amount. I think it's fair to ask what kind of integral cap/reset characteristics are implemented in the Jaguar, but you won't see me complain too much. I'm just happy that my robot isn't barrelling through a wall due to wind-up.

I promised my last post would be my last post, but this thread has gotten out of hand.

Regardless. We've gotten the PID working with some limitations. We've worked around them, and have an ADEQUATELY workable closed control loop. I would love to have more, but we are given six weeks for a reason...

and trust me, the best use of those 6 weeks is NOT spent on arguing the specifics of the Jag's I implementation.

Say your piece, then let's all move on.

[techhelpbb]

You said reading the code is not your problem. Whose problem is it? David explained it quite well. The PID update is done every millisecond. That is an accurate number.


It doesn't address my question.

If I told you my computer runs at 1GHz could you tell me how long it would take to crunch the first 20 digits of PI?

No you really couldn't. You couldn't because even if it's a RISC CPU and did one instruction per second, you don't know how many instructions it might take in whatever form the code was written to do the calculation or how long it would take to reach the display device whatever that is.



("run the gambit full range"? I'm not familiar with that phrase. I assume you mean force the output to its maximum -- or minimum -- value.)


For me, it means the maximum or minimum value in reality. Which is probably not the maximum or minimum supply voltage or current.


It seems to me that the time it takes to go full scale depends on the error and on the gain parameters. The gains are fully under your control, but the error is an arbitrary number.


For this measurement, error must start at 0. Input then is pushed up a step which jumps with gain and then goes into integration. There's an image at the section of the link I keep referencing.


But the range of control isn't really related to time, is it? Full range is full range, whether it takes one millisecond, or a thousand, to reach it. I suspect there's a mismatch in terminology that's keeping us talking past one another.


Yes and no. The range of possible values at the output (of the Jaguar) obviously can't change instantaneously and depending on how fast each iteration of the code can move the output will depend on how many times it can go around before the PID loop can drive to the limits...but of course...within the minimum and maximum you might not start at the minimum because of the gate drive circuit.


I'm not following you. It doesn't "back off" until the error term changes sign. Nothing in the controller can tell you when that will happen.

Of course you can't get it from the code; the error depends on the state of what you are controlling. The "assumptions" you must make are not wild; they are based on the response of what the controller is controlling.


The link I keep providing clearly defines that this test starts with 0 error.
http://www.jashaw.com/pid/tutorial/pid3.html


There's clearly some idea which you think is obvious but which you are not succeeding in getting across to us. I still do not understand the distinction you apparently are maintaining between the implementation of the controller and the controller itself.

I don't actually understand why you think I've made that distinction.

[techhelpbb]

It looks to me like you're asking for numbers that depend on the gain parameters. They are not an inherent feature of the PID controller implementation.

No. The number is not about the gain at all it's about what's above it in that diagram.
This link I provided is quite specific.

The error starts out at 0.
The error is shifted to stimulate a response (which will take some number of 1ms cycles because of the discrete time design of the Jaguar).
The gain is apparent and noted.
The integrator gets started.

There's a measurement in time shown at the bottom, it's the repeat time.
That'll be measured in repeats per minute.

[EricVanWyk]

There is no disrespect in what I'm writing to these people. This is a complicated subject and I am merely trying to get to the meat of it.

I have not, at any point, clearly disputed that the Jaguar has a software timed iteration of the PID loop at 1ms intervals.

The parameter I seek is clearly defined at the link I presented several times. It is not an instantaneous parameter for a iteration around the Jaguar's loop.

The Jaguar will not continue to integrate forever in 1ms steps.
It can't.

I accept that disrespect is not your intent, but it is the effect. I only ask that you account for that effect in future posts.

It is not clear to me whether you are speaking of the jaguar in isolation, or the jaguar + motor + mechanics as a total package.

In isolation, the best available model of the jaguar is a 1kHz vanilla PID loop with an output that saturates at +/- 100% of the bus voltage. Further levels of detail are available, but the additional accuracy those details provide would be swamped.

If you require a fancier or different control algorithm, you will need to implement it on the cRIO. If this proves to be too great a burden, I ask that you write a proposal whitepaper for the feature and submit it for the 2012 season.

[wmarshall]

The question reduces to "How may times per minute does the I repeat the action of the P?"

I really don't see what the confusion is
:confused:

[techhelpbb]

I accept that disrespect is not your intent, but it is the effect. I only ask that you account for that effect in future posts.


If somehow I've offended someone I apologize. However, I do not feel it's disrespectful to ask questions and the link I'm referencing is not some trivial work in the professional control field. Also I'm hardly unaware of the specifics of PID loops, the calculus that supports them, or for that matter I suspect is neither is the author of the link to which I refer:

http://www.jashaw.com/

I can provide additional links if desired in which the parameters I seek factor predominantly.

http://www.scribd.com/doc/6929817/Basic-Control-TheoryDr-Hung-Nguyen
(search for 'repeats per minute')

http://dexautomation.com/pid.php
(search for 'repeats per minute')

http://www.automation.siemens.com/WW/forum/guests/PostShow.aspx?PageIndex=1&PostID=256787&Language=en
(search for 'repeats per minute')

It's possible I'm not communicating in a way that is apparent if you focus down on the intimate loop details but I'm sure what I'm asking is a parameter I can get for virtually every single PID loop that controls motion in my shop full of servos and servo controllers. This includes IAI and Mistubishi.


It is not clear to me whether you are speaking of the jaguar in isolation, or the jaguar + motor + mechanics as a total package.


This parameter can be approximated with just the controller, in this case the Jaguar.


In isolation, the best available model of the jaguar is a 1kHz vanilla PID loop with an output that saturates at +/- 100% of the bus voltage. Further levels of detail are available, but the additional accuracy those details provide would be swamped.


I won't disagree, simulating this parameter would likely be nightmarish. I merely touched on a fraction of the details because before because I was trying to point that out.


If you require a fancier or different control algorithm, you will need to implement it on the cRIO. If this proves to be too great a burden, I ask that you write a proposal whitepaper for the feature and submit it for the 2012 season.

This was not about having a fancier algorithm. Obviously, I can see this algorithm and I was aware when we had a special case algorithm in the past, which was why we implemented it in Java when that happened. Runaway conditions can't be so easily controlled with ideal, series or parallel algorithms.

This was about obtaining the parameters to perform tuning such as this:
http://www.learncontrol.com/tutorial/pid6.html

I can provide you a several tuning examples such as this, that will produce tuning that in some cases is pretty close to what you'd get with professional PID tuning software, a very complicated simulation and a major headache.

[Alan Anderson]

No. The number is not about the gain at all it's about what's above it in that diagram.
This link I provided is quite specific.

Here is what I believe the crux of the issue boils down to.

You are basing your demand for "repeat time" and "derivative time" values on the specific PID implementation described at http://www.jashaw.com/pid/tutorial/pid3.html:

Out = G(e + R+ D )

The Jaguar does not implement that PID form. As David posted:

Output = P*Error + I*Integrator + D*(Error - Previous Error)

They can be transformed into one another if necessary, but you will find that the "repeat time" is essentially determined by the P and I constants, and the "derivative time" is essentially determined by the P and D constants.

I think that if you continue to study the description you are showing us as the basis for your understanding of PID, you will also find that the repeat time and the derivative time are not characteristics of a controller that get measured. They are parameters that must be set in order to tune the controller.

[Joe Ross]

Alan posted while I was doing research, but here's my explanation

http://www.automation.siemens.com/WW/forum/guests/PostShow.aspx?PageIndex=1&PostID=256787&Language=en
(search for 'repeats per minute')

This describes the PI controller as Kp(1 + 1/(Ti*s)). Is Ti the value you are looking for?

The Jaguar implements Kp + Ki/s

The equations are equivalent, if you consider that Ki can be described as Kp/Ti. By controlling Ki and Kp, you can make Ti whatever value you want.

LabVIEW implements the form you are familiar with.

[techhelpbb]

Thank you all and to further clarify how we got to this point:

From the Siemens link:
http://www.atp.ruhr-uni-bochum.de/rt1/syscontrol/node61.html

The standard form of the equation as it is called here:

WikiPedia Alternative nomenclature and PID forms (http://en.wikipedia.org/wiki/PID_controller#Alternative_nomenclature_and_PID_fo rms)

Is what I'm used to working with, has more direct physical relationship to the consequences of the physical operation of the loop (that's why it's used so often in the industry, that and it probably was easier to understand when it's analog and not subject to the constraints of computer mathematics...hence my servo controllers and LabView...and that is why I'm used to thinking about the consequence of what these values mean and why they are commonly referred to as tuning parameters).

It's possible to have measurable time in this form. After all these parameters are based on time which is linear. Of course gains do not have units.

In the alternative ideal form you've used (and obviously you can go back and forth), is less intuitive in a physical implication sense, but more mathematically friendly. I'm absolutely positive there are timing implications for this form that are the consequences of physical limits, but now that I see how to go back and forth I can see more clearly what you mean when you say you can set your Ti and your Td (that seems quite nebulous in meaning to me).

I was trying to extract Ti and Td backwards using measurements from a practical implementation of the system to a point. Not trying to determine where the limits of the Kp, Ki and Kd parameters are the other way around. Obviously there is a specific relationship there and that was basically what I wanted.

It was this difference that was making us 'talk past' one another. I'm trying to apply my practical experience tuning industrial PID loops within the context I'm provided information usually, and the Jaguar obviously implements this is the way that is most friendly to it's programming. Since we got to this point by going after the code for the Jaguar, it created a gap between what I was expecting within the practical constraints and where that mathematical form can go (you can plug whatever you want in with the math but I was trying to get a grip on what the real world would limit it to and the other form of this equation makes that easier for me to visualize). After all, the real world is the reason we can't just absolutely resolve this matter in the first place and just a deliver a PID loop with a perfect tune every time.

There's nothing wrong with that. It's just a different way of looking at it.
I can now see how to get to the various points I am would like to be at.

[meakerb]

After slogging through the 5 pages of this thread, I've come to one conclusion: I'm not going to use the PID control within the Jaguar.

The original post posed the issue of how do students (and others who do not have the mathematical background of most of the posters) tune their PID controller. After 5 pages of discussion (and arguing over the mathematics and other minutia) I don't think there is any consensus here, which leaves two alternatives: trial-and-error, or just don't use the PID control.

Unless someone here can convince me otherwise, I will opt for the latter.


Mentor, team 3221

[techhelpbb]

After slogging through the 5 pages of this thread, I've come to one conclusion: I'm not going to use the PID control within the Jaguar.

The original post posed the issue of how do students (and others who do not have the mathematical background of most of the posters) tune their PID controller. After 5 pages of discussion (and arguing over the mathematics and other minutia) I don't think there is any consensus here, which leaves two alternatives: trial-and-error, or just don't use the PID control.

Unless someone here can convince me otherwise, I will opt for the latter.


Mentor, team 3221

The only problem I ever had with the approach they were using was that I felt I couldn't reconcile my experience at each stage of the system (from the software to the electronics to the mechanics) with the results I'd get from what we have.

The approach they gave will work. It's a tested model. It just bothered me we had to push the limits of the mechanical system, which sort of ignores the electronic system which itself has limits.

There are good...technical reasons...that we all skated over when we talked about this and that make it hard for most people with basic tools to test the electronic limits especially with a brush DC motor.

I am absolutely going to test a few things from this topic and confirm that that I am correct about them. I will do so promptly and...I hope...I can try to produce something that is accessible at the level of people without a Masters or PhD control theory. For the most part: for velocity loops the presented pattern of tuning that works best was described and for position loops it was also described.

I want to clarify after all that I don't believe the TI Jaguar algorithm is wrong...it's precisely correct. There are MANY ways to implement PID in the industrial world. Some target specific applications, some target specific set points. It doesn't help that the terminology is often different for the same things. It doesn't help that certain approaches to the sort of thing often render what should be obvious patterns hidden under a pile of math into things people might not grasp in a timely manner.

I do not for the most part, disagree with the vast majority of this topic. It is unfortunately the sort of thing that can happen when people from diverse backgrounds try to grasp the details of something this complicated.

I know I'm not the first person to be confused by this during the course of a FIRST competition because I've had conversations like this with other mentors at competition.

I worry, most of all, that when 'strange things' happen and people skate over accessible understanding of it 'for what works' we shrug our shoulders and forget that we have students here that are learning. Just because the calculus books say one thing, the physics books another, it's quite probable they are only looking at the physical results and they are too easily not ideal like this quickly enough that the students feel they can really grasp it.

I never want to put anyone off. On the contrary, this is a very complicated topic that spans huge books, and I merely want to make sure that somewhere there is a properly condensed solution for basic problems that make accessible sense.

I can say with absolute certainty there is a gap because last year, I hadn't mentored for several years, and I came in to help with some simple matters. I was a little surprised when the student doing most of the coding thought he had the whole 'PID thing' under control. I was even more surprised when he thought he could tune 2 loops at the same time in a synchronous manner. I figured that the documentation for the NI cRIO must be absolutely fantastic to explain the sort of detail I took a good long time to learn so quickly and precisely. Then in the last few days we had a twitching robot that could never...ever hit the set point...never at the same time and when I asked if we tuned the loops he had, I suspect, a very limited or confused idea of what that meant. Problem was that even if he could tune them in LabView I wasn't entirely certain how that translated to Java and then to the Victor 884 speed controls (we used them last year) and the JavaDocs are basically just an export of the functions into HTML with little useful comment in some critical places. After I banged my head on the problem for a bit...and that was with a gun to my head for time....I realized that even if we figured out how to transfer the tuning from the LabView to the Java and get it working...the mechanical system was so overloaded that it would jump in ways that we couldn't tune and...frankly...everyone was so aggravated that if it didn't appear there was logic to the process there was going to be a gracious...but professional...removing of the entire assembly. So I broke the entire basic concept down into the most basic...physically testable...concepts I could think of. Had them test each one a few times and then basically had the students piece the process back together. Was it great 'computer science'? No. Was it great mathematics...eh...no. However until we started to hit the limits of the timing constraints it worked. We wouldn't have hit those limits if not for the fact that our mechanism could bind and then 'runaway' near the set point.

For the most part, what I've learned from this topic technically shouldn't discourage the use of the Jaguar or the PID functions. Though a nice...abridged version...might make a whole lot of people more comfortable which was sort of my concern from the beginning. I mean it's taken several students a bit of effort to figure out just how to get the encoders working on the Jaguars so they read properly, that some of the encoders had A and B wrong. That when the master link on our kit of parts robot eventually dragged it kicked the PID loop they were trying to tune unexpectedly at even intervals of minutes (just how long it took to come around the chain and catch). I don't really envy them feeling like they are tweaking something aimlessly just to get down to this point that they are tuning with the BDC-COMM and when we finish here we still have to be sure that Java actually does what it's supposed to. Especially when if you read other topics from the past up in these forums there were issues with some of these functions that are no longer relevant as the current firmware fixes them. I'm confident we can get this working. I just don't want to even think about trying to do it...oh say 1 day before we ship the robot.

[drakesword]

After slogging through the 5 pages of this thread, I've come to one conclusion: I'm not going to use the PID control within the Jaguar.


As I had previously stated.

Tune the PID so it is responsive and quiet even if it mean it only reaches 50% setpoint.

Option A: Double your setpoint and hope for the best.

Option B: Calculate % error and increase your setpoint by that amount.

For 95% of the robots on the field Option A will work perfectly.


The original post posed the issue of how do students (and others who do not have the mathematical background of most of the posters) tune their PID controller. After 5 pages of discussion (and arguing over the mathematics and other minutia) I don't think there is any consensus here, which leaves two alternatives: trial-and-error, or just don't use the PID control.

Unless someone here can convince me otherwise, I will opt for the latter.


Mentor, team 3221

If you do not want to use PID on the jaguar you can consider the PID in the API.

[techhelpbb]

As I had previously stated.

Tune the PID so it is responsive and quiet even if it mean it only reaches 50% setpoint.

Option A: Double your setpoint and hope for the best.

Option B: Calculate % error and increase your setpoint by that amount.

For 95% of the robots on the field Option A will work perfectly.



If you do not want to use PID on the jaguar you can consider the PID in the API.

I just want to clarify.

You are making that suggestion so they can use the P loop only for a set point of velocity (meaning your I gain (Ki) and D gain (Kd) remain at 0) and you're compensating for the offset (droop) the P loop will experience like that by increasing the set point. This is what it appears when I read this.

I won't deny that this works. In a physical sense what you propose really will work (to a point). But as was suggested tuning I gain (Ki) would probably be a better idea when the set point is velocity. Again...things are different when the set point is a position. There are patterns to how that PID equation they implemented will react. The patterns might be a little more visually understandable in the most common standard mathematical form of the PID transfer function like LabView uses, but they are equivalent in a purely mathematical sense.

In short, and to be absolutely clear, you're going to need some I gain (Ki) with the P gain (Kp) unless you feel like manually compensating each and every possible velocity set point you can attain (and you'll quickly find that's not quite linear). You can still find the point by running a series of tests. Finding the point at which oscillation even slightly appears while making sure you have no mechanical or electrical issues causing them. You can even take 50% of your P gain (Kp) when you hit that point of oscillation (make sure you test this a few times) as you have effectively done here. Just increase your I gain (Ki) starting at a small number like 0.0001 and probably stopping well before 0.1. You should be able to achieve your set point like that and if you can actually measure it...it might waiver a little...but not much if you get it right. Pay attention to not let your battery draw down too much while you do this, it may effect the ability of your motors to move and adversely effect your testing. Again...we need to be VERY specific about this...we are talking about a set point of velocity in this post and what I'm responding to not position.

It's even entirely possible as others have suggested that you might be able to make this work with just an I loop (that would be P gain (Kp) and D gain (Kd) remaining at 0). Not sure about this however, I have to consider that a while.

To clear up some of the alternate names for the same values used in these 5 pages:

Kp = P gain = P constant (the value of P in BDC-COMM)
Ki = I gain = I constant (the value of I in BDC-COMM)
Kd = D gain = D constant (the value of D in BDC-COMM)

These have no units as they are gains.

Common industrial tuning parameters for PID loops:

Ti = integral time = repeat time = reset time = reset rate
(usually measured in repeats (resets) per minutes (or seconds) or the inverse)

Td = derivative time = rate = pre-act
(usually measured in minutes or seconds)

To convert your tuning parameters to your Ki and Kd constants:
Ki=Kp/Ti, Kd=Kp*Td

[techhelpbb]

If you pattern match, this I controller for velocity control has the same form as the P controller when doing position control. This says that the I term in the Jaguar's velocity loop acts like the P term in the Jaguar's position loop. A similar analysis will show that the P term in the Jaguar's velocity loop acts like the D term in the Jaguar's position loop.

As a courtesy because this is correct and because it's been long buried.
I gain (Ki) is an important key factor for a velocity set point in the Jaguar.

The I gain (Ki) really shouldn't be ignored for this purpose. Even though the most basic step by step instructions might lead one to believe that P gain (Kp) should be tuned and it will achieve a certain result (perhaps one might even think from some presentations the result you intend by just using the P gain (Kp) alone), if you read those documents carefully with the mathematical background you'll see they are often tuning to a position set point and we are talking about a velocity set point.

Right tool for the right job.
Again, my thanks for the time and patience on this matter to everyone involved.

[Greg McKaskle]

Along the way, this thread briefly commented on considerations for doing PID on the cRIO and spent a considerable amount of time investigating PID implementation on the Jaguar.

To add a bit of additional info on the cRIO option, keep in mind that the default loops running on the cRIO are at standard priority. If the CPU isn't highly loaded, and no large processing tasks are running, the timing of the loops will likely be fine. The somewhat simple frameworks that don't use priorities trade timing determinism for simpler code and fewer new concepts.

If you are trying to have tight timing constraints and you have large processing tasks such as vision, you should investigate taking advantage of the OS and development tools for added determinism. I'm talking about priorities, timed loops, and related realtime features. It will introduce new concepts, but will restore your code's ability to meet deadlines.

There are a number of elements to consider when choosing how to do control, and the good news is that using the Jaguar to do truly dedicated control is a great enhancement to the control system. Meanwhile, the ability to view plots of the inputs, output, and setpoint, and to be able to normalize or fixup angle wraps are areas where the cRIO may be a better choice.

While portions of this thread were somewhat painful to read through and difficult to understand, in the end I hope that teams and mentors learn how to relate the different approaches and help teams choose between control choices.

Greg McKaskle

[techhelpbb]

I just want to follow up a concern from another mentor about PID loop tuning in here.

Above drakesword said that you can drive 95% of the robots at the competition using the tuning method he outlines.

What he is describing in that post 'just works'. It's hard to argue with that tangible outcome. Problem is it's actually quite possible that what he is describing could 'just work' while there are other problems in your robot. That means it might be a good second choice if you can't get it to do what it should and can't figure out how to fix it.

What I was told by someone was that they can never tune the I portion or D portion of their PID loops in LabView or the Jaguar for a velocity set point.

When you try to tune the I portion or the D portion of the PID loop with a set point of velocity, especially if you use the observation of oscillation method presented by others and echoed by myself above. It is vital that 2 criteria are met in your robot:

1. The system you are tuning >MUST< be operating smoothly. The battery should have a reasonable charge. The electrical connections should be stable. The electrical connections should be correct. The speed controls should be properly cooled. The motors should be mounted well. The motors should be operating freely and they should be tested. The gear boxes should not have chipped teeth and should run smoothly. Belts shouldn't be slipping, sprockets shouldn't be skipping. Chains shouldn't be snagging. Wheels should be smooth running (even if the wheel surfaces are a bit uneven). The frame of your robot that was straight when you started before should be within specifications to keep the rest running smoothly. Just a hint, think carefully about that pneumatic shifter on your gear box and the effect it'll have on your PID loop.

2. Hopefully you are not using a simple PID loop where you can't use it. There are more complicated control loops that exist. Other forms of the PID loop. Obviously the Jaguar doesn't give you much choice in this matter. If you realize you can't use the Jaguar's ideal discrete timed PID loop you could (and we've done it) implement whatever you like (or can) in the cRIO. It appears you can still read the encoders attached to the Jaguars if you zero out all the terms of their PID loop and seed it with some really small values (at least it seems that way for us in Java). You might even be able to get the cRIO to run a special case PID loop and use the sensors on the Jaguars if you need the extra I/O.

Unfortunately when you observe for things like oscillation with visual and audio observation you can make mistakes in tuning. This method of tuning is deceptively simple. You might hear a noise in this tuning method and assume you've reached the first sign of oscillation. Problem is that noise might really be caused by some simple electrical or mechanical issue and if you eliminated that issue...then this tuning of the I portion for the velocity set point would actually work. Hard to do this sort of thing in a large noisy room with limited time and tools. If you really want to make this work...and you're having trouble doing it...try it when you can patiently tinker with it don't just discount it.

Simple rules are nice. In industrial settings. We'd take measurements of values. Put them into the proper context in the standard PID form. If we had to get them to the Ki or Kd values the Jaguar needs, we'd assume the linear relationship and convert then compensate for some real world issues. This adds math and more measured observations. It should make for a more precise tuning for the loop. However, in doing that math you might discover that your measurements would show you that your system can't use such a simple PID loop. Tuning for the oscillation as has been described is simple to explain. However, you might never do the sort of measured observation of the system that would clearly demonstrate you shouldn't be using such a simple PID loop to control it, you could only find that out after a long process of elimination and possibly lots of oscillation with the simple method as proposed. It's a trade off: what we have time for, what we have tools for, what we have the available understanding to obtain. The math is sound. The concept does work. There is nothing wrong with the Jaguar design as such. It's just complicated and needs careful patient commitment to make this work as it should.

Good luck to everyone, and again, thank you all for your patience and time.

[kamocat]

Here is an example of a situation where PID does not correctly describe the error you will encounter:

Holding an unbalanced arm in position (against gravity).

In this, the force required compared to the angle of the arm is a sine function. With PID, then, you're likely to have uncontrollable oscillations near 0 and 180 degrees, or insufficient force near 90 degrees.

My team's robot does indeed have a mechanism similar to this. I plan to try PID and see how well it works. If it's not adequate, then we'll find another way.

[Nikhil Bajaj]

A question to those of you who have seen the code and looked in depth at the Jaguar implementation of the PID...is there windup limitation on the integrator? I can't find anything that says that there is--if there isn't I would personally feel concerned about running certain systems (those that would have a tendency to get into situations where they are under-actuated) with the Jaguar/CAN/PID combination.

[Ether]

That's the WPILib source code, not the jaguar source code.

Good catch Joe. That's what I get for posting while talking on the phone.

I'll delete the post.

Looks like the Jag PID limits integrator wind-up:

//
// Update the error integrator.
//
if((psState->lIntegrator & 0x80000000) == (lError & 0x80000000))
{
//
// Add the error to the integrator.
//
psState->lIntegrator += lError;

//
// Since the sign of the integrator and error matched before the above
// addition, if the signs no longer match it is because the integrator
// rolled over. In this case, saturate appropriately.
//
if((lError < 0) && (psState->lIntegrator > 0))
{
psState->lIntegrator = psState->lIntegMin;
}
if((lError > 0) && (psState->lIntegrator < 0))
{
psState->lIntegrator = psState->lIntegMax;
}
}
else
{
//
// Add the error to the integrator.
//
psState->lIntegrator += lError;
}

//
// Saturate the integrator if necessary.
//
if(psState->lIntegrator > psState->lIntegMax)
{
psState->lIntegrator = psState->lIntegMax;
}
if(psState->lIntegrator < psState->lIntegMin)
{
psState->lIntegrator = psState->lIntegMin;
}

[Nikhil Bajaj]

Thanks, Ether. That helps...I guess I will have to play around with the CAN stuff further in order to figure out how to set that value.

Another feature I like to include sometimes when I program a PID loop for myself is that I don't add anything to the integrator if the system is saturating (not just keeping it from winding up too much, but just not adding into the integral term if it won't help anything).

So, if P and D are maxing out the actuator (pegging it at 12V) then there doesn't seem like there's much point in adding to the integrated term. This is certainly not a "classical PID", but limiting integrator windup, and having a saturated system is also not "classical PID".

It also appears that there isn't a way to use a D term with a built-in low pass filter. I know LabView and Simulink both have this, but the Jaguar doesn't, else we'd have a place to put the time constant for that.

[kamocat]

Nikhil,
Are you saying that the standard form and ideal form of PID will actually perform differently?

[Nikhil Bajaj]

I'm going to write post in language that I think will widen the audience a bit so that hopefully other people who aren't super-knowledgable about controls can understand. If I come across as condescending to those who know a lot about this stuff (which is clearly most people in the thread), I don't mean to be! :)

As defined in the Wikipedia article on PID Controllers referred to earlier, no, the standard and ideal forms will not perform differently. They are mathematically equivalent, with the standard form being more intuitive from a physical and tuning perspective, and the ideal form being a bit nicer for analysis and if you are going to do gain selection via methods like direct pole-placement (if you don't know what that is, don't worry about it too much if you're just concerned with getting your robot working. Just tune your PID, it'll work well with Ziegler-Nichols or some other tuning method).

But those forms are just dumb algorithms. PID isn't a be-all, end-all control method. When the PID controller decides on what the next output should be, it doesn't know about actuator saturation and the implications thereof.

It only knows "I've got to multiply my error by this, multiply the integral of my error by this, and multiply the derivative of my error by this, add them up, and that's my output." If you saturate your controller, it neither knows nor cares. It still thinks the integral term should be winding up, and doesn't care how much it does.

If you write code that changes that, then you have a controller that is no longer a PID controller, it is some extension of a PID controller that is better suited for systems that will commonly saturate their actuation authority. Adding something to limit windup, or preventing any summation into the integral when the proportional term or derivative terms are saturation, are non-linear additions to the ideal/standard PID controller that reflect our understanding of the reality of the system. Those additions are what can significantly change performance, and we add them because in the systems we're working with, we think it will change performance for the better.

Taking saturation into account in the ways I've described, for example, will often help significantly with overshoot without impacting settling time, etc. as much as just fiddling with your P, I, and D gains would.

The other addition I mentioned in my previous post is one that affects the derivative term. Because taking a derivative tends to exacerbate high-frequency noise, a common addition to PID controllers is to include what is called a low-pass filter on the derivative (which is a way of basically decreasing the effect of very fast changes in a value over time, like noise, and keeping the low-frequency, slower changes in the value over time, like what the physical system is doing). This can improve the performance of derivative-related terms in noisy systems. Probably not a huge deal when you are using incremental or absolute encoders, but it can be miraculously helpful if you are using the analog signal from a gyro or potentiometer. The low pass filter is typically linear, so this isn't as complicated of an addition in terms of modeling the effects.

We know the systems we work with better than the dumb PID algorithm does, and any help we can give it, the better. Plus, today we have tools like LabView and Simulink, etc., that make it relatively easy to simulate the effects of doing non-linear additions to the controller.

Yeesh, long post. I hope it was helpful in explaining what I meant.

[Ether]

I'm going to write post in language that I think will widen the audience a bit so that hopefully other people who aren't super-knowledgable about controls can understand. If I come across as condescending to those who know a lot about this stuff (which is clearly most people in the thread), I don't mean to be! :)

Not to worry. Excellent post.

[sgtell]

Looks like the Jag PID limits integrator wind-up:

//
// Update the error integrator.
//
if((psState->lIntegrator & 0x80000000) == (lError & 0x80000000))
//trimmed


[/QUOTE]

From this old thread it looks like the Jaguar's onboard firmware source code was once available - at least the old TI/Luminary micro version (I understand that the FRC version was not).

Is there anywhere to obtain this source code today? Our students are attempting position-based PID control onboard the jaguar using an encoder, and having some difficulty. Being able to point to exactly what the jaguar is doing with their parameters may be a useful teaching opportunity.

thanks, Steve

[jhersh]

Is there anywhere to obtain this source code today? Our students are attempting position-based PID control onboard the jaguar using an encoder, and having some difficulty. Being able to point to exactly what the jaguar is doing with their parameters may be a useful teaching opportunity.

Have you tried looking here? http://www.ti.com/tool/mdl-bdc24&DCMP=STELLARIS&

There is a software download that should include the non-FRC version, which should include all of the PID algorithms.

[GeeTwo]

By definition, it is impossible to stably hit your set point with a P only control loop. You must have an I term.

It is possible to have an accurate feed-forward and achieve this. Not likely, for sure.

Also, for benefit of anyone reading this and not recognizing the distinction, you can stably hit a position set point with a P-only control loop. (Well, actually you need some D, but this doesn't need to be in software - a bit of friction will often do the job nicely.)



As to a P-only loop only reaching 50% speed, that makes sense if you don't have a feed-forward. Thought experiment: what happens if you start at the setpoint speed, or equivalently read the current speed, and make it the setpoint? Answer: the difference is zero, so zero voltage is applied to the motor. It slows down. As it slows down, D increases and voltage is again applied, but never enough to get back up to the set point.

[Ether]

This thread is about speed control using the Jag firmware PID, which does not have a feedforward term.