motor synchronization

VEX V5 Technical Support UNOFFICIAL Tech Support
#1

I am using a controller to move my robot but when I make the robot move forward the wheels don’t rotate equally and one is always faster than the other. Is there a way I can use shaft encoders or gyroscopes to equalize motor power when I use a controller to move it?

#2

Sure, are you using EasyC or ROBOTC? Have you checked that one wheel (well, the axle) does not have more friction than the other? Perhaps search the forum for threads on “driving straight” or “driving with PID control”.

#3

Have you checked that both motors have the same inner gears such as both set to torque or both to speed? If one is torque and one is speed you’ll get his sort of problem.

#4

I was wondering if you had checked that both motors are indeed the same type: 393 vs. the old discontinued 269.

Also, have you checked that your joystick has been calibrated? I’m not sure it would likely be off by that much, but I thought I’d ask. I presume you are using arcade drive vs. tank drive? (In tank drive, you would need to push both control sticks forward for the robot to go forward. In arcade drive, only one stick controls direction.) In tank drive, you can overcome some otherwise incurable imbalance in your wheels by simply learning to push the sticks a little differently, allowing for the error.

If you have encoders on each wheel, or want to add them, you can have a look at this: http://www.robotc.net/wiki/Tutorials/Arduino_Projects/Mobile_Robotics/VEX/Using_encoders_to_drive_straight

#5

If your robot is going around in tight circles, then there may be a large source of friction on one side of the robot that isn’t on the other side. There may also be some issue with the power each motor is able to deliver to the wheels, whether that’s because of the motors being different sizes or geared differently.

What I imagine is happening, however, is that as you try to drive in a straight line, the robot is veering off course slightly. Even the best-built robot is likely to encounter this, as no two motors are exactly the same and even the slightest inconsistency in a bearing can change the friction of the system.
The easiest way to try and solve this issue is to simply reduce the maximum value of the wheel that’s going to fast. It’s a terrible method that you won’t catch my team doing, but it’s relatively simple and easy.
A good way to make sure each wheel travels the same distance in the same time is to put a shaft encoder on each one. You can look at the speed of each axle and write some code to ensure they’re the same. Your code would set up a negative-feedback-loop where if a wheel is going to fast (relative to the other one), the code tells that motor to slow down slightly until it is going at the correct speed.

#6

Why use programming when you can use marketing? Just say you modeled your innovative drive after the legendary 2915 robot and call it intentional.

#7

That’s too awesome for words. LOL.

#8

I’m surprised jpearman did not plug the smart motor library because he has the speed calculations as part of the data structure as long as you add the encoder to the motor. What is not in there is now is the function to slow down the one side to the speedier one.

There’s no accessor function for the speed right now either. Hey, someone can branch for that and A/B speed control! Yeah Github and open source!

Note: Since the struct is a global variable you really can access it directly but not the best programming practice for an included library. Darn you robot C and the lack of data access controls.

#9

There is access to speed, SmartMotorGetSpeed.

/*-----------------------------------------------------------------------------*/
/*  Get Motor speed                                                            */
/*-----------------------------------------------------------------------------*/

float
SmartMotorGetSpeed( tMotor index )
{
    // bounds check index
    if((index < 0) || (index >= kNumbOfRealMotors))
        return( 0 );

    return( sMotors index ].rpm );
}
#10

I thought there was but I looked at the documentation today instead of the code… :eek:

An undocumented feature! Woo hoo!!! :stuck_out_tongue:

#11

It’s documented in Rev 2 of the manual which is on github along with the code. It was not a feature of the original v1.00 release so is probably not in the documentation linked in the very first post of the smart motor release thread. I should probably delete all the old versions now, people are still downloading the original release that had a couple of small bugs.

#12