Driving Straight

[Bpk9p4]

Originally Posted by 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.

I really like this gyro idea i will have to give it a try.

I am only going to be using this outside of auto. During auto we use a gyro.

The method i am trying now is to use a velocity control PID for each side. however it would be nice to have a slave/master configuration but i am not sure hot to deal with turning

[notmattlythgoe]

Originally Posted by Bpk9p4

I really like this gyro idea i will have to give it a try.

I am only going to be using this outside of auto. During auto we use a gyro.

The method i am trying now is to use a velocity control PID for each side. however it would be nice to have a slave/master configuration but i am not sure hot to deal with turning

For long uses of a gyro make sure to take into account the gyro's drift.

[adciv]

We've found LabView compensates fairly well for the drift. We usually see a few degrees per minute, which has been more than accurate enough for our matches. If you need more than that, you can extend the duration it uses to measure the drift.

[lakecat]

I believe that the CAN bus library has built in PID. All we had to do last year was set it to speed control mode and to read off the encoder.

[mschwab013]

Originally Posted by 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.

I'm currently trying to implement a very similar system and was wondering if you had any recommendations for tuning the PID constants and the "leadFactor" at the same time

[aeastet]

We used the gyro for driving straight for Auto and during the matches this year. The gyro is the easiest way to make sure you are going in a certain direction. We used the drive straight to drive to the step and drive straight to back up from the step. This way we did not knock over a stack of totes. We had a lance sticking out that we used for auto to move the recycle bins out of the way. If the driver turned while backing up it would move the stack. This function to drive straight back was a huge hit with the drivers.

The NavMXP had very little drift. We left it running for 20 minutes one time and had no drift. Way better than the old kit gyro. If you are trying to drive straight and you have a gyro why would you do it any other way?

Tim

[dubiousSwain]

Originally Posted by adciv

We've found LabView compensates fairly well for the drift. We usually see a few degrees per minute, which has been more than accurate enough for our matches. If you need more than that, you can extend the duration it uses to measure the drift.

Its important to tune your gyro properly or you'll get noise and drift. 316 ran into this problem last year.

[GeeTwo]

Originally Posted by dubiousSwain

Its important to tune your gyro properly or you'll get noise and drift. 316 ran into this problem last year.

As with so many things, it's important to understand how much noise and drift you can accept. If you're only using the gyro for autonomous (15 seconds long) or to do short-term maneuvers (like backing up in a straight line without your probe knocking down a stack), you can allow significantly more drift than if you're expecting your "arena coordinates" mecanum drive to be stable through a full 2-1/2 minute match. If you're looking for full-match alignment and can't get it from your gyro or encoders, consider if your strategy puts you up against a wall or other well-defined feature of the field on a regular basis, and see if you can use that as an opportunity for a heading correction.

[Ari423]

Originally Posted by GeeTwo

As with so many things, it's important to understand how much noise and drift you can accept. If you're only using the gyro for autonomous (15 seconds long) or to do short-term maneuvers (like backing up in a straight line without your probe knocking down a stack), you can allow significantly more drift than if you're expecting your "arena coordinates" mecanum drive to be stable through a full 2-1/2 minute match. If you're looking for full-match alignment and can't get it from your gyro or encoders, consider if your strategy puts you up against a wall or other well-defined feature of the field on a regular basis, and see if you can use that as an opportunity for a heading correction.

We never got it fully implemented in a competition robot, but we made code last year that would use the output from two ultrasonic sensors to detect the angle the robot was at compared to a flat wall. When we would click a button on the dashboard corresponding to which wall the robot was facing, it would automatically reset the gyro to the measured angle away from the angle of the wall (+/- 90 for side walls, 180 for back wall). This meant we wouldn't have to slam against a wall to reset the gyro, we just had to drive up to it at a not-too-shallow angle.

[aeastet]

Originally Posted by GeeTwo

As with so many things, it's important to understand how much noise and drift you can accept. If you're only using the gyro for autonomous (15 seconds long) or to do short-term maneuvers (like backing up in a straight line without your probe knocking down a stack), you can allow significantly more drift than if you're expecting your "arena coordinates" mecanum drive to be stable through a full 2-1/2 minute match. If you're looking for full-match alignment and can't get it from your gyro or encoders, consider if your strategy puts you up against a wall or other well-defined feature of the field on a regular basis, and see if you can use that as an opportunity for a heading correction.

We actually had our NavMXP gyro running for over 20 minutes with only 1 degree of error the whole time. The NavMXP Gyro has been one of the most awesome finds I have had for the years that I have been coaching. I did a little work to the code from NavMXP but I do not see drift specially in the two minutes of the game. Our auto went 12 for 12 at world championships and was about 95% the rest of the year. We turned and drove straight many times throughout the match. The old kit of parts gyro was a waist of time. I am tell everyone that I see that this one is for real.

[Skyehawk]

Here is a comparison based "drive straight" code example that doesn't use PIDs. It is handy for demonstrations, programming practice, etc. where you need to be able to follow along without getting wrapped up in more advanced functions (such as PIDs) useful, like it was said before, if the user hasn't taken basic calculus. Works like a charm, it may be a little sparsely commented, but just PM me if you have any questions.

FYI: Top encoder is left side, bottom is right side. This code makes the robot REVERSE at 50% speed. (I just pulled it out of one of our autonomous routines).

The .06125 constant is "inches traveled/encoder tick" (you will need to update this to accommodate for your drive train reduction between the encoder shaft and the wheels).
The 85 constant is the desired distance in inches.

You can import this vi code snippet into Labview.

Cheers,
Skye

[Greg McKaskle]

I've seen a number of FLL teams use an approach similar to what I attached. They will have three to five cases where they tune the coefficients or return hard-coded numbers. Sometimes the sensor is an ultrasonic sensor to follow a wall instead of two encoders. Sometimes they reset the sensors inside the loop instead of accumulating.

These approaches work pretty well if the loop runs fast enough. It gives them a piece to tune and once they gain a sense of how the control works, you can add storage and have both integrated and term-to-term error, and pretty soon you have a simple PID, or at least the portion of it that you need for that problem.

Since FRC robots take lots of space and infrastructure to run, you may find it useful to use a smaller robot to structure the code, then try it out on an FRC bot.

Greg McKaskle