Manual Velocity PID, anyone successful?

[Chris_Elston]

Has anyone been successful implementing a manual velocity PID for manual driving?

Did you use single or tank drive joysticks?

What worked better for you? Converting your PWM values to a percent based power where 255 = 100%, or just sticking with PWM values.

Did you design two independent PID's for each wheel? Then how did you integrate them together to make the robot drive straight? Did you have something joining your two PIDs together?

Basically, I was wondering if anyone wanted to share their theory if you've ever got this to work.

Seem rather tricky measuring a velocity from encoders, converting to a "PWM value or percent based command", then reading a joystick value, and integrating the encoder feedback two ways for each wheel, then trying to slave them together, and trying to TURN too....confusing control theory....

Anyone want to share?

[Alan Anderson]

We had an optional PID velocity control mode for our 2005 robot. The drivers didn't like it; they were used to the more direct joystick->motor power control. We never took the time to dial in the PID parameters for the best response, but it worked reasonably well at low speeds.

Our scheme for controlling the left and right sides might be a little unobvious. We actually tracked robot velocity and turn rate as our control and feedback values, and mixed them together in the fashion of a single-joystick system to command the motors. It gave us extremely repeatable autonomous drive paths (alas, we didn't manage to get the camera to choose which path to use before we decided to focus on other strategies).

[Jared Russell]

I've had similar experiences.

All of our team's drivers prefer open-loop control for manual driving. Autonomous mode is another beast altogether, but a human driver is one of the better feedback "devices" around for controlling driving. :)

The only feedback functions that we bother using are:

1) Dynamically shifting between high and low gear on the AndyMark transmission based on RPM and turn rate. Basically, if you're in low gear going more or less straight, shift up when you reach a certain RPM threshold. Thus, when you're flying across the field, you stay in low to get your acceleration then ramp into high when you need it. This method also works well because if you suddenly start pushing, you automatically downshift because the RPM lowers.

2) Drive straightening. If we detect that the driver is trying to go in a straight line (i.e. p1_x is within a tolerance of neutral), we used gyro feedback as the control variable for balancing the motor speeds until our angular velocity was zero. This may or may not be useful depending on how reliable your drivetrain goes in a straight line, but we found it helpful nonetheless. As an added bonus, we found that even if one of our four drive motors died in a match we still drove mostly straight. Just be careful in implementing this, or you'll find that your drive motors will stop turning in a pushing match because they will be trying to slow down to match the other side. It isn't too hard to fix that, however.

[Joe Johnson]

It is my understanding that the Killer Bees (Team 33) do it every year (although I am not sure of the PID or just PI or perhaps P in terms feedback loop structure). I think that their 4 speed transmission more or less had to do everything from pick the gear to set the gas -- the driver joystick was used to set desired wheel speeds.

The Wise and Mighty Zondag once told me that his drivers merely make suggestions as to what the robot should be doing. The Code decides if it thinks the suggestions are any good. If The Code likes what is being suggested it tries to be accommodating, if not, well, that's why they are only suggestions...

Joe J.

[KenWittlief]

as an engineer I have to say, a closed loop feedback control system is way more accurate and precise than any human on joystick could ever be.

Humans have eye to hand coordination at best around 1/10th of a second (100mS). The loop in the RC runs about ten times faster than that.

If a PID control robot drives worse than open loop, then something is not right with the control system: slop/backlash in the drive train, faulty sensors, PID gains not set for optimum response.

seriously, try to out calculate your calculator.

The one version of PID control I have seen used very successfully is a solid state yaw rate sensor (gyro chip) used to sense robot turn rate, and using a one joystick control setup. Then its very easy to use the turn rate from the gyro chip to close the loop on steering. This is exceptional when going up ramps and stuff, if your bot trys to turn sideways on the way up, and your driver is pushing the joystick straight, the PID loop will keep it going straight no matter what!

[Rick TYler]

The one version of PID control I have seen used very successfully is a solid state yaw rate sensor (gyro chip) used to sense robot turn rate, and using a one joystick control setup. Then its very easy to use the turn rate from the gyro chip to close the loop on steering. This is exceptional when going up ramps and stuff, if your bot trys to turn sideways on the way up, and your driver is pushing the joystick straight, the PID loop will keep it going straight no matter what!

This is exactly what our software team is working on. They've asked me to look around for some sample PID code using the gyro. Our gyro is working (as is the camera), but they haven't integrated everything yet.

Anyone feel like helping point us to a sample?

[Salik Syed]

that yaw correction w/ gyro is a really good idea... i think i may try this!

[Jared Russell]

Gyro yaw correction sample pseudocode:
--------
Angular_Vel = Gyro_Value - GYRO_CENTER;
Error = Desired_Angular_Vel - Angular_Vel; // Set Desired to 0 to go straight

Left_Drive += K * Angular_Vel;
Right_Drive -= K * Angular_Vel;

--------

Define K to be a constant somewhere.
The +/- may vary depending on the gyro orientation (upside down) or drivetrain definition of forward.
Also, be sure to check the bounds on your drive motors (final value must be between 0 and 254).
Watch the types (signed, unsigned, char, int) you choose so as not to overflow.

[CronosPrime1]

Honestly, I don't know why everyone does not like the direct joystick to PWM value mapping. All it takes is some driving experience. In the time it takes you to get a program for manual velocity PID working, you could instead become an experienced robot driver. You really could. And you would not clutter up unnecessary space on your robot controller. And you would save yourself many headaches. If there is some specific time when you need slow and precise control (say, for making a ramp when it is being cluttered by the two other robots), you could implement a half-velocity switch - press a switch, and the joystick inputs are reduced by half.

