Drivetrain PID tuning

[ollien]

Today, I was encouraging my rookie programmers to utilize the NavX to experiment with PID Control in order to make our robot drive straight. Given that we've never done this in a season, one of the things that crossed my mind is how we should deal with the differences in CoFs between our lab's carpet and that of a true to life field. What have other teams done to account for this? Have you guys just purchased carpet, and just calibrated it on that? What would you use to re-tune your loop at competition?

Thanks so much!

[Jared Russell]

Sensitivity to carpet variation is somewhat dependent on your drivetrain geometry and dynamics. A 6 wheel drive, dropped-center robot with a roughly central CoM and hard wheels is going to turn pretty similarly on a wide variety of floor surfaces. Meanwhile, a 4 wheel drive robot with a long wheelbase and pneumatic wheels may scrub quite differently depending on carpet.

Ideally your PID algorithm can be tuned to compensate for various types of floor conditions (after all, well-worn vs. brand new field carpet can be quite different in its own right!). If you are able to control your robot on a couple different types of surfaces at home (including whatever you have that is most similar to the field surface), you ought to be good when you get to competition.

[beijing_strbow]

We're able to get pretty good straight driving using only the P term with the navX, so that may be worth trying. As for carpet, a local store gave us a 5x12 foot square of the official carpet (different color though).

[GeeTwo]

Originally Posted by beijing_strbow

We're able to get pretty good straight driving using only the P term with the navX, so that may be worth trying. As for carpet, a local store gave us a 5x12 foot square of the official carpet (different color though).

A P only loop makes sense in this application, because there is so much physical damping/resistance in the yaw of a robot; there is no need for a software dampening. The navX is likely much more dependable than the wheels for determining orientation, that I would not use drive train encoders in the navigation loop, but ONLY to to feed the wheel/motor PID loop.

As far as color, if you insist on the right color, you'd need a new piece (or two) of carpet each year.

[Oblarg]

Things to watch out for when doing this, based on personal experience:

1) It is very hard for a loop to keep you driving straight at max speed, because if your motors are saturated you can only slow down one side to adjust, rather than both slow down one side and speed up the other. If you give yourself some headroom, it will work much better.

2) Unless you are using cascading control (i.e. feeding the output of your heading loop to a wheel velocity loop), it is likely that you won't be able to make the p gain high enough on the heading loop to make steady state error acceptably small without introducing instability. A quick and dirty fix for this is to simply add or subtract some minimum output to/from the calculated heading loop output whenever it is outside of some tolerance around 0.

[sspoldi]

Originally Posted by ollien

Today, I was encouraging my rookie programmers to utilize the NavX to experiment with PID Control in order to make our robot drive straight. Given that we've never done this in a season, one of the things that crossed my mind is how we should deal with the differences in CoFs between our lab's carpet and that of a true to life field. What have other teams done to account for this? Have you guys just purchased carpet, and just calibrated it on that? What would you use to re-tune your loop at competition?

Thanks so much!

We have never needed to re-tune for a change in carpet. Our typical heading stabilization is a PI controller for angular rate via gyro to stabilize heading. We tune via the following:

1.We do a quick system id on the yaw axis
a. Apply a moderate amplitude yaw step
(usually 1/2 max input on whatever yaw command input you have)
b. Model the angular rate output with the equation
rate = input*k*(1 - exp(-t/tau))

2. design a controller using the following architecture;
error = (yaw_cmd - yaw_rate)
motor_cmd = PID(error, Kp, Ki, Kd)
where:
Kp = gain/K*tau
Ki = gain/K
Kd = 0
gain = 5 to 10 (arbitrary, desired bandwith in rad/sec);

3. Vary gain to get the command response you want. We start at 10, and if it's too sluggish bump it up, if it oscillates or limit cycles (bounces back and forth due to backlash) we back it off.

Sorry for the terse explanation, but that's pretty much it. We do all our own code, so the PI controller is just written into the yaw service function. Sorry I don't have the code right now, but I can find it.

Cheers,
Steve.

[SamcFuchs]

Can anyone explain to me why so many teams use gyros for driving straight instead of encoders?

[Ty Tremblay]

Originally Posted by SamcFuchs

Can anyone explain to me why so many teams use gyros for driving straight instead of encoders?

Wheel slip is not a factor and the sensor's value more directly represents robot angle*. That being said, there are downsides to both so it's really just team preference.

*aka "math"

[GeeTwo]

Originally Posted by SamcFuchs

Can anyone explain to me why so many teams use gyros for driving straight instead of encoders?

short answer: wheels slip.

Once the wheels have slipped against the carpet/floor/obstacle and you don't know how much, you can't reliably use the encoders (by themselves) to determine orientation. Gyros have more drift, but are not subject to this sudden loss of calibration.

[D.Allred]

Originally Posted by SamcFuchs

Can anyone explain to me why so many teams use gyros for driving straight instead of encoders?

I found it easy to implement with arcade drive. The heading loop replaces the rotate joystick.

David

[SamcFuchs]

Originally Posted by GeeTwo

short answer: wheels slip.

Once the wheels have slipped against the carpet/floor/obstacle and you don't know how much, you can't reliably use the encoders (by themselves) to determine orientation. Gyros have more drift, but are not subject to this sudden loss of calibration.

Good point. I'm used to encoders because we use them for motion profiling, which you couldn't really do with a gyro.

[SamcFuchs]

Originally Posted by Ty Tremblay

Wheel slip is not a factor and the sensor's value more directly represents robot angle*. That being said, there are downsides to both so it's really just team preference.

*aka "math"

Sure you get a number that represents your angle, but if you're trying to go a predetermined distance, encoders make corrections much easier.

[ollien]

Originally Posted by D.Allred

I found it easy to implement with arcade drive. The heading loop replaces the rotate joystick.

David

How do you accomplish this? Do you just set your setpoint proportional to the position of the stick?

[ahartnet]

Originally Posted by ollien

How do you accomplish this? Do you just set your setpoint proportional to the position of the stick?

Robot.drivetrain.arcadeDrive(DriveForwardSpeed, (Robot.drivetrain.getGyroAngle().getAngle()));

You might want/need to multiply the gyro angle by a Kp or -Kp. We actually ended up with the following:

Robot.drivetrain.arcadeDrive(-DriveForwardSpeed, (-(Robot.drivetrain.getGyroAngle().getAngle()) * Kp+.1));

[Jared Russell]

Originally Posted by SamcFuchs

Good point. I'm used to encoders because we use them for motion profiling, which you couldn't really do with a gyro.

You can definitely do motion profiling with a gyro.