Jaguar Speed Control Only Reaches 50% of Setpoint

[dyanoshak]

Originally Posted by techhelpbb

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.

Originally Posted by techhelpbb

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]

Originally Posted by Mr. Lim

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]

Originally Posted by Ether

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]

Originally Posted by techhelpbb

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]

Originally Posted by Ether

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

Depends. It might be a cascaded system

[techhelpbb]

Originally Posted by dyanoshak

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?



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]

Originally Posted by techhelpbb

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?



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" and download the CD that comes with the kit, for free.

You can also click on the Software Updates link.

[techhelpbb]

Originally Posted by dyanoshak

Not at all. You click the link on the page that says "Reference design kit CD" 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]

Originally Posted by 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.

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]

Originally Posted by techhelpbb

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]

Originally Posted by AustinSchuh

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)

Originally Posted by techhelpbb

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.

Originally Posted by techhelpbb

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)

Originally Posted by techhelpbb

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.