Problem with Motor direction

[FRC1672]

Our programing / electronics team was trying our bench top test and we found that one of our motors was traveling backwards. The jaguar is receiving a backwards signal as denoted by the LED's color being 'orange-ish'.

We set up the bench top test stock from the KOP. Our cables were hooked up correctly. The motors did drive. We are using the WPI library (unmodified).

Any insight if its just the WPI library? Is there a physical fix (reversing cables???) other than reversing the motors in the library coding.

[Miner]

Basically your choices include anything that complies with the rules...

For now you could switch the wires on the jaguars, on the motors, or just switch it in the programming like you said.

Get it to work now and you will have more time to work on it later. Thats something thats good to remember. Dont spend a lot of time trying to solve a problem that can be quick fixed and worked on later...

[FRC1672]

The jaguar is receiving a backwards signal. The jaguars LED is representative of backwards signal. The LED is 'orange-ish'. Sorry for no saying that above.

Moving your attention to the WPI library where can we switch the motor direction?

We also have an issue with reuploading / recompiling the library.

[TotalChaos]

Originally Posted by FRC1672

Moving your attention to the WPI library where can we switch the motor direction?

Are you using LabVIEW?

- Austin

[FRC1672]

WinRiver: C++. I'm sorry if i misspelled that.

[TotalChaos]

Oh, ok. I'm sorry, I can't really help then. I don't really know much C++. Hopefully someone who knows it better will pick up on your thread.

Good luck!

- Austin

[EHaskins]

The WPILib "RobotDrive" class includes the ability to easily reverse motors in software. Normally this would be configured using a call to SetInvertedMotor().

WPILib code a docs:

/*
 * Invert a motor direction.
 * This is used when a motor should run in the opposite direction as the drive
 * code would normally run it. Motors that are direct drive would be inverted, the
 * Drive code assumes that the motors are geared with one reversal.
 * @param motor The motor index to invert.
 * @param isInverted True if the motor should be inverted when operated.
 */
void RobotDrive::SetInvertedMotor(MotorType motor, bool isInverted)
{
 ...
}

The OTB code probably was configured to reverse one side, since that is almost always desired for a robot drive.

EDIT:
After looking at the Default code and WPILib code, I found where it happens.

For the right side, reversed is considered forward. So, if you want the right side to rotate the same direction as the left you need to call SetInvertedMotor for the right drive motor(s) and set them to inverted. You can see this in the function RobotDrive::SetLeftRightMotorSpeeds.

Bold comments mine

/** Set the speed of the right and left motors.
 * This is used once an appropriate drive setup function is called such as
 * TwoWheelDrive(). The motors are set to "leftSpeed" and "rightSpeed"
 * and includes flipping the direction of one side for opposing motors.
 * @param leftSpeed The speed to send to the left side of the robot.
 * @param rightSpeed The speed to send to the right side of the robot.
 */
void RobotDrive::SetLeftRightMotorSpeeds(float leftSpeed, float rightSpeed)
{
	wpi_assert(m_rearLeftMotor != NULL && m_rearRightMotor != NULL);

	leftSpeed = Limit(leftSpeed);
	rightSpeed = Limit(rightSpeed);

	if (m_frontLeftMotor != NULL)
		m_frontLeftMotor->Set(Limit(leftSpeed) * m_invertedMotors[kFrontLeftMotor]);
	m_rearLeftMotor->Set(Limit(leftSpeed) * m_invertedMotors[kRearLeftMotor]);

	if (m_frontRightMotor != NULL)
//Notice the "-" before Limit(), but not on the lines above. This is where the right side is reversed.
		m_frontRightMotor->Set(-Limit(rightSpeed) * m_invertedMotors[kFrontRightMotor]); 
	m_rearRightMotor->Set(-Limit(rightSpeed) * m_invertedMotors[kRearRightMotor]);
}

[FRC1672]

Originally Posted by EHaskins

The WPILib "RobotDrive" class includes the ability to easily reverse motors in software. Normally this would be configured using a call to SetInvertedMotor().

WPILib code a docs:

/*
 * Invert a motor direction.
 * This is used when a motor should run in the opposite direction as the drive
 * code would normally run it. Motors that are direct drive would be inverted, the
 * Drive code assumes that the motors are geared with one reversal.
 * @param motor The motor index to invert.
 * @param isInverted True if the motor should be inverted when operated.
 */
void RobotDrive::SetInvertedMotor(MotorType motor, bool isInverted)
{
 ...
}

The OTB code probably was configured to reverse one side, since that is almost always desired for a robot drive.

Thank you. This was most useful.

[Vikesrock]

Before you do this I have a question for you. Is the "backwards" motor you observed just form looking at the two motors not hooked up to anything and seeing that they were spinning opposite directions? If so I recommend orienting the motors as they will be oriented in your robot drivetrain (usually facing opposite ways) and see if they are now both spinning "forwards" or "backwards". In a typical FRC setup the motors must be driven in opposite directions to drive straight unless the wiring is reversed on one.


The physical solution is reverse the cables running from the Motor to the Jaguar. Take the cable currently attached to the negative side of the Jaguar motor output (probably black) and attach it to the positive side of the motor output.

[Enigma's puzzle]

This is pretty tricky, we had the same problem our first year, you will want to put encoders on the motors for sure. they don't have the same power going forward and backwards, i am assuming that you are not orientating them the same way. If you don't put encoders on, one side will turn faster than the other, and inevitably cause you to turn.