|
|
|
![]() |
|
|||||||
|
||||||||
We built this reverse drive so the robot will drive straight with out programing. It was easy to build and we will be testing it on our robot soon. We had it modified in 3 hours.
02-10-2010 03:05
Chris is meTwo things:
1. What's a reverse drive?
2. Do most teams need programming for straight driving, or have I just been on two incredibly lucky teams?
02-10-2010 03:30
Aren_Hill
|
Two things:
1. What's a reverse drive? 2. Do most teams need programming for straight driving, or have I just been on two incredibly lucky teams? |
02-10-2010 03:33
AdamHeard
We've never had issues either, the CIMs are neutrally timed as far as I know. Differences in speeds are more commonly from extra friction.
02-10-2010 09:31
joeweberWe have always had trouble during autonomous mode. The robot always wanders to the left and we have to program it out. All electric motors go faster one direction than the other. This is a very simple fix.
02-10-2010 09:49
apalrd
If you don't have the programming skills, I could send you some simple LabVIEW code to drive straight, using kit encoders. Just PM me if you want it. It's a simple drop-in block for Autonomous Independent that drives straight, at a fixed speed (in ft/sec), for a fixed distance. You need to give it two encoders and a RobotDrive, and tune the gain slightly.
02-10-2010 11:18
J93WagnerMad props to you good sir.
Just one thing though, you wouldn't happen to have CAD models or drawings would you, becuase if this is really simple, then perhaps our own design team would like to incorporate it into the 6-wheel tank drive we're modeling this preseason.
02-10-2010 11:20
RyanCahoon|
If you don't have the programming skills, I could send you some simple LabVIEW code to drive straight, using kit encoders. Just PM me if you want it. It's a simple drop-in block for Autonomous Independent that drives straight, at a fixed speed (in ft/sec), for a fixed distance. You need to give it two encoders and a RobotDrive, and tune the gain slightly.
|
02-10-2010 11:38
Ether
02-10-2010 12:16
Joe Ross
Our drivetrains go straighter in autonomous after we switched from victor speed controllers to jaguars, which don't have an offset center.
02-10-2010 15:40
artdutra04
A [quadrature] encoder and velocity PD control loops are lighter than an additional gear.
02-10-2010 15:58
Chris is me|
A [quadrature] encoder and velocity PD control loops are lighter than an additional gear.
|
02-10-2010 16:41
Tom LineThe only time we've ever had a significant problem driving straight was when we had drag due to a worn mechanical component. We've always used skid-steered drivetrains however, and those tend to stay straight because of the their frictional interaction with the floor.
02-10-2010 19:09
JesseKEvery one of our issues in driving straight has either had to do with an imbalance in friction or in a misalignment of a wheel. While fixable in software, the unfortunate side effect of such a fix is the robot moving slower overall. Software fixes also add complexity to debugging an autonomous like 2008 (go straight a set distance, turn a to set heading, straight, turn, straight ...) in that the autonomous is less likely to be 100% consistent.
02-10-2010 22:59
ChuckDickersonA little bit of extra code sure seems like it would weigh less than extra gears. This seems like a good way to waste ounces to me.
02-10-2010 23:35
ttldomination|
1. I believe its a method to overcome possible direction bias of cims, enabling both sides to spin in the same direction by adding one more stage of 1:1 gearing.
|
02-10-2010 23:44
kevin.li.rit
As far as I can tell the direction bias of the CIMS is less than 100 rpm.
But why add an extra gearing stage when you could simply mount the gearbox in the same direction.
03-10-2010 00:05
kgzak|
As far as I can tell the direction bias of the CIMS is less than 100 rpm.
But why add an extra gearing stage when you could simply mount the gearbox in the same direction. |
03-10-2010 00:15
kevin.li.rit
That's a good point, There are also differences motor to motor especially for older motors.
03-10-2010 03:14
EricH
Using the 100 RPM bias figure that Coffeeism mentioned (note--I'm not sure how accurate that is; someone may want to figure it out), and the free speed of a CIM at 5500 RPM, that's a 1.8% difference from switching directions. Pretty small. When you gear down a CIM, you multiply that a bit--but it's still pretty small. For a free-speed motor, it's entirely possible that one motor and its otherwise identical twin have a larger free-speed difference than a motor and its bias.
Would it work? Probably. Are there other, simpler, and possibly more elegant, ways of doing the same thing? Yep; I can think of 2-3 off the top of my head, ranging from ignoring automode entirely to having a gyro and a pair of encoders and some programming to ensure that the robot maintains heading to within 1/1000 of a degree or some other ridiculous degree.
I think it's a new solution to a much-solved problem; while I can appreciate the engineering, I don't see why it's better than the other solutions.
03-10-2010 09:55
Alan Anderson
It's not motor bias tripping you up. The problem is the default Victor calibration, which has its neutral point a little higher than it should. If you calibrate your Victors, or if you tell WPIlib that you're using factory-calibrated Victors, or if you switch to Jaguars, there should be no difference in forward vs. reverse speed.
03-10-2010 10:09
kevin.li.rit
I searched for it and someone else has measured it on this chief delphi post.
http://www.chiefdelphi.com/forums/sh...t=41255&page=2
03-10-2010 10:31
Chris is meWith a 1.5% difference in free speed, assuming it is not an issue of Victor calibration (much lighter of a fix than a second gear
), at 12.75:1, one side of your drive will spin freely at about 417 RPM, and a theoretically slower CIM will spin at 410 RPM. This assumes you have only 2 CIMs in your drivetrain; I'd gander that 2 more CIMs would "average out" this effect to make it even smaller.
With 6" direct driven wheels, and an assumed 81% efficiency, that's about 8.84 feet per second on one side and 8.69 feet per second on the other. That's a difference of about 2 inches per second. Turning scrub would probably stop your drive from tracking two inches in one direction over 9 feet.
03-10-2010 18:45
Hawiian Cadderdoes anyone know why the Cims have a bias, i noticed that the older the cim is the worse it gets, i would assume it is something to do with the rotor becoming magnetized or the permanent magnets starting to mess up.
03-10-2010 21:49
Chris is me|
does anyone know why the Cims have a bias, i noticed that the older the cim is the worse it gets, i would assume it is something to do with the rotor becoming magnetized or the permanent magnets starting to mess up.
|
03-10-2010 22:59
Ether
03-10-2010 23:24
joeweberI do not know if the CIM’s have or have not bias direction but our robots for the last 6 years have all traveled to the left over a 20 ft autonomous mode. Tele-op is not a problem and the thought of setting up the drives motors and gear boxes off to one side so they are going the same direction is not always an easy placement with the space available. We also have used Fisher Price motors on a home made Segway and it always drove to the left. Yes we can program it out but some times it becomes a difficult task when you are dealing with gyros, rotation sensors, accelerometers and a camera to keep it on track. We just thought the addition of a small idle gear, short axel, and two bearings would be an easy fix. The weight is minimal and the time saved in programming can make a large difference when you only have six weeks to make everything work. We have a small team with one programer that has other things to do durring build season.
04-10-2010 00:09
RyanCahoon|
The problem is the default Victor calibration, which has its neutral point a little higher than it should.
|
04-10-2010 00:29
AdamHeard
|
Side note: Another way to fix this that's always worked for me is wiring one of the motors backwards. (wire the Victor's output backwards, not the input)
|
04-10-2010 09:22
skimoose|
That being said, I've been told many times before that CIMs have no significant motor bias whatsoever. I have no data, but my team has also never had this problem so I'm inclined to think for my purposes, it's not a big deal. Your team and setup could be completely different, particularly if you have a 2WD robot which has no turning scrub.
|
04-10-2010 09:30
skimoose|
Side note: Another way to fix this that's always worked for me is wiring one of the motors backwards. (wire the Victor's output backwards, not the input)
|
04-10-2010 09:36
Joe Ross
|
That could give you problems with a strict robot inspector. Wiring must comply with the color coding rules. Yes, you can tape over the entire motor lead, but this only simplifies your code, it doesn't eliminate bias. As long as the motors are oriented 180 degrees apart one has to travel in the opposite direction to the other to move in the same relative direction.
|
04-10-2010 09:55
Jared Russell
Reminds me of this: http://www.chiefdelphi.com/media/photos/17269
The drill motors we used until 2005 had horrendous bias (around 10% if I recall correctly), so some teams came up with ways to correct for it mechanically.
04-10-2010 10:25
apalrd
|
...dealing with gyros, rotation sensors, accelerometers and a camera...
|
|
We have a small team with one programer that has other things to do durring build season.
|
06-10-2010 11:26
D.AllredInteresting conversation. Please let us know if your mechanical approach solves the problem. I suspect the extra gear will on one side of the robot will cause more loss due to friction than the perceived motor bias issue.
06-10-2010 18:41
kevin.li.rit
|
Interesting conversation. Please let us know if your mechanical approach solves the problem. I suspect the extra gear will on one side of the robot will cause more loss due to friction than the perceived motor bias issue.
|
06-10-2010 19:29
buildmaster5000For our team, driving straight was not an issue of motor bias, but a Jaguar issue. We were giving our Jaguar on one side a value of -1, and it would only output -.9 (I am not sure the exact number, so feel free to correct me.). We this causes a much more noticable difference than any motor bias did.
06-10-2010 21:03
kstl99I hope this is not straying too much but no one has mentioned the wire length. I made the mistake this year of having the wires to the wheel motors all different lengths. We used mecanum wheels and a joystick control, no encoder, and I believe the gyro was only used to orient the control before a match. While we seemed to go straight in autonomous it is hard to drive straight.
Does the wire length really make much difference, enough to be the OP's issue?
06-10-2010 21:57
Ether|
Does the wire length really make much difference, enough to be the OP's issue?
|
06-10-2010 22:12
Joe Ross
|
Does the wire length really make much difference, enough to be the OP's issue?
|
07-10-2010 11:41
J@GMFlintJoe- The gearbox revision looks pretty cool! But as you've no doubt read here, there are a lot of ways to approach the bias issue. I'll share our typical method here.
Every year as SOP we tach. all of our CIM's fwd & bwd -straight off supply- before assembling them into a drive unit, I don't think we've ever had one with same RPM in both directions. We then match the motors by RPM, or sets as best as we can. There are some differences that do level out, and as someone noted earlier, older motors tend to show more variation -based on our data anyways.
Once the robot is fully assembled, we again use a tach. & check for friction. Then after some intitial driving (which most always has some bias and the drivers complain) we adjust the output commands (in software) for the fwd running motor down until free speeds are nearly equal. Then live test again on the surface to confirm or adjust further (then the drivers are happy, and lose an excuse for not driving straight!
). From there we may again tune, but it's usually close enough. We have only installed encoders when more precision was required, ie. placing, errr trying to place, tubes in 2007, or runnning laps in 2008 in auton.
This year, we detuned the forward AM-GEN1 side a straight 4% throughout the scale all the time. For what we were doing, this worked well enough and the robot was pretty repeatable.
Closed-loop (encoders) when practical and within your resource capabilities are almost (IMO as a robotics engineer) always a better method if you can control slippage on the carpet or surface. Not only that, if you have a good control loop, it can adjust and compensate for a multitude of sins and still keep your robot going where you want to. Keep in mind, that doing this is not always as easy as it sounds and can take some precious time away from things like practicing playing the game in teleop.