I’m seeing significant speed differences running the TB Minis (with two CIMs) in forward vs. reverse. Mostly this is at slow speeds. I assume this is “by design”, but i’m curious that the sample code I’ve looked at doesn’t compensate for this in any way. With two gear boxes on each side of a KoP robot and so the motors running in opposite directions therefore results in a turning force when attempting to drive straight. I assume this is a well known (non-)issue.
That is odd, I know that some motors (like the old Dewalt drill motors) have a preference for one direction vs the other. The cim motor is not one of them. A few things could be happening.
A) you could have resistance in your system that applies one way.
B) your motor controlless could be out of calibration.
C) you could have some bad cims.
Not an expert, just a tried highshooler.
Right, I would certainly have expected one side to be consistently slower than the other in both forward and reverse indicating some assembly tolerance. The asymmetric nature (meaning one side faster in forward and the other faster in reverse) was kinda counterintuitive. I’ll check I haven’t missed a speed controller calibration step (these are the Victor SPs).
When we were designing our shooters for both the alpha and beta bots we took the 14 or so mini CIMS that we had and measured their actual rpms, both forward and reverse. We found them to range from about 5650 rpm to 6440 rpm and it didn’t matter whether it was forward or reverse. The only noticeable difference that we did discern was that 8 of them ran forward faster than reverse. Some of them were strangely different-- running 550 rpm faster in one direction vs the other.
We just used these numbers to mate a pair so that we were able to have the same speed (within 40 rpm, no load) with one forward and the other in reverse.
CIMs do have motor bias, as other motors do. Generally CIMs are pretty well balanced, but it has been known to happen. TBs, as far as I know, shouldn’t cause bias “by design”. I would check lubrication/assembly of them or motor controller calibration.
There are a lots of ways to control the outputs and make them match each other. “Drive Straight” code is very common for teams to use.
Thanks for all the replies. In the end I tracked it down to the Victor SP calibration. I noticed when moving forward/reverse that the red/green colors came on at different times. The VictorSP manual says that they are calibrated for the RoboRio by default, so could be there is still something I have to do in the RoboRio, but for now running through the calibration steps in the Victor SP manual fixes the issue.
For anyone curious, or running into this later here is the current manual:
Of course I unplugged the motors while running the calibration step.