Backwards Mounted Motors

The way our tank drive was made, one tranny was mounted so that 254 would drive forward, and one mounted so that 254 would drive backwards. To deal with this, I added the following bit of code to my Drive() function.

if(intSpeed > 127)
{
RIGHT_MOTORS	=	127 - (intSpeed - 127);
}
else
{
RIGHT_MOTORS	=	127 + (127 - intSpeed);
}

The problem with this though, is that forwards speed is always higher than backwards speed. To solve this, I took the backwards RPM and divided it by the forwards RPM. Then, on the side that was forwards, I had the following code

if(intSpeed > 127)
{
LEFT_MOTORS	=	intSpeed * .952;
}
else
{
LEFT_MOTORS	=	intSpeed * (1 / .952);
}

After Battlecry, the driver told me that it was still veering to the right. Could the maximum RPM’s have changed? How do you guys get around backwards tranny’s?

If I was a programmer, I’d tell the driver to deal with it or tell the mechanical people to fix whatever is “dragging” or binding causing extra load/friction. The CIM motors should be VERY close in forward and reverse speed as far as I know. So, check your slower side tranny for extra friction somewhere.

Just so you know, the easy way to reverse a motor is
‘255 - intSpeed’

That way you dont have to deal with the If() statements.

And yes, CIM motors, have neutral timing. They run just as good forwards as they do backwards. I would defintely have a poke at the drivetrain. Even though it’ll still probably be your problem to fix. :rolleyes:

Why not just swap the pos. and neg. leads to the motor at the Victor for the right motor? No software or programming required.
I find it is always easier to do the simple things first.
Now your only limitation is that most joysticks never get all the way to 0 in full reverse.

Well, not the max RPMs, but the motors do get broken in after some heavy running, which causes them to run differently.

Mike,

The CIM motors are the same in forward and reverse. Our transmission arrangement had one tranny mounted “backwards” and we drove perfectly straight without code adjustments to motor speed. Something else is going on in the drive. First check for any bind in the transmissions, especially chain. Next, check to see if the motors are O.K. Use code as a last resort.

-Paul

Contrary to popular belief, it is NEVER a program issue, always hardware

F.I.R.S.T. Troubleshooting Rule #1 - If you work on software, the problem is always with hardware. If you work with hardware, the problem is always with software

I’m going to have to agree with everything above. I found it easier to reverse the leads on one set of CIMs, rather than having to fix it in code. Also, the CIMs do run almost identically in forward or reverse, so I would say that there must be something whack with your right tranny.

<edit>
In an attempt to actually add something new and insightful to the discussion, rather than just repeating what everyone else said, here’s how I fixed the drift on our drill motors last year (which do indeed run very differently in forward and reverse). We hooked up an encoder to each wheel (we just used Banner sensors and white dots on the wheels, since it was far too late to integrate a real encoder). Then I wrote a segment of code in Default_Routine() that ran the drive motors for about ten seconds (350 program cycles, I think), counting encoder clicks the whole time. I’d put the robot up on blocks, and then execute the code with a specific combination of joystick button presses. At the end, it would determine the ratio of encoder clicks (a/(a+b)), and then apply that difference to the faster motor. Basically, instead of hard-coding the ratio as you’ve done, you could do this to adjust the ratio on the fly, and store the result to EEPROM. Then you can recalibrate it whenever your drivers start to complain again. See if there are any obvious problems with your tranny first, and then try this.
</edit>

mount the motors both facing the same way but 1 with a shaft the it drives situated next to it the runns from the output to the wheels it needs to drive, or get some sort of encoders to accurately measure the speed while moving because the rpms may be diff at max rpms but the you gotta look at the torque curve to find out rpms at diff levels of torque being applied to it

Thanks for the help guys, I’ll talk to our mechanical team…

Mechanically ill agree with you, but when it comes to control while using a victor speed controller ill have to disagree. The way you get the joystick to go all the way to “complete 255 and 0” is by calibrating the victor. I cant stress it enough to teams that you can not just connect random joysticks to the OI and get a full range of change at the victor speed controllers. Though if you calibrate your victors to joysticks you can get a full range of change. Also each time you change your joysticks or victors you should recalibrate the victors.

 For those insterested, calibration instructions are in the Victor 884 User Manual. [/edit]