[Astronouth7303]

Honestly, I don't know why everyone does not like the direct joystick to PWM value mapping. All it takes is some driving experience. In the time it takes you to get a program for manual velocity PID working, you could instead become an experienced robot driver. You really could. And you would not clutter up unnecessary space on your robot controller. And you would save yourself many headaches. If there is some specific time when you need slow and precise control (say, for making a ramp when it is being cluttered by the two other robots), you could implement a half-velocity switch - press a switch, and the joystick inputs are reduced by half.


We have program memory to burn
I doubt anyone can aim their cannon that accurately using straight PWMs
Doesn't help you in autonomous
If we didn't screw around with PID, we'd be out of a job.
What if the driver stayed up a little too late last night and his/her abilities are not showing today?
Sometimes, 8-bit resolution just isn't enough
If your motors are a little off on one side, your drivers are going to be cursing
PID is pimp when done right
What about 2/3s velocity? 1/2 can be slow, and you only got 40 seconds before having to go do something else
There is a sense of accomplishment when you get through the headaches


Now be quiet and tune your loops. ;)

[Jared Russell]

Honestly, I don't know why everyone does not like the direct joystick to PWM value mapping. All it takes is some driving experience. In the time it takes you to get a program for manual velocity PID working, you could instead become an experienced robot driver. You really could. And you would not clutter up unnecessary space on your robot controller. And you would save yourself many headaches. If there is some specific time when you need slow and precise control (say, for making a ramp when it is being cluttered by the two other robots), you could implement a half-velocity switch - press a switch, and the joystick inputs are reduced by half.

One word: Intangibles.

A feedback loop will work regardless of battery problems, frictional differences, incidental contact...last year we lost a drive motor and our feedback algorithm compensated correctly so the driver didn't even notice until we got back to the pit!

[Rick TYler]

Yeah, but, writing PID from scratch is hard. Does anyone have some sample code I could show to our student programmers?

[Mike Shaul]

Here is some basic P control code, let me know if anyone catches an error! :)


#define GAIN 10 //This will need to be tuned

u8 p_control(u16 desired, u16 actual)
{
s16 error, control;

error = desired - actual;
control = error * GAIN;
if( control > 504 )
control = 504;
else if( control < -504 )
control = -504;

control /= 4; /* Convert to 8-bits */

return (u8)(control +127); /* PWM Output */
}

[Jared Russell]

Here is some basic P control code, let me know if anyone catches an error! :)


#define GAIN 10 //This will need to be tuned

u8 p_control(u16 desired, u16 actual)
{
s16 error, control;

error = desired - actual;
control = error * GAIN;
if( control > 504 )
control = 504;
else if( control < -504 )
control = -504;

control /= 4; /* Convert to 8-bits */

return (u8)(control +127); /* PWM Output */
}

You can replace the line:

control /= 4;

with:

control >> 2;

But that's about it - otherwise it works.

[Mike Shaul]

Also, here is a great article that explains the implementation of a full PID control as well as the behavior of each stage.

PID without a PhD (http://www.embedded.com/2000/0010/0010feat3.htm)

[Tom Bottiglieri]

For anyone who has utilized a differential term in their control loop, did you use the timing of the default routine or set up an timed interrupt driven differential calculation?

I know the default code loops at ~26ms, but is its rate of repitition constant enough to house the differential term calculation?

[Jared Russell]

I find that the default 39Hz main loop is fast enough for any feedback applications in FIRST, and it is fairly well timed as long as you don't go overboard on the interrupts.

Besides, the closer together your differential term calculations are, the less resolution you have in them (i.e. you couldget 5-10 "ticks" difference on a 100Hz loop but the same rate would produce 12-25 on 39Hz).

[Joel J]

You can replace the line:

control /= 4;

with:

control >> 2;

But that's about it - otherwise it works.
if control can be negative, then a right shift can have a disastrous effect! mcc18 v2.4 does NOT shift in 1's for a negative number. Instead, it treats all numbers as unsigned.

For example,

int control = -16;
control = control >> 2;

After that snippet, you'd expect control to be -4, but in actuality its 16380. Quite different.

[kaszeta]

if control can be negative, then a right shift can have a disastrous effect! mcc18 v2.4 does NOT shift in 1's for a negative number. Instead, it treats all numbers as unsigned.

For example,

int control = -16;
control = control >> 2;

After that snippet, you'd expect control to be -4, but in actuality its 16380. Quite different.

Indeed, our team learned that lesson the hard way....

[Jared Russell]

if control can be negative, then a right shift can have a disastrous effect! mcc18 v2.4 does NOT shift in 1's for a negative number. Instead, it treats all numbers as unsigned.

For example,

int control = -16;
control = control >> 2;

After that snippet, you'd expect control to be -4, but in actuality its 16380. Quite different.

Wow - I definately would have thought that a shift would extend the sign.

I guess I should have RTFM. ;)

[Astronouth7303]

Yeah, but, writing PID from scratch is hard. Does anyone have some sample code I could show to our student programmers?

The Navigation code Kevin made for last year's robot has PID in it.

And it's pretty easy.

error = current - target
integral += error
derivative = error - prevError
output = Kp * error + Ki * integral + Kd * derivative
prevError = error


(The implementation details are left to the reader ;) )