Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   NI LabVIEW (http://www.chiefdelphi.com/forums/forumdisplay.php?f=182)
-   -   Driving Straight (http://www.chiefdelphi.com/forums/showthread.php?t=129795)

Bpk9p4 16-06-2014 09:19
Driving Straight
 
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 16-06-2014 09:37
Re: Driving Straight
 
Quote:
Originally Posted by Bpk9p4 (Post 1390047)
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 16-06-2014 09:41
Re: Driving Straight
 
Quote:
Originally Posted by notmattlythgoe (Post 1390048)
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 16-06-2014 09:44
Re: Driving Straight
 
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 16-06-2014 09:44
Re: Driving Straight
 
Quote:
Originally Posted by Jon Stratis (Post 1390049)
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 16-06-2014 09:45
Re: Driving Straight
 
Quote:
Originally Posted by Bpk9p4 (Post 1390051)
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 16-06-2014 09:49
Re: Driving Straight
 
With the slave and master configuration how do you deal with turning? Would you mind drawing a flowchart?

notmattlythgoe 16-06-2014 09:52
Re: Driving Straight
 
Quote:
Originally Posted by Bpk9p4 (Post 1390054)
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 16-06-2014 09:56
Re: Driving Straight
 
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 16-06-2014 10:07
Re: Driving Straight
 
You can use the encoders to emulate a gyro for driving straight. Here is some psuedo-code for how to do it:

Code:

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 16-06-2014 10:15
Re: Driving Straight
 
Quote:
Originally Posted by notmattlythgoe (Post 1390052)
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 16-06-2014 11:00
Re: Driving Straight
 


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 16-06-2014 11:01
Re: Driving Straight
 
Quote:
Originally Posted by Jon Stratis (Post 1390059)
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 16-06-2014 11:51
Re: Driving Straight
 
Quote:
Originally Posted by Jon Stratis (Post 1390049)
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 16-06-2014 11:59
Re: Driving Straight
 
Quote:
Originally Posted by Joe Ross (Post 1390064)
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.

Bpk9p4 16-06-2014 12:44
Re: Driving Straight
 
Quote:
Originally Posted by Chris Hibner (Post 1390058)
You can use the encoders to emulate a gyro for driving straight. Here is some psuedo-code for how to do it:

Code:

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 16-06-2014 12:55
Re: Driving Straight
 
Quote:
Originally Posted by Bpk9p4 (Post 1390067)
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 18-06-2014 13:42
Re: Driving Straight
 
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 08-08-2014 04:45
Re: Driving Straight
 
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 13-11-2015 11:26
Re: Driving Straight
 
Quote:
Originally Posted by Chris Hibner (Post 1390058)
You can use the encoders to emulate a gyro for driving straight. Here is some psuedo-code for how to do it:

Code:

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 13-11-2015 11:40
Re: Driving Straight
 
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 13-11-2015 17:48
Re: Driving Straight
 
Quote:
Originally Posted by adciv (Post 1390356)
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 13-11-2015 20:42
Re: Driving Straight
 
Quote:
Originally Posted by dubiousSwain (Post 1505090)
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 14-11-2015 00:21
Re: Driving Straight
 
Quote:
Originally Posted by GeeTwo (Post 1505109)
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 19-11-2015 08:59
Re: Driving Straight
 
Quote:
Originally Posted by GeeTwo (Post 1505109)
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 27-11-2015 23:33
Re: Driving Straight
 
1 Attachment(s)
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 28-11-2015 11:45
Re: Driving Straight
 
1 Attachment(s)
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


All times are GMT -5. The time now is 17:48.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi