Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   Programming (http://www.chiefdelphi.com/forums/forumdisplay.php?f=51)
-   -   Robot Drifting (http://www.chiefdelphi.com/forums/showthread.php?t=25212)

AsimC 13-02-2004 10:50

Robot Drifting
 
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. 13-02-2004 11:03

Re: Robot Drifting
 
Quote:

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:
Code:

// 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 13-02-2004 11:36

Re: Robot Drifting
 
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 13-02-2004 11:36

Re: Robot Drifting
 
Quote:

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 13-02-2004 11:51

Re: Robot Drifting
 
Software fixes to mechanical problems... eek! :p

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 13-02-2004 11:58

Re: Robot Drifting
 
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 13-02-2004 12:04

Re: Robot Drifting
 
Quote:

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 13-02-2004 19:22

Re: Robot Drifting
 
Quote:

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?

Rich Kressly 13-02-2004 21:12

Re: Robot Drifting
 
Quote:

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 13-02-2004 22:12

Re: Robot Drifting
 
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

Mark McLeod 13-02-2004 22:52

Re: Robot Drifting
 
Quote:

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:
Code:

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 14-02-2004 16:15

Re: Robot Drifting
 
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. 14-02-2004 17:38

Re: Robot Drifting
 
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.

steven114 14-02-2004 23:18

Re: Robot Drifting
 
Quote:

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

Might I point out that 150/100 will evaluate to 1, not 1.5... there is no way to store a floating point number in an integer. You can hack around it by storing an exponent, but I don't believe setting myInt to 150/100 will store 1.5...

Aignam 14-02-2004 23:31

Re: Robot Drifting
 
I spent the entire day yesterday, and 2 hours today learning to stop our 2003 robot on a dime in a 30 by 36 box when driving from about 10 feet away. Yes, the robot drifts. Yes, it is really annoying to have to compensate for it. Yes, this is going to happen in real matches. Yes, I'm going to shut up and deal with it. Just have your driver prepare for it.


All times are GMT -5. The time now is 04:21.

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