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?

Thanks,
Zaque

Re: Invert Motors Physically or in Code?
 

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.

Re: Invert Motors Physically or 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.

Re: Invert Motors Physically or in Code?
 

It really doesn't matter.

Re: Invert Motors Physically or in Code?
 

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.

Re: Invert Motors Physically or in 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

Re: Invert Motors Physically or in Code?
 

Or you could just?

Re: Invert Motors Physically or in Code?
 

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! :D

Re: Invert Motors Physically or in Code?
 

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.

Re: Invert Motors Physically or in Code?
 

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.

Re: Invert Motors Physically or in 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.

Re: Invert Motors Physically or in Code?
 

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.

Re: Invert Motors Physically or in Code?
 

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.

Re: Invert Motors Physically or in Code?
 

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

Re: Invert Motors Physically or in Code?
 

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.