pic: Reverse Drive
 

Re: pic: Reverse Drive
 

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?

Re: pic: Reverse Drive
 

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.

2. We've never had issues either....well aside from misaligned swerve modules but that's a different story

Re: pic: Reverse Drive
 

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.

Re: pic: Reverse Drive
 

We 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.

Re: pic: Reverse Drive
 

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.

Re: pic: Reverse Drive
 

Mad 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.

Re: pic: Reverse Drive
 

This seems like the way to go to me. It may not even be problems with the motors (or even if that does exist): friction in the drivetrain, imperfections in the play surface, wheel slipping (encoders attached directly to the drivetrain can't fix this though), among other things.

--Ryan

Re: pic: Reverse Drive
 

Just to be clear, maybe all electric motors in the KoP have bias, but the statement is not true of electric motors in general, especially brushless motors.

Re: pic: Reverse Drive
 

Our drivetrains go straighter in autonomous after we switched from victor speed controllers to jaguars, which don't have an offset center.

Re: pic: Reverse Drive
 

A [quadrature] encoder and velocity PD control loops are lighter than an additional gear.

Re: pic: Reverse Drive
 

While true, if this is a big problem for this team and driving straight is fixed by a single additional gear, a team heavy on the mechanical but light on the programming resources could pretty reasonably decide the tradeoff is worth it.

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.

Re: pic: Reverse Drive
 

The 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.

Re: pic: Reverse Drive
 

Every 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.

Re: pic: Reverse Drive
 

A 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.

Re: pic: Reverse Drive
 

Hm... I'm curious as to why that works? It would seem like it wouldn't make that much of a difference...

Re: pic: Reverse Drive
 

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.

Re: pic: Reverse Drive
 

I was just gonna suggest this. Also, the only problem we had with turning was with our open loop autonomous when we went straight we turned slightly. this was probably cause by our electric board and battery being on the same side and nothing on the other. We tool a Tachometer and measured the speed of the motors with no load and they were going the same speed. Are you sure this wasn't your problem? or maybe they have a direction basis while under load?

Re: pic: Reverse Drive
 

That's a good point, There are also differences motor to motor especially for older motors.

Re: pic: Reverse Drive
 

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.

Re: pic: Reverse Drive
 

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.

Re: pic: Reverse Drive
 

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

Re: pic: Reverse Drive
 

With 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.

Re: pic: Reverse Drive
 

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.

Re: pic: Reverse Drive
 

Who says the CIMs have a significant bias?

Re: pic: Reverse Drive
 

If a brushed DC motor has a bias, it's often due to the commutation timing being slightly biased in one direction or the other.

Re: pic: Reverse Drive
 

I 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.

Re: pic: Reverse Drive
 

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)

Re: pic: Reverse Drive
 

I'd learn to calibrate the victors, it's very easy to do, and should be done to all victors each year.

Re: pic: Reverse Drive
 

We ran tests in 2007 using victors to control the CIMs and there was some bias, and it was different for each motor tested, it was most apparent when ramping speed up or down. The response curves varied, not significantly but enough to be a problem occasionally, because they were not linear. We wrote code that year to flatten out the response curves to be more linear and that helped.

We haven't done the same testing with Jaguars yet, might be a good exercise for this season.

Drive line friction would probably cause greater issues with a robot driving straight, than motor bias which is fairly consistent throughout the motor's life. No matter what the source of driving error, I'd be looking to sensors and code to fix those issues if you want to achieve truly accurate autonomous navigation.

Re: pic: Reverse Drive
 

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.

Re: pic: Reverse Drive
 

It should only give you trouble with an uninformed robot inspector. <R48> specifically allows for different coloring schemes on the output of a speed controller because the speed controller does not output constant polarity.

Re: pic: Reverse Drive
 

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.

Re: pic: Reverse Drive
 

A quadrature encoder (rotation sensor) should be all you need. As long as both sides are going the same speed, it will not drift. You do not need to further compensate with other sensors.


Myself and a programming mentor (who is also very busy, being the lead mentor) are the only current programmers on team 33. I wrote all of the code myself, and there is quite a bit of it for our current robot, especially in the arm.

If you would like my autonomous drive straight block, PM me and I will send it to you (apparently I can't post attachments in this thread).

Re: pic: Reverse Drive
 

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.

Re: pic: Reverse Drive
 

I believe a good rule is that you retain 85-95% of power through each spur gear stage?

Re: pic: Reverse Drive
 

never mind

Re: pic: Reverse Drive
 

For 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.

Re: pic: Reverse Drive
 

I 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?

Re: pic: Reverse Drive
 

What gauge was the wire and what was the difference in length?

Re: pic: Reverse Drive
 

A rule of thumb is that 10 awg wire drops .1 volts over 1 foot at 100 amps. Most drive trains don't draw 100 amps for normal driving. If you assume 40 amps and a 1 foot different, that's .04 volts dropped or 0.3% of 12 volts. It would be worse if smaller wire is used (eg 12 awg), there is a longer length mismatch, or you have a particularly inefficient or high current drivetrain.

Re: pic: Reverse Drive
 

Joe- 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! :p ). 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.