Go to Post Looks to me like they have a tasty robot. - Andy Baker [more]
Home
Go Back   Chief Delphi > Technical > Electrical > CAN
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Reply
Thread Tools Rating: Thread Rating: 3 votes, 5.00 average. Display Modes
  #61   Spotlight this post!  
Unread 02-01-2011, 07:13 PM
techhelpbb's Avatar
techhelpbb techhelpbb is offline
Registered User
FRC #0011 (MORT - Team 11)
Team Role: Mentor
 
Join Date: Nov 2010
Rookie Year: 1997
Location: New Jersey
Posts: 1,798
techhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond repute
Re: Jaguar Speed Control Only Reaches 50% of Setpoint

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

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

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

WikiPedia Alternative nomenclature and PID forms

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.

Last edited by techhelpbb : 02-01-2011 at 08:17 PM.
Reply With Quote
  #62   Spotlight this post!  
Unread 02-01-2011, 09:13 PM
meakerb's Avatar
meakerb meakerb is offline
Mentor
FRC #3786
Team Role: Mentor
 
Join Date: Jan 2010
Rookie Year: 2009
Location: Washington
Posts: 13
meakerb is an unknown quantity at this point
Re: Jaguar Speed Control Only Reaches 50% of Setpoint

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
Reply With Quote
  #63   Spotlight this post!  
Unread 02-01-2011, 09:30 PM
techhelpbb's Avatar
techhelpbb techhelpbb is offline
Registered User
FRC #0011 (MORT - Team 11)
Team Role: Mentor
 
Join Date: Nov 2010
Rookie Year: 1997
Location: New Jersey
Posts: 1,798
techhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond repute
Re: Jaguar Speed Control Only Reaches 50% of Setpoint

Quote:
Originally Posted by meakerb View Post
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.

Last edited by techhelpbb : 02-02-2011 at 02:42 PM.
Reply With Quote
  #64   Spotlight this post!  
Unread 02-02-2011, 08:33 AM
drakesword drakesword is offline
Registered User
AKA: Bryant
FRC #0346 (Robohawks)
Team Role: Mentor
 
Join Date: Jan 2006
Rookie Year: 2004
Location: USA
Posts: 200
drakesword is on a distinguished road
Re: Jaguar Speed Control Only Reaches 50% of Setpoint

Quote:
Originally Posted by meakerb View Post
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.

Quote:
Originally Posted by meakerb View Post
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.
Reply With Quote
  #65   Spotlight this post!  
Unread 02-02-2011, 11:43 AM
techhelpbb's Avatar
techhelpbb techhelpbb is offline
Registered User
FRC #0011 (MORT - Team 11)
Team Role: Mentor
 
Join Date: Nov 2010
Rookie Year: 1997
Location: New Jersey
Posts: 1,798
techhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond repute
Re: Jaguar Speed Control Only Reaches 50% of Setpoint

Quote:
Originally Posted by drakesword View Post
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

Last edited by techhelpbb : 02-02-2011 at 03:59 PM.
Reply With Quote
  #66   Spotlight this post!  
Unread 02-02-2011, 12:02 PM
techhelpbb's Avatar
techhelpbb techhelpbb is offline
Registered User
FRC #0011 (MORT - Team 11)
Team Role: Mentor
 
Join Date: Nov 2010
Rookie Year: 1997
Location: New Jersey
Posts: 1,798
techhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond repute
Re: Jaguar Speed Control Only Reaches 50% of Setpoint

Quote:
Originally Posted by AustinSchuh View Post
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.

Last edited by techhelpbb : 02-02-2011 at 04:01 PM.
Reply With Quote
  #67   Spotlight this post!  
Unread 02-02-2011, 07:23 PM
Greg McKaskle Greg McKaskle is offline
Registered User
FRC #2468 (Team NI & Appreciate)
 
Join Date: Apr 2008
Rookie Year: 2008
Location: Austin, TX
Posts: 4,861
Greg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond repute
Re: Jaguar Speed Control Only Reaches 50% of Setpoint

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
Reply With Quote
  #68   Spotlight this post!  
Unread 02-03-2011, 11:12 AM
techhelpbb's Avatar
techhelpbb techhelpbb is offline
Registered User
FRC #0011 (MORT - Team 11)
Team Role: Mentor
 
Join Date: Nov 2010
Rookie Year: 1997
Location: New Jersey
Posts: 1,798
techhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond repute
Re: Jaguar Speed Control Only Reaches 50% of Setpoint

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.

Last edited by techhelpbb : 02-03-2011 at 01:19 PM.
Reply With Quote
  #69   Spotlight this post!  
Unread 02-03-2011, 09:51 PM
kamocat's Avatar
kamocat kamocat is offline
Test Engineer
AKA: Marshal Horn
FRC #3213 (Thunder Tech)
Team Role: Mentor
 
Join Date: May 2008
Rookie Year: 2008
Location: Tacoma
Posts: 894
kamocat is just really nicekamocat is just really nicekamocat is just really nicekamocat is just really nicekamocat is just really nice
Send a message via AIM to kamocat Send a message via MSN to kamocat
Re: Jaguar Speed Control Only Reaches 50% of Setpoint

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.
__________________
-- Marshal Horn
Reply With Quote
  #70   Spotlight this post!  
