We’ve “successfully” gotten our CAN Jaguars working under speed control.
We’ve tuned the PID constants to get a system that seems to react nicely, and is stable.
The only problem, our system only reaches 50% of the setpoint speed.
Anyone else notice this?
When we setX() at 60 RPM, getSpeed() shows only 30 RPM is attained.
I’m pretty sure I know why this is happening, but I’d like to confirm others are seeing this too.
There’s two possible causes:
Either you’re going as fast as the motor can, or you need to include some Integral into your tuning.
If you’re providing full power, then the Jaguar LED will be solid green (or solid Red if you’re in reverse)
Can you confirm that a P-Only control loop will only get you half-way to the setpoint?
I have some concerns that the speed control mode on the Jags is missing some important functionality.
If the P term doesn’t accumulate in velocity control, it will go to 0 as it gets closer to the setpoint. This usually results in a P-only loop appearing stable, but only hitting about 50% of the setpoint.
A workaround is to have an I term that will get you all the way to the setpoint. However, I’ve heard elsewhere that the I term goes to zero as soon as the setpoint is attained, so as to prevent overshoot/wind-up. I can’t confirm this 100%, but based on some initial testing I’m led to believe this is the case, as an I-only loop seems to hit the setpoint, then cuts out, only to accelerate up to the setpoint and cut out again.
Right now, we’re using a P-only loop, setting the setpoint twice as high as we really want it. It’s a sloppy workaround, but the best we’ve come across so far.
I’ve not used CAN on the Jags before, much less the PID control, but is there a configuration that has to be set for number of clicks/rev on the encoders?
Yes, without an I coefficient, you can’t expect to ever reach the setpoint; you get partway there, and then don’t go any further.
I haven’t tried an I-only loop.
If you’re intent on using P only, what happens when you double your P coefficient? Is that the point where it starts to oscillate?
I’m in the process of tuning the Speed PID loop on my team’s Jaguars, and I’m having a similar issue. Using BDC-COMM to set the PID values, I can increase P until I get to just under my setpoint, but when the loop actually hits the setpoint, the Jags start freaking out and flipping the motor direction very quickly, before faulting. This has made it nigh impossible to get anywhere, as the method I’m using to tune the loop (Wikipedia) needs the loop to hit the setpoint.
At a stable P(no sad gear grinding) the output is much lower than the setpoint, and as P is increased to hit the setpoint, the loop gets more prone to the gear grinding. I’ve yet to even begin to play with the I value, as I fear it may lead to more instability.
By definition, it is **impossible **to stably hit your set point with a P only control loop. You **must **have an I term.
A PID loop is calculated with respect to the error, or difference between what you want and what you have. As you approach the setpoint, the error approaches 0. Therefore, the output of the P term approaches 0. Therefore, with a P only loop you will always undershoot your target. You can jack the P gain up to reduce the undershoot, but it will never be zero. If you jack it up too high, noise will dominate and the whole thing will go unstable.
Keep the P where you have it (hitting half your goal) and add a bit of I.
My workaround has been to tune the P-only loop to react as best as can be to exactly half the setpoint.
I can confirm that when you crank the P to actually try and hit the setpoint, bad things happen. It’ll get you there, only to slam in reverse, and oscillate around the setpoint…
I’ll get a chance to add I term to see if it will actually get me to the setpoint in a stable manner.
I’m curious if anyone know exactly how the Jaguars deal with Integral wind-up. Whether it reduces the I-term to 0 once the setpoint is hit, or does it cap the accumulated I value to some kind of ceiling?
Either way, I think we’ll get a chance to find out tomorrow!
I’m a mentor for wmarshall’s team and I have a request into TI for actual documentation on the transfer function, LaPlace or block diagram for the FIRST firmware Jaguar PID functions.
It’s more curious to me that the P loop doesn’t always reach the point of instability eventually for any given value of P.
In theory, a small P should move more slowly toward the set point but still get there eventually.
This does not seem to be the case and that leads me to believe this is not a parallel PID algorithm.
If I get anywhere I’ll let you all know.
Not only do we not know how they handle integral wind up (if they handle it at all), we don’t know if they have a deadzone or a D filter.
Also I’m not a fan of tuning using the Ziegler Nichols method the way I suspect we’re going to get told to use it.
I’d not like to end up with marginal tuning.
The jaguar source code is available for download. luminarymicro.com
I’ve never heard of such a thing. It would seem to defeat the whole purpose of the integral controller.
**
It is my understanding, though I could be wrong, that the FIRST firmware differs from the commercial firmware.
I know that the FIRST firmware operates in trusted mode where as I’m fairly sure the commercial firmware does not.
Also I’ve noted that TI has mentioned to other people using the ‘Jaguar’ for non-FRC purpose they shouldn’t use the FIRST firmware as the FIRST firmware has ‘safety features’ for FIRST (basically).
This leads me to wonder if I’d be wasting my time reverse engineering the source code. Though frankly, in a more commercial sense, I can’t imagine being told to reverse engineer the source code for a commercial controller just to get a block diagram of the transfer function or the proper tuning procedure.
Is it just me or does this link not work:
“Stellaris® RDK-BDC24 Brushed DC Motor Control Module User’s Manual”
I suspect what they are hoping to communicate would be to eliminate noise induced run away. If you get noise that interferes with your return function then over a duration then…for example…you might end up ‘winding up’ the I in such a way that even though you’ve limited it…it’s still way too high and because of it getting to high over and over from disturbance and noise it may never come down and the result might be perceived as erratic movement.
If you can ‘reset’ the I (not necessarily make the I constant 0), and do it when the I is perceived to have ‘wound up’ too often, then you can effectively prevent yourself from having to reset the entire PID loop to eliminate what appears to be erratic function.
As an example…
http://community.mybb.com/thread-78886.html
The crux of this issue is that the PID implementation seems to be more suited to position control, rather than speed control.
Killing the I term when the setpoint has been reached is commonly employed in position control - particularly in systems where there is a lot of resistance as you slowly reach your desired position. When you are finally reach the setpoint, your P is already 0, and it’s in your best interests to 0 the I term to prevent overshoot. The I has already done its job to get to the setpoint, to overcome any resistance encountered on the way there.
Regardless, I can’t 100% confirm what the I term behaviour is until later this afternoon, but I’m hoping the I-term is capped, rather than 0’ed.
(I posted this last night, but it claimed it needed approval so I’ll try again).
I suspect what they are hoping to communicate would be to eliminate
noise induced run away. If you get noise that interferes with your
return function then over a duration then…for example…you might
end up ‘winding up’ the I in such a way that even though you’ve
limited it…it’s still way too high and because of it getting too high
over and over from disturbance and noise it may never come down and
the result might be perceived as erratic movement.
If you can ‘reset’ the I (not necessarily make the I constant 0), and
do it when the I is perceived to have ‘wound up’ too often, then you
can effectively prevent yourself from having to reset the entire PID
loop to eliminate what appears to be erratic function.
As an example…
http://community.mybb.com/thread-78886.html
When the goal is to achieve a set point of a fixed speed, then I can see how this helps when the prime concern is the change in set point.
As noted above, when the prime concern is achieving the set point position it makes sense when the loading is prone to bind at the last second. Though, the kind of binding matters. If for example the mechanism is prone to binding and then runaway (the motors are overloaded and then break free) then you’re probably too close to the limits of the ideal, serial or parallel algorithms for the stable D to be achieved anyway in which case now you have a special case.
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.
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.
I suppose if they’re frequent enough, you don’t need a PID at all 
**
Depends. It might be a cascaded system :ahh: