Invert Motors Physically or in Code?

Hi all,
I was wondering if there is a “preferred” or “correct” method of inverting motors. Specifically, should it be done in code or by switching the wires, or by some other third method of which I am not aware?


I believe that the “correct” practice is to have all of the motors red-to-red and black-to-black, and then invert the direction in code.

The only time we invert wires physically is if we are in a rush, but we always switch it back later. Otherwise we try to always change motors in code so that if we ever have to switch the motor nobody gets confused.

It really doesn’t matter.

Never invert wires. Because the very first time someone has to trouble shoot something, replace a broken component, or unplug the motor, it WILL get plugged back together with colors matching (backwards).

Always invert the code.

I’m not sure if “correct” is the right word. But, I think it is worthwhile to set a standard that positive always means forward/up/right (or forward/up/left if you prefer, just choose 1 and stick to it). If the wiring is the one not following that standard, change the wiring. If the code is the one not following that standard, change the code. The key here is consistency.

Another tip is to never swap the wires leading out of the motor. Always swap the ones in between the speed controller and the motor. On top of this, make sure all of your motors are wired the same way. This way, if a motor breaks, you can swap it out and not have to worry if it is wired the same

Or you could just?

I do not think that there is a correct or standard way of reversing a motor. Do it the way how you will find it easiest. If you are better at programming, use the code method. If you are good at electrical, rewire it.

Even though I am good at coding, I would prefer the rewiring method. On my VEX OmniBot, Heels, I rewired two motors backwards to allow me to use standard mecanum code for control!

Hopefully, this helps! :smiley:

I agree with Tom, always “invert” in code as the wiring and terminals are marked so that you can always connect them consistently no matter who replaces the motor or motor controller. In theory there is a much larger pool of people who might replace those items vs the pool of people who might change the code.

Much safer to comment the code that L drive motors are “inverted” than to make sure that everyone who could ever possibly change a motor, including people on other teams who may be lending a hand in the heat of the moment between finals rounds that the L drive motors are to be hooked red to (-) and black to (+). It could be particularly disastrous should you have a dual motor system and to wire one of the motors backwards so that they are fighting each other. Best case secnario your robot doesn’t function, worst case you let the magic smoke out of both motors or motor controllers and now you’ve got two to change before the next round.

One more vote for “invert in code”. This is the more robust design practice for the many reasons enumerated above.

There are very rare exceptions like having multiple motors which need to operate on a single motor controller, but in opposite directions. Or perhaps there’s nobody who knows how to manipulate code available at the moment. Absent that kind of very special situation, invert the motors in the code.

I think that it can really depend on the situation. For instance my FTC team 3507 has built a mecanum drive train this year. And as the programmer for it accounting for one side of the motors being reversed is easy in code. But it becomes very complicated to understand what the values sent to the motors should be. It that case I would have voted for reversing the wires.

A side note

If you swap the wires you shouldn’t just make a mental note. You should have something visible that says they are swapped. In competition any knowledge like that will most likely be forgotten.

I believe in our code we have “invert” variables, one for each motor. When the code gets to the “output/write” section, all values to be output are multiplied by their “inversion” variable, which is assigned as either 1 or -1. That way if we are doing weird things such as mecanum, only a single number must be changed to guarantee an error-less inversion.

We use Anderson connectors, so we cannot physically insert the connectors together the wrong way. If we’ve assembled it to connect red to red wires, you cannot physically connect the Anderson connectors so black goes to red without intentionally disassembling and reassembling the connector. This means that if we change the order of the wires to change the direction of the motor, it cannot get accidentally reassembled incorrectly at a later time.

If we’re at the point where were actually testing a mechanism for the first time (where this type of thing tends to be an issue), I’d much rather just take 30 seconds to break the Anderson connector apart and switch the leads than spend ten minutes changing the code, recompiling, and rebooting the robot. It may not be the “right” way, but it’s a lot faster.

Another good reason to switch it in code is that it copies over to our practice bot.

Programmers are generally the last ones to touch ANY system that depends on embedded software to function correctly – and the more time they get to play with and perfect the code, the better the system will function. There will be plenty of challenges for programmers to overcome as they get the system ready to function correctly – there is just no excuse for making arbitrary design choices in other aspects of system design that add to the challenge by creating extra factors for programmers to keep track of.

Wiring, on the other hand, can and should be standardized, and its configuration ‘frozen’, as early as possible in system development. Allowing those who wire the robot to adopt any convention other than “always connect red with red, and black with black, in every power circuit” is simply creating an unnecessary opportunity to lose a match.

Code! Down the line someone is going to wonder “hey, why is this black wire connected to this red wire?” and switch them which could lead to devastating results if the component has the potential to be destructive

edit: hey, why is this black wire concocted to this red wire? oops.

It’s worth noting that the color coding on the outputs of all motor controllers I’ve seen are green/white, not black/red, because they’re meant to be reversible. If you ever see red->black on a properly wired robot, something is terribly wrong and you better not turn it on. Wiring the inputs of a motor controller backwards is a guaranteed way to ruin both the motor controller and your day.

That’s not to say that you should not be consistent with your wiring and handle motor reversals in code; on your final robot, you definitely should plan for that, but it’s not an issue of red->black (or, rather, it most definitely shouldn’t be). I agree with the earlier poster who mentioned that swapping the wiring is the way to go in early testing phases; with the time it takes to compile/upload code with the cRIO (especially if you’re using LabView), you will save much time this way.

Just a quick additional reason to invert in code only - it forces you to program well. If you program in a way where one boolean can determine the “reversed” position, your code is well made. It forces you to code in a way where you can implement new features, functions, etc. quickly. Especially with OO languages (use polymorphism!).

Example (details omitted) in Java:

The bad way:


The good way:

class ReversedTalon extends Talon {
    public void setSpeed(double s) {



Is it acceptable to use the .setInvertedMotor method in Java?

I think that like mentioned preciously in this thread, it is better to use inheritance to your advantage and make a “reversed” esc class, whether it be a victor, talon or jaguar. That way, the code becomes much easier to diagnose because there aren’t a bunch of .setInvertedMotor() lines that you need to keep track of, and it would instead be:

ReversedTalon leftDrive = new ReversedTalon(1);