Unread 02-18-2011, 02:36 PM
Nikhil Bajaj Nikhil Bajaj is offline
MATLAB Fan
FRC #0461 (Westside Boiler Invasion)
Team Role: Mentor
 
Join Date: Feb 2003
Rookie Year: 2002
Location: West Lafayette, Indiana
Posts: 101
Nikhil Bajaj has a reputation beyond reputeNikhil Bajaj has a reputation beyond reputeNikhil Bajaj has a reputation beyond reputeNikhil Bajaj has a reputation beyond reputeNikhil Bajaj has a reputation beyond reputeNikhil Bajaj has a reputation beyond reputeNikhil Bajaj has a reputation beyond reputeNikhil Bajaj has a reputation beyond reputeNikhil Bajaj has a reputation beyond reputeNikhil Bajaj has a reputation beyond reputeNikhil Bajaj has a reputation beyond repute
Send a message via AIM to Nikhil Bajaj
Re: Jaguar Speed Control Only Reaches 50% of Setpoint

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.
Reply With Quote
  #71   Spotlight this post!  
Unread 02-18-2011, 03:08 PM
Ether's Avatar
Ether Ether is offline
systems engineer (retired)
no team
 
Join Date: Nov 2009
Rookie Year: 1969
Location: US
Posts: 9,126
Ether has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond repute
Re: Jaguar Speed Control Only Reaches 50% of Setpoint

Quote:
Originally Posted by Joe Ross View Post
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:

Code:
    //
    // 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;
    }



Last edited by Ether : 02-18-2011 at 03:21 PM.
Reply With Quote
  #72   Spotlight this post!  
Unread 02-18-2011, 04:54 PM
Nikhil Bajaj Nikhil Bajaj is offline
MATLAB Fan
FRC #0461 (Westside Boiler Invasion)
Team Role: Mentor
 
Join Date: Feb 2003
Rookie Year: 2002
Location: West Lafayette, Indiana
Posts: 101
Nikhil Bajaj has a reputation beyond reputeNikhil Bajaj has a reputation beyond reputeNikhil Bajaj has a reputation beyond reputeNikhil Bajaj has a reputation beyond reputeNikhil Bajaj has a reputation beyond reputeNikhil Bajaj has a reputation beyond reputeNikhil Bajaj has a reputation beyond reputeNikhil Bajaj has a reputation beyond reputeNikhil Bajaj has a reputation beyond reputeNikhil Bajaj has a reputation beyond reputeNikhil Bajaj has a reputation beyond repute
Send a message via AIM to Nikhil Bajaj
Re: Jaguar Speed Control Only Reaches 50% of Setpoint

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.
Reply With Quote
  #73   Spotlight this post!  
Unread 02-19-2011, 10:14 AM
kamocat's Avatar
kamocat kamocat is offline
Test Engineer
AKA: Marshal Horn
FRC #3213 (Thunder Tech)
Team Role: Mentor
 
Join Date: May 2008
Rookie Year: 2008
Location: Tacoma
Posts: 894
kamocat is just really nicekamocat is just really nicekamocat is just really nicekamocat is just really nicekamocat is just really nice
Send a message via AIM to kamocat Send a message via MSN to kamocat
Re: Jaguar Speed Control Only Reaches 50% of Setpoint

Nikhil,
Are you saying that the standard form and ideal form of PID will actually perform differently?
__________________
-- Marshal Horn
Reply With Quote
  #74   Spotlight this post!  
Unread 02-19-2011, 01:09 PM
Nikhil Bajaj Nikhil Bajaj is offline
MATLAB Fan
FRC #0461 (Westside Boiler Invasion)
Team Role: Mentor
 
Join Date: Feb 2003
Rookie Year: 2002
Location: West Lafayette, Indiana
Posts: 101
Nikhil Bajaj has a reputation beyond reputeNikhil Bajaj has a reputation beyond reputeNikhil Bajaj has a reputation beyond reputeNikhil Bajaj has a reputation beyond reputeNikhil Bajaj has a reputation beyond reputeNikhil Bajaj has a reputation beyond reputeNikhil Bajaj has a reputation beyond reputeNikhil Bajaj has a reputation beyond reputeNikhil Bajaj has a reputation beyond reputeNikhil Bajaj has a reputation beyond reputeNikhil Bajaj has a reputation beyond repute
Send a message via AIM to Nikhil Bajaj
Re: Jaguar Speed Control Only Reaches 50% of Setpoint

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.

Last edited by Nikhil Bajaj : 02-19-2011 at 01:14 PM. Reason: grammar :(
Reply With Quote
  #75   Spotlight this post!  
Unread 02-19-2011, 03:04 PM
Ether's Avatar
Ether Ether is offline
systems engineer (retired)
no team
 
Join Date: Nov 2009
Rookie Year: 1969
Location: US
Posts: 9,126
Ether has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond repute
Re: Jaguar Speed Control Only Reaches 50% of Setpoint

Quote:
Originally Posted by Nikhil Bajaj View Post
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.


Reply With Quote
Reply


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 02:00 PM.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi