# FRC Driving Straight

I have two questions concerning using PID to make a robot drive straight during the autonomous period (we have a tank drivetrain). The first is which is better to use for sensor inputs: one encoder + NavX Gyro or two encoders. The second question to follow up with that: is it better to use two concurrent PID loops to correct straightness along with distance (and if so, how?) or is it better just to use a while loop for the distance and PID for the angle correction?

This depends on a lot of things. For really accurate straight driving I would actually recommend a navX and two encoders. This way you can run Pid with a navX to get velocity per-side adjustments and pid with the encoders to make those adjustments accurate.
If you’re looking for driving to a specific distance., you might try driving straight until a certain distance away from the target then running position PID on encoders to land right at your target position. However, with two encoders and a navX you may want to look into pathfinder.

Well, starting with PID on wheel velocity is the right move. Then, you could use a PID loop on angular velocity with the output feeding into a modifier ratio between the L and R wheels (ex. if the PID output is 0.2 and the left and right commanded speed is 0.6, instead set the left to be 0.6-0.2*0.6=0.48 and right to be 0.6+0.2*0.6=0.72), in order to enforce a consistent, speed-independent offset.

First let’s address the encoders. If you’re running a tank drive, using two encoders to measure distance and averaging them will negate turning effect. If you don’t use this process, any turn will change the distance your robot sensors report.

Next, running on just encoders to handle angle is usually a bad idea. When your wheels slip, you will lose accuracy.

Using the encoders to measure distance and the gyro to handle angle is pretty easy. But it isn’t the best solution. Most teams who do it this way just use an average encoder value for distance and use the gyro for angle.

The current ‘best’ solution is to use the encoders to follow a given path, and use the gyro concurrently to insure any slip is corrected for. This is an order of magnitude harder.

To slightly rephrase, sounds like the problem statement is “drive straight over a precise distance”.

In which case, I think your best answer is two encoders + gyro.

When you have multiple sensors measuring the same thing (in this case, drivetrain motion), and you are attempting to combine their readings together, to control your robot toward a desired outcome, you’re doing something called sensor fusion.

A general principle of sensor fusion: More sensors is better, assuming you properly account for the limitations of each sensor.

Things like Kalman Filters are the mathematically rigorous way of doing this. However, you don’t need to be mathematically rigorous to apply the concept in simple cases.

Heuristically, the encoders are your first line of defense to ensure your drivetrain is at the desired location on the field. However, encoders loose their accuracy when your wheels slip against the ground. This is where a gyro becomes useful, as it can (with a few caveats) tell you the absolute direction you’re pointed in. By calculating a “correction factor” based on the error in direction, and feeding that back to the drivetrain, you can use the gyro to help overcome the limitations of the encoders.

Concretely, the formula that’s worked well for Casserole over the past few years for driving straight, and along curved paths:

1. Tune PIDF algorithms for each side of the drivetrain independently, which accurately control the rotational velocity of each set of wheels.
2. Use a motion profiler to generate a time-series of velocity commands, which theoretically move the robot from the start location to the end location. By using smooth velocity profiles (ie - Pick \theta_{wheel}(t)'s to minimize \frac{d\theta_{wheel}}{dt} within constraints of error in drivetrain X/Y position), we ensure that the PIDF doesn’t have to work too hard to keep the wheels moving at the commanded velocity.
3. The motion profiler also generates a time-series of expected heading throughout the path. Subtract this desired heading from the actual heading (as measured by a gyroscope).
4. Apply this error as a “correction factor” in commanded RPM to each side of the drivetrain. This will induce rotation of the drivetrain in an attempt to correct for heading errors.

One big limitation of this process is that large correction factors in (4) cause the final location of the drivetrain to be inaccurate. However, (4) should only come into play if we’ve had lots of wheel scrub and slip. In this case, we already have lost accurate drivetrain position information, so I’m not sure if there’s a ton more we could do without another sensor.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.