Standard Drivetrain, Labview, currently arcade drive. Have always had the same problem each year, hoping to figure out how to solve it. I have seen this referenced somewhere else, but the answer wasn’t real clear. Basically, when you push joystick forward, 1 side of the drivetrain always starts just a little ahead of the other and will favor that side in power. If you reverse it, it’s the opposite side. I’ve read somewhere that it has to do with the “natural direction of the motor and since one is going backwards, then its just going to do this”, unfortunately, I didn’t understand the solution.
It is possible to drive, but you have to favor one side slightly. Even tried tanking drive, it didn’t help much either. Thanks.
we had the same problem, we tried taking the gearboxes apart multiple times but nothing helped. We just had our programmer compensate, I think thats the only way to fix it.
In the future, could you post using the default font size, it easier on the eyes and not as distracting.
To answer the OP’s question, you probably need to calibrate your motor controllers. The procedure varies depending on what type of controller you are using.
…why are you yelling?
lopsided98 is right if you’re using PWM. That might help normalize it.
What you were alluding to is the fact that CIMs (like many motors) are slightly more efficient in one direction then the other (a direction bias). When you move forward one side of your robot has the CIMs spinning clockwise and the other side has motors that spin counter-clockwise. So one side will take advantage of operating in it’s bias while the other side won’t.
Also traditionally your robot’s chassis would change over the season creating even more asymmetric characteristics. But then again this year’s game doesn’t really allow for robot contact, so this this might not hold true this year.
Experienced teams will use encoders, gyro, and other forms of feedback to keep the robot going straight. It’s a normal part of the challenge of making a great robot.
Already calibrated, guess we will have to figure out the advanced programming.
If you can better characterize this and determine whether this is primarily an issue at the low input values or is consistent across the speed range you will operate in, you can do an open-loop compensation. Just reduce the eager side by some amount, like perhaps a linear transform. I’d suggest making some coefficients that are placed on a panel or in a global. Run the code and tweak the bias and slope to see if this is good enough.
Depending on the weight distribution and wear-n-tear on the robot, you may need to update this at some point. You may also want to do the test on carpet or a close approximation.
How did you calibrate the motor speed controllers? Doing that should have corrected the “one side starts before the other” issue.
Make sure that the code is opening the kind of speed controller that you actually have installed. Jaguars and Talons do not respond exactly the same, and if the hardware and software don’t match you can get the symptoms you describe.