Re: Jaguar Speed Control Only Reaches 50% of Setpoint
 

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:
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.

Re: Jaguar Speed Control Only Reaches 50% of Setpoint
 

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...

Re: Jaguar Speed Control Only Reaches 50% of Setpoint
 

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.

Re: Jaguar Speed Control Only Reaches 50% of Setpoint
 

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.

Re: Jaguar Speed Control Only Reaches 50% of Setpoint
 

Courtesy of TI in regards to my questions...

http://www.eetimes.com/ContentEETime...0/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.

Re: Jaguar Speed Control Only Reaches 50% of Setpoint
 

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

Re: Jaguar Speed Control Only Reaches 50% of Setpoint
 

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.

Re: Jaguar Speed Control Only Reaches 50% of Setpoint
 

http://e2e.ti.com/support/microcontr...25/163005.aspx

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

Re: Jaguar Speed Control Only Reaches 50% of Setpoint
 

OK, valid point.

Re: Jaguar Speed Control Only Reaches 50% of Setpoint
 

The real problems I have with the Ziegles Nichols method (the closed loop version...not all the versions like these)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)

Re: Jaguar Speed Control Only Reaches 50% of Setpoint
 

Taken directly from the Jaguar source code:

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:

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).

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

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.

Re: Jaguar Speed Control Only Reaches 50% of Setpoint
 

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.

Re: Jaguar Speed Control Only Reaches 50% of Setpoint
 

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]

Re: Jaguar Speed Control Only Reaches 50% of Setpoint
 

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

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

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

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

Re: Jaguar Speed Control Only Reaches 50% of Setpoint
 

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.