Currently, we are running CANBus mode on the jags without PID Speed control.
I’ve set up the PID Speed control and would like to know exactly what values to put where. I’ve heard that the “P” value is the only one that needs to be edited.
So my question is;
How are “P” values considered? Is it values between -1 and 1 or something else?
§roportional, (I)ntegral, (D)erivative. These are all terms of gain in the PID equation. Without getting into the math, I would try a .25 or .5 to start with with and then gradually increase (to speed up) or decrease (to slow down) from there.
For positional control, yes start with P and raise till unstable - back off and add some I to achieve closer final value.
For Velocity (Speed) control, many teams have had better success starting with I and adding P. The issue is with velocity, a negative proportional error will try to drive the motor backwards. The other way to solve this is to use a feed-forward term, which is not available on the Jaguar.
Hi Shane. Welcome to ChiefDelphi.
Have you successfully implemented speed control using the PID algorithm in the Jaguars? Was it for the drivetrain, or some other mechanism?
Well I made this:
http://i758.photobucket.com/albums/xx230/megasilver335/canjaguar_zps92a03905.png](http://s758.photobucket.com/user/megasilver335/media/canjaguar_zps92a03905.png.html)
It’s just missing PID values.
When you’ve actually successfully tuned a Jag PID for drivetrain speed control please post your experience here. This topic is of interest to many here on CD.
Oh… Okay so I guess I’m pioneering the way for speed control PID? Because I really don’t know what I’m doing with it.
Sorry, I read your post too quickly. I thought I was responding to the person posted
“Without getting into the math, I would try a .25 or .5 to start with with and then gradually increase (to speed up) or decrease (to slow down) from there.”
But when you are successful, please do share your experience.
There are several threads on CD about tuning the Jag PID for speed control. If the built-in search in CD doesn’t find them, try using Google with … site:chiefdelphi.com Jaguar PID
Thanks! 
we actually couldn’t tweak it because we were busy rushing to finish the bot before midnight on bag day. I’ll let you know after practice day at the San Diego Regional. 
It proved way too glitchy for us to use.
We just said “screw it” and scrapped CANBus, because no other teams were dealing with CANBus and Labview, so we went back to PWM.
Reminder to self, no more Mecanum drive.
That’s unfortunate. We’re using CAN and LabView and omni-wheels, but not with closed loop speed (yet). So far, we have not had problems, but we are using additional surrounding loops and filters on driver inputs and rotations to limit commanded speed changes.
In past years, we tried to start from the wheels up, and hit many frustrations. This year, we are starting from the top (driver) down, and doing better, although we have not closed the last loop at the jaguar to wheel.
We noticed in the past that the Jaguars cut out when they seem to predict that they will exceed a limit, under PID control. We decided to filter the driver input by limiting the maximum acceleration allowed, both linear and rotational. Further, we implemented a PID in LabView to compare a modeled rotation to our gyro reading, and use that to drive the holonomic.vi rotational input. So far, this is the best control we’ve ever had for mechanum or omni-wheel.
We would like to do the one last step of closing the loop at the wheel, now that we have more restrained inputs. That will have to wait until our bag gets opened later this week. In the end, we are good enough now, and have no issues with CAN Jaguars.
*Len,
Have you guys considered writing and posting a paper explaining what you’ve done?
Yes, but we’d like to have some on-field time to really tune it up and prove that it is good enough to share. It was worked out on a white-board and ground into code, which remains the only documentation that we have at this point. Our students glaze over when I talk about accelerations and velocities being derivatives of position. We’ve kept it simple by limiting rates of velocity change (effective max. acceleration), and generalizing by using finite time slices given by periodic task loops. We’ve been working with our base from our old Logo-motion robot as a stand-in for our current one, so we know that the code is working well.
Our goal this year was to make the best field-centric control that we could, where anyone on the team could drive well. We do not have dedicated drivers, due to historical events and precedents in our team. Some students could do OK if we left it open-loop and scaled down the inputs (.5 for linear, .25 for rotational). Other students had difficulty with this, and would cause the robot to lurch about, losing the ball.
A friend of the team remarked that the open-loop control reminded him of the helicopters he flew in Vietnam, requiring very slight movements of the stick. Reduced gains limited the top-end performance of the robot, and we just don’t have enough time for everyone to become skilled drivers with the typical open-loop system. That gave birth to our “bad driver filter” which was driven by physical limits of wheel friction and gyro rate.
Overall, it took a lot of work. We had to go to a new gyro that had a higher rate (posting code for this in a moment), and had to make an intermediate model for rotation. In the end, we want to share all of this, but we don’t want to lead others down a blind alley of thought process that seems valid now, before being fully vetted.