Full reverse speed controllers when moving forward

When the robot moves forward, one side is moving faster than the other. We investigated the problem and we found that the right speed controllers are red and the left speed controllers are green. We researched this and we found that red is full reverse and green meant full forward. What could be causing this? How can we fix it?

We are using VictorSP speed controllers. The order of the motors in the robot: 3 is front left, 1 is rear left, 2 front right, 0 is rear right.

The constructor for the motor is
RobotDrive myRobot = new RobotDrive(3,1,2,0);
We had to invert our motors using the setInvertedMotor method.

ah doesn’t one side have to be driving in the opposite direction to go forward.
The motors have to rotate in opposite directions.

The motors on the left are facing the opposite direction to the ones on the right. Because they are flipped, you have to have one side moving in reverse to make them go the same direction in unison.

Your issue is likely with either your gearboxes, or your driver has a slight bias to one side of the joystick.

This is something that we have always dealt with and I assumed was common knowledge. DC motors will operate at different speeds (both load and freerun) with different polarisations. This relationship is not a linear one. I am pretty sure it has something to do with how the internal windings are placed.

The simple solution is to use an encoder to match rpms (or distances). You can drive reasonably straight (~2in drift over >10 ft with a kit-bot). You can also use a gyro to keep a constant heading.

The gearboxes could be a factor, but I am willing to bet it is relative motor speeds if you are simply feeding the motor controller a voltage percent in the code without any feedback.

EDIT: if the speed difference is severe (such as 1 inch drift over 1 foot) the problem is likely mechanical.

Agreed. First step would be to write a bit of code to set both sides to the same speed when a button is pressed. If you’re still pulling, it’s most likely mechanical. With power off, try turning the wheels by hand. You’ll likely find that your slow side has more resistance than the fast one.

Have you calibrated your speed controllers? Instructions can be found on page 6 of the getting started guide

Good point, or just try a different one (or flip the motors they are attached to) to see if the bias moves with the controller or if it is a mechanical/motor issue.

This may be at least part of your problem.


public RobotDrive(int frontLeftMotor,
int rearLeftMotor,
int frontRightMotor,
int rearRightMotor)

Constructor for RobotDrive with 4 motors specified with channel numbers. Set up parameters for a four wheel drive system where all four motor pwm channels are specified in the call. This call assumes Talons for controlling the motors.
(emphasis added).


  • 2.037ms = full “forward” - 1.539ms = the “high end” of the deadband range - 1.513ms = center of the deadband range (off) - 1.487ms = the “low end” of the deadband range - .989ms = full “reverse”


  • 2.004ms = full “forward” - 1.52ms = the “high end” of the deadband range - 1.50ms = center of the deadband range (off) - 1.48ms = the “low end” of the deadband range - .997ms = full “reverse”

Note that the range for the Talon is shifted towards positive. Is left going faster?

Not that it matters for this thread, but I have to say that I hate the very idea of custom calibrations for speed controllers for FIRST applications.

Maybe the practice isn’t SO bad these days with the reliability we have for most of today’s FIRST legal speed controller*, but in the past when random aluminum shavings could hobble your robot by failing a critical speed controller at just the wrong moment, no pit was complete without a batch of prewired speed controllers waiting to save your tournament from disaster.

IN THOSE DAYS, custom calibrations were just plain bad. It wasn’t enough to have hardware ready to change between matches, you had to do the whole kabuki dance necessary to get the calibration right. And if you didn’t do it just so, you might be driving in circles for 2 minutes. Ugh. So painful…

On a more philosophical level, it seems like we don’t custom ESC calibrations in the day of programmable robots with and much more reliable self-calibrating input devices. If you need calibration constants at all it seems to me that they belong in the robot code not in the speed controllers.

My 2 cents.

Dr. Joe J.

*I’m looking at you Victors & Talons. Others may be good as well, but I can say that my personal experience with these two has been stellar. The failure rate is nothing like the old days - like zero failures that were not of the “someone ran over the speed controller with a tank and it doesn’t work anymore” type.

you can also swap the polarity of the side that is running in the red direction.

  • turn off the inverted flags for hat side
  • swap the polarity of the motor to speed controller connection.

then forward = greed on both sides.

also, make sure you tell it the right kind of controller as above.

Possible easy joystick test: use digital buttons for driving(by “digital”, I mean a button that is either pressed or released, not something that can be pressed part way like a joystick or a trigger.) I wouldn’t recommend it permanently, but testing it this way, you’ll see if there’s an issue with the joysticks, since the motors are either full speed(button pressed) or stopped(button not pressed). You could probably tell without the motors running at 100% power.

We have the same idea with you. But this page said that “The New Talon SRX and Victor SP DO NOT have reverse polarity protection. Reversing the polarities will damage the motor controllers.”
I wonder if the swapping thing could damage my speed controllers?

We have the same idea with you. But this page said that “The New Talon SRX and Victor SP DO NOT have reverse polarity protection. Reversing the polarities will damage the motor controllers.”
I wonder if the swapping thing could damage my speed controllers?:confused:

What he meant is reverse the polarity on the MOTOR side. Reversing the polarity on the INPUT side is definitely going to damage the motor controllers, but the the motor side is perfectly fine.

I generally preach that changing the polarity of motors via. wiring is terrible practice. You should always do it in code. Having the wiring polarization standardized is extremely valuable when you inevitably have to replace/temporarily disconnect a motor or controller.

Thank you very much for helping my team. We don’t have much experience in programming. We have tried to fix the code but it seems like we can only reverse the rotation, we couldn’t even touch the speed controller signal (full reverse and full forward) :frowning:

normally, i would agree. i think the better solution here is to use the correct speed controller type since that apparently changes the pulse width range used.

but you may still end up with unbalanced forward versus reverse. in those case, i would swap the motor polarity for better functions, especially in systems where the motors are sharing a shaft, but pointed in the opposite direction or something.

Last year, our auton routine was pulling to the side. Victor SP’s. One side was moving slower than the other. We calibrated the speed controllers and it went straight for the rest of the season.

it was a 10 minute fix. We didn’t have to remove anything from the bot. No rewiring. Your problem might be something more as others have suggested but the calibration is the easiest variable to eliminate before you start looking for more complicated causes.

Good Luck.

Recalibrating the speed controller because you are sending the wrong pulse width is a two wrongs kind of right. I agree with Dr. Joe on this point. Recalibrating should be a last resort because it is not easily repeatable and replaceable.

We tried to calibrate the Victor but we couldn’t make it. The speed controllers always blinking red which is failed calibration