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.