When wiring motors should the rotation be predictable? Our off season project has a 4 motor 6wheel drop center drive. 1 cRio :eek: , 4 Jaguars (PWM) :yikes: , 4 Cims. Jaguars are paired together using PWM Y-cables. Seem and tested true on one side the paired Cims spun opposite to each other.
Yes, the rotation should be predictable.
I’ll admit that I can’t always remember off-hand which direction our motors are going to spin given a positive signal to the controller, but I know for certain that all motors in a gearbox will spin together, and that if I swap out a motor its direction of spin won’t change.
To ensure this, make it a team policy to always wire up motors in the same way. *Never *reverse a motor by changing the wiring. Always do it in code.
Are they spinning opposite because they are on the other side of the robot?
If wired in same orientation (red to positive, etc…) they are all likely spinning the same direction in the motor reference frame (all CW or all CCW), but if you point a motor the other way it’ll invert in the robot reference frame.
Per the spec sheet, Red positive should spin the motor CCW looking at the shaft. If memory serves, rotating the brushes (end plate) relative the magnets (motor body) will reverse rotation. We have had a couple rotate “backawards” over the years.
So, it should obey the right-hand-rule with the thumb pointing out along the shaft?
There are exceptions to this rule. For example, if you are running two motor controllers off a PWM splitter (common when using tank drive or any dual-motor gearbox) or two motors from a single motor controller (like automotive motors, per R35), and one is going the wrong way, then you can only fix it in wiring. We had this exact situation on this year’s robot - we had two identical motors powering the two doors for our gear mechanism. The doors opened in opposite directions (one CW, one CCW). As we were using automotive motors, we could run them both off a single speed controller, which presented the simplest solution, in terms of less required space, less required wiring, and simpler code. Of course, it meant that the two motors had to be wired up opposite from each other.
Having a standard way of wiring something is good. It helps prevent mistakes when you have to replace a motor. But it’s a mistake to hold on to that concept so tightly that it forces you to engineer a more difficult solution.
I would argue that the complexity added on the physical robot by having a motor wired in a different way is greater than that saved in code from the use of a PWM splitter (regardless, we use CAN).
Wiring two motors from the same controller is already pretty out-of-the-ordinary, so I don’t think anyone would expect “wire the motors in the same direction” to hold in that case (especially since, in that situation, the standard is no longer dictating an arbitrary choice - you can’t reverse only one of the two motors in code), no matter how strictly they usually hold to the policy.
Complexity? There’s absolutely no added complexity when you swap the polarity of a motor. The only possible introduction of complexity is getting it right if you have to replace the motor… And regardless of how it’s set up, I ALWAYS have things tested on a robot after a change is made, which makes it ridiculously easy to see if a mistake was made, and quick to remedy. If you have complex or poorly written code (which most teams have, sadly) it can be difficult to ensure you get the polarity right every time you use that motor, depending on what the motor does. On the other hand, if you have code that you know works otherwise, switching the wires can be done quickly (under a minute for any robot my team builds). That ensures you don’t introduce bugs in your code by trying to change the polarity with programming. Why not take the simpler, more assured route when fixing things?
PWM splitters are really great for teams to use when needed, and do save complexity in code. It means you only have to set one motor controller object instead of two every time you reference it (which, depending on what it is and the structure of the team’s code could be a lot of times). It’s pretty easy when writing code to screw that up and only set one, or to be making a change quickly and only change one of them. Why risk it?
The use of “only” here sort of masks the fact that this is a really important constraint that I’ve totally seen burn people many times before. The cost of not splitting PWM signals to two motors that need to travel in opposite directions is a tiny one-time cost to code complexity (the additional motor controller objects don’t actually need to be handled directly, if your code is structured in a reasonable manner - if a team is literally calling all the motor controllers on their drive directly at multiple points in the code, they have much deeper problems and reducing the number of motor controller objects is, at best, a band-aid) that is extremely unlikely to come back to burn you later. The same is not true to the cost of breaking standards for your motor wiring. I simply do not believe it’s a good practice.
We have had at least 1 CIM wired incorrectly (I believe the factory accidentally swapped wire colors)