Driving Straight

[Bpk9p4]

One of my off season projects it to try and get are robot to drive straight. I know you can do this with a gyro but i was wondering if there was any other methods people have used.

[notmattlythgoe]

Originally Posted by Bpk9p4

One of my off season projects it to try and get are robot to drive straight. I know you can do this with a gyro but i was wondering if there was any other methods people have used.

We have used encoders to measure the distance traveled on each side of the drive train and compensate if one got too far ahead of the other.

[Jon Stratis]

Originally Posted by notmattlythgoe

We have used encoders to measure the distance traveled on each side of the drive train and compensate if one got too far ahead of the other.

It's better to use encoders to measure the speed of the wheels in a PID loop to control them properly. With that, the PID loop will ensure the sides of the drive train are going at the correct speed.

I would only use distance from an encoder in autonomous, when you need to travel to a specific point as part of your routine.

[Bpk9p4]

I was trying the encoder and PID method over the weekend. I was not sure if i should have a PID controller for both sides or have a slave masters configuration. Which have you used

[notmattlythgoe]

Originally Posted by Jon Stratis

It's better to use encoders to measure the speed of the wheels in a PID loop to control them properly. With that, the PID loop will ensure the sides of the drive train are going at the correct speed.

I would only use distance from an encoder in autonomous, when you need to travel to a specific point as part of your routine.

Would you mind explaining why one way is better than the other? As one side starts to travel further than the other side the PID loop speeds the corrected side of the drive train up. It's the same effect using a different measurement. We're measuring the difference in speed in the distances traveled compared to the actual speed value.

[notmattlythgoe]

Originally Posted by Bpk9p4

I was trying the encoder and PID method over the weekend. I was not sure if i should have a PID controller for both sides or have a slave masters configuration. Which have you used

Ours uses a slave/master. We correct the one sides speed depending on the differences in the distances using a PID loop.

[Bpk9p4]

With the slave and master configuration how do you deal with turning? Would you mind drawing a flowchart?

[notmattlythgoe]

Originally Posted by Bpk9p4

With the slave and master configuration how do you deal with turning? Would you mind drawing a flowchart?

Are you just trying to drive straight or are you trying to find a way to very precisely control both sides of the drive train (assuming a skid steer)?

[Aaron.Graeve]

Drive straight in what portion of the game? It is much easier in autonomous since you know what path the robot will be taking and can plan acordingly. Not so during teleop. Regarding the softaare side, a gyro would be your best bet, as it was designed to measure the heading of the robot. During auto, you can get away with just an encoder on each side of the drivetrain and work towards mathing speeds.

If you do not have any sensors, you can try applying a proportionally different power value to each side (e.g. after you get the final motor values from the joysticks,run the left motors at 80% and the right ones at 100%). You could try to figure out the function that each side of the drivetrain is following (speed of wheels based on motor value) and compensate that way. The function method would be the more complicated form of a simple power scaling factor, but an underlying issue exists.

Since you are trying to compensate for a mechanical problem in software, without a closed loop system (sensor and PID), the robot will only drive straight as long as the drive train does not change (including gear bindings or re-greaseing). You could get it "close enough", but it would be suseptable to the quality of repairs, the weather that day, and the mechanical sub-team. That doesn't sound fun does it.

[Chris Hibner]

You can use the encoders to emulate a gyro for driving straight. Here is some psuedo-code for how to do it:

heading = 57.3*(leftEncDist - rightEncDist) / trackWidth;

if (abs(driverTurnCmd) < turnDeadZone)
{
  if (headingCaptured == FALSE)
  {
     desiredHeading = heading;
     headingCaptured = TRUE;
  }
  turnCmdPID = PID(heading, desiredHeading);
  arcadeDrive(driverThrottleCmd, turnCmdPID);
}
else
{
  headingCaptured = FALSE;
  arcadeDrive(driverThrottleCmd, driverTurnCmd);
}

When we've done this in the past, it makes it a little smoother if you lead your desired heading with your turn rate. So instead of "desiredHeading = heading" in the above code, we've done "desiredHeading = Heading + robotTurnSpeed * leadFactor", where "leadFactor" is a calibration that you tune to make the stopping of the turn smooth.

[Jon Stratis]

Originally Posted by notmattlythgoe

Would you mind explaining why one way is better than the other? As one side starts to travel further than the other side the PID loop speeds the corrected side of the drive train up. It's the same effect using a different measurement. We're measuring the difference in speed in the distances traveled compared to the actual speed value.

How often, outside of auto, are you instructing the robot to drive exactly straight? Joysticks work by defining the speed of your drive train, not the distance traveled. Using the encoders to measure distance traveled requires you to pick some arbitrary time interval to use to convert between the encoder feedback and the joystick input. If you pick an interval that's too large, you'll notice significant challenges as the robot drifts one way, then compensates by drifting back the other way. If you pick one sufficiently small, then you're basically doing exactly what the encoder class does for you when you use it for speed - taking the number of ticks over a set period of time to determine the speed.

[Ether]

This discussion reminded me of something I posted a couple of years ago.

For any students interested in some math:

http://www.chiefdelphi.com/forums/sh...5&postcount=26

[Owen Makin]

Originally Posted by Jon Stratis

How often, outside of auto, are you instructing the robot to drive exactly straight? Joysticks work by defining the speed of your drive train, not the distance traveled. Using the encoders to measure distance traveled requires you to pick some arbitrary time interval to use to convert between the encoder feedback and the joystick input. If you pick an interval that's too large, you'll notice significant challenges as the robot drifts one way, then compensates by drifting back the other way. If you pick one sufficiently small, then you're basically doing exactly what the encoder class does for you when you use it for speed - taking the number of ticks over a set period of time to determine the speed.

This is why you should understand calculus before doing PID's. The derivative of the curve of distance traveled, is the curve of the velocity, or speed, which is why you should use the velocity curve becausr it is the most accurate.

[Joe Ross]

Originally Posted by Jon Stratis

It's better to use encoders to measure the speed of the wheels in a PID loop to control them properly. With that, the PID loop will ensure the sides of the drive train are going at the correct speed.

Does 2177 do this? My impression is that very few teams do, because it's hard to tune. If you do, it would be a great whitepaper.

[notmattlythgoe]

Originally Posted by Joe Ross

Does 2177 do this? My impression is that very few teams do, because it's hard to tune. If you do, it would be a great whitepaper.

This is why we haven't done it. We get a much better signal counting distance than we do speed and it is much easier to tune the PID controller since it doesn't need to be as precise.