Drive Train Curves Only While Backing Up

[Ozuru]

Hello,

For some reason our drive train is curving to the right only when we backup. When we use the joysticks, it does not curve. When we set the talon manually (Talon.set(-1)), it curves to the right pretty severely.

We're using a 6-wheel drive train (3 on each side) with a mini toughbox. Our motors are 4 KoP CIM motors and we're using 4 talons for our motor controllers. We're splitting the PWM cable so we're only using two PWM cables to access the 4 talons. We're kind of unsure what this could be so I was wondering if anyone had an issue like this before or what your ideas might be as to what's causing it.

Thanks!

[notmattlythgoe]

Originally Posted by Ozuru

Hello,

For some reason our drive train is curving to the right only when we backup. When we use the joysticks, it does not curve. When we set the talon manually (Talon.set(-1)), it curves to the right pretty severely.

We're using a 6-wheel drive train (3 on each side) with a mini toughbox. Our motors are 4 KoP CIM motors and we're using 4 talons for our motor controllers. We're splitting the PWM cable so we're only using two PWM cables to access the 4 talons. We're kind of unsure what this could be so I was wondering if anyone had an issue like this before or what your ideas might be as to what's causing it.

Thanks!

Are you making sure to set all of the talons manually? What do the diagnostic lights on the talons do when the robot is backing up?

[MrForbes]

Did you calibrate the speed controllers?

[Ozuru]

Originally Posted by notmattlythgoe

Are you making sure to set all of the talons manually? What do the diagnostic lights on the talons do when the robot is backing up?

I think so -- I'm invoking the RobotDrive.tankDrive(double left, double right) method.

The lights are a solid green when backing up. This is due to the fact that our motors are sort of hooked up backwards -- from the way it was explained to me we would have to swap the negative and the positive wires to fix it in hardware (which is supposedly a big no-no) so I've been compensating for it in programming. Is this what most teams do?

[Ozuru]

Originally Posted by MrForbes

Did you calibrate the speed controllers?

No, we did not -- I didn't know that this is possible. How would I go about doing this?

[zachrobo1]

Originally Posted by Ozuru

No, we did not -- I didn't know that this is possible. How would I go about doing this?

You are using the KOP Talons, right? This is the manual for them.
http://www.crosstheroadelectronics.c...Manual_1_1.pdf

On page 7 are the calibration instructions.

[Ozuru]

Originally Posted by zachrobo1

You are using the KOP Talons, right? This is the manual for them.
http://www.crosstheroadelectronics.c...Manual_1_1.pdf

On page 7 are the calibration instructions.

Thank you. I'm going to try that today. Would that be a valid explanation as to why it is curving?

[MrForbes]

It's the first thing I would do....it doesn't cost anything, but time.

[Ozuru]

Originally Posted by MrForbes

It's the first thing I would do....it doesn't cost anything, but time.

Got it.

We swapped the PWM cables in the RoboRIO (port 0's cables are now in 1 and port 1's cables are now in 0) and now, when reversing, we reverse while curving in the opposite direction. We hooked the output of them up to an oscilloscope and it is showing that one port's PWM is getting more signal than the other although in the code I am giving them the same values. Any ideas?

For example, if I do RobotDrive.tankDrive(-0.5, -0.5) it is producing the PWM similar to RobotDrive.tankDrive(-0.6, -0.5).

[GeeTwo]

Are you declaring both motor controllers to be of the same class (e.g. not one Talon and one Jaguar)?

See the second paragraph in the white area of:
http://wpilib.screenstepslive.com/s/...ns-and-jaguars

[MrForbes]

Are you saying that the direction of curving is following the code, not the hardware?

if so, you'll have to get some help from a programmer....and I suggest you post images or listings of your code so they can see what you have done.

[GeeTwo]

Originally Posted by Ozuru

.. and now, when reversing, we reverse while curving in the opposite direction.

That pretty much rules out any mechanical causes.

[TikiTech]

Originally Posted by Ozuru

Got it.

We swapped the PWM cables in the RoboRIO (port 0's cables are now in 1 and port 1's cables are now in 0) and now, when reversing, we reverse while curving in the opposite direction. We hooked the output of them up to an oscilloscope and it is showing that one port's PWM is getting more signal than the other although in the code I am giving them the same values. Any ideas?

For example, if I do RobotDrive.tankDrive(-0.5, -0.5) it is producing the PWM similar to RobotDrive.tankDrive(-0.6, -0.5).

Were the motor controllers recalibrated?

Another thing to try is program for ports 1&2 to see if it related to a specific port since the issues are common to port 0

Aloha!

[BitTwiddler]

Originally Posted by Ozuru

The lights are a solid green when backing up. This is due to the fact that our motors are sort of hooked up backwards -- from the way it was explained to me we would have to swap the negative and the positive wires to fix it in hardware (which is supposedly a big no-no) so I've been compensating for it in programming. Is this what most teams do?

I don't believe there is anything wrong with reversing the motor wiring to compensate for the left/right motor reversal problem. However we wire all of our motors the same way but in LabView we can open the motors with a parameter that tells the RoboRIO to reverse the meaning of the input values to the motors.

I suspect the call to the tank drive method or the open constructor would include similar parameters to invert the motor outputs.

[Ozuru]

Thanks for all of the replies so far everyone.

I'm not there testing but have someone else testing. I'm going to be recalibrating them (and consequently posting here with my findings) sometime around 3 PM EST today. Maybe I'm interpreting the oscilloscope wrong -- here are the images I received. Linking to rather than embedding the pictures because they're massive.

Oscilloscope Reading #1
Oscilloscope Reading #2

The readings are from the PWM signals with the ports swapped running the very basic code below I wrote to confirm it wasn't a programming issue.

As for my code testing this, I literally just created a new IterativeRobot I just did:

RobotInit() {
Talon t = new Talon(0);
Talon t2 = new Talon(1);
RobotDrive rDrive = new RobotDrive(t, t2);
} 

TeleopPeriodic() {
rDrive.tankDrive(-1, -1);
}

and this causes the curvature we're seeing. I have a more complex method in my actual robot code for CommandBased but, seeing as it curves with that basic code, I concluded that it was probably not my code.