Robot Drifting

[AsimC]

Our team is having trouble with our robot drifting to the right while driving straight. We feel that is because one drill motor is running in reverse. I know there is a way to compensate for in in the programming but im not really sure how to do it. Would the Current Sensors help in programming the motors? Any suggestions or examples of code would be very helpful to us. Thanks alot.

[Ryan M.]

Originally Posted by AsimC

Our team is having trouble with our robot drifting to the right while driving straight. We feel that is because one drill motor is running in reverse. I know there is a way to compensate for in in the programming but im not really sure how to do it. Would the Current Sensors help in programming the motors? Any suggestions or examples of code would be very helpful to us. Thanks alot.

The easiest way to do this is to have to enocders on the dirve wheels. FIgure out using those how much faster the one motor is turning than the other. From that figure out how much of a reduction in PWMs you need to make them balance and store that value in a #define. Use the define as an addition/subtraction to what you would normally be putting out on the fast side. If the difference between the motors ever changes, just change the #define value, recompile, and download.

Here is a quick example:

// Somewhere t the top of the file. Comp is short for compensation
// This is the amount of difference in PWMs that makes the motors approzimatly even
#define COMP_SPEED 15
 
 
// In some function that use the motors.
// Go forward. pwm02 is on the slow side
pwm01 = 255;
pwm02 = 255 - COMP_SPEED;
 
// At some later point in the function.
// Go in reverse.
pwm01 = 0;
pwm02 = 0 + COMP_SPEED; // The 0 isn't nessecary, it's just there to illustrate the point

That isn't the optimal solution, of course. The best idea is to have your program monitoring the enocoders and if it sees one side going faster than the other when it shouldn't be, it autonomatically corrects. But, that is more complicated and you should be able to get away with the first solution.

[Kevin Sevcik]

I don't think that'll work quite like you intend. It'll work fine for autonomous mode dead reckoning, but not for normal driving, really. I'd think in normal driving, the difference would scale with the speed of the motors, and you'd need a more complicated function to figure out the compensation.

In addition, your reverse compensation isn't right. Remember, when you're going in that direction, the motor that's normally going in reverse is now going forwards. It's now the one that needs to be compensated. The reverse direction should be:

pwm01 = 0 + COMP_SPEED;
pwm02 = 0;

[Mark McLeod]

Originally Posted by AsimC

Our team is having trouble with our robot drifting to the right while driving straight. We feel that is because one drill motor is running in reverse. I know there is a way to compensate for in in the programming but im not really sure how to do it. Would the Current Sensors help in programming the motors? Any suggestions or examples of code would be very helpful to us. Thanks alot.

There are lots of ways to handle this.

The right/left drivetrains are rarely 100% balanced, so you should always be able to adjust for it in the code as necessary. Be aware that every time you adjust the drive system (replace a wheel, fix the alignment) you need to revisit the code adjustment.

An easy method is to first assume the difference is linear and adjust the more powerful side down to match the less powerful side as a percentage of full power. These will of course be different for driving forwards and backwards, so add an if statement for that.




e.g.,

stronger side power = current power - (current power/full power * constant)


weaker side power = current power

The simplest way to select constant is:


- Run the robot at full power and note which side lags.
- Pick a value for constant above, put it into the code and run the robot again.
- Repeat until you are driving straight.

Remember that constant doesn't have to be restricted to integers like 1,2,3,..
It can be a #define like "#define CONSTANT 150/100" to get a value of 1.5 without using floating point #'s.

[Matt Adams]

Software fixes to mechanical problems... eek!

If your robot is drifting... there's one quick thing that you should look at right away... this is a very typical situation, but it can often (but not always) be adjusted by shifting your weight distribution.

The drill motors do not run in the same speed forward and backward, if this is what you're using, (or even if you're not) perhaps you could shift some weight around your robot to the side opposite of where you're drifting... i.e. if you're drifting to the right, try to move some weight on the left side.

Mind you that in reverse, drifting will be more significant if you're evenly balanced via weight in forward. Maybe you'll balance this by software in reverse, since you can try to avoid needing to drive accurate and pushing in that direction.

In general, try to do as much as you can mechanically, and don't try to kill your robot's power input through software... your drivers wil want every ounce of it!

Good luck!

Matt

[JVN]

I can't believe all the solutions which have been mentioned so far as the "simplest".

The SIMPLEST solution, is to teach your driver to live with it, and account for the drift when he/she is on the field. It's not that difficult...

Human controlled, dynamically adjusted voltage scaling. (Also known as HuCDAVS), is a simple control method that involves holding one joystick a little bit further forward than the other.

John

[Mark McLeod]

Originally Posted by JVN

Human controlled, dynamically adjusted voltage scaling. (Also known as HuCDAVS), is a simple control method that involves holding one joystick a little bit further forward than the other.

John

Sadly, HuCDAVS have been ruled illegal by FIRST during autonomous mode.

I will note that we don't usually apply this software fix when our HuCDAVS is operable.

[AsimC]

Originally posted by Mark McLeod
e.g.,
stronger side power = current power - (current power/full power * constant)
weaker side power = current power

When you say current power...where am i getting this number from?

[Mark McLeod]

Originally Posted by AsimC

When you say current power...where am i getting this number from?

That's your normal pwm output value.

This is a more concrete example using a joystick value to drive:

int temp; // use to hold signed pwm value (-127 to 127) for simpler math
 
pwm13 = p1_y; // (or whatever your normal power calculation is)
temp = pwm13 - 127;  // convert to human math:) 
temp = temp - (temp/127 * 10);
pwm13 = temp + 127; // convert back to normal 0-254 range

[AsimC]

Thank you so much. Im going to try it on tuesday when we get back to working on the bot and hope it works.

[Adam Y.]

Can the drill motors polarity be reversed on one of them? Check the cans for the positive above the one brush. Also is one tire gaining more traction than the other. I noticed today that an extreme of what you are describing happened in last years robot. The frame was so warped that the robot was actually swerving since one wheel was not getting enough traction.

[The Lucas]

Originally Posted by Mark McLeod

Sadly, HuCDAVS have been ruled illegal by FIRST during autonomous mode.

I will note that we don't usually apply this software fix when our HuCDAVS is operable.

How about just using a gyro to keep a true bearing durng autonomous. Otherwise, I'm with John, HuDAVS is the way to go. You are just limiting your total drive train power with any other method.

[Mark McLeod]

Originally Posted by The Lucas

How about just using a gyro to keep a true bearing durng autonomous. Otherwise, I'm with John, HuDAVS is the way to go. You are just limiting your total drive train power with any other method.

We use three methods: a gyro, the IR, and shaft encoders to maintain heading, position, and orientation during autonomous, but that doesn't help teams that don't have them. The method I suggest is for teams without any of these. It's essential if you are using true dead-reckoning.

We don't use any of them during driving mode, although we do sometimes modify the power curve to give more range at the low-end.

There are lots of answers and you'll see as many software solutions as robot solutions to FIRSTs game. It's part of what makes it all so interesting.

[Rich Kressly]

Originally Posted by JVN

I can't believe all the solutions which have been mentioned so far as the "simplest".

The SIMPLEST solution, is to teach your driver to live with it, and account for the drift when he/she is on the field. It's not that difficult...

Human controlled, dynamically adjusted voltage scaling. (Also known as HuCDAVS), is a simple control method that involves holding one joystick a little bit further forward than the other.

John

Amen. We've always had tremendous success using the "learn to deal with it method."

[team222badbrad]

Simple solution?

next year make sure both motors are running in the same direction...

or if time/design allows fix it before ship date!

we have been doing this for 2 years now