Jaguar Speed Control Only Reaches 50% of Setpoint

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.

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?

OK, valid point.

**

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)

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: PError + IIntegrator + 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.

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.

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]

**

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?

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.

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

**

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

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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

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

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.