How do you sync multiple motors?

[Japper]

Our team is playing around with parts from last years robot and have been experimenting with multiple motors and 4 wheel drive but we need to synchronize the motors.

Is there an easy way to do this so that the motors on each side are running at the same speed?

We have one victor per motor and the victors per each side are sent the same PWM data. Is this just a matter of calibrating the victors?

Please advise

Thanks

[T3_1565]

Well if your willing to get more parts, encoders work wonders on syncing motors to run the same speed. As far as I know, if you don't buy any more parts, I don't think you can get them EXACTLY the same. because no motor is exactly the same.

Someone correct me if I'm wrong though :P

[chris31]

You could use encoders or a gyro to solve this problem and ensure that your drive straight.

[Richard Wallace]

You could use encoders or a gyro to solve this problem and ensure that your drive straight.The gyro approach might be simpler, if you have access to parts from last year's kit.

This whitepaper (http://www.chiefdelphi.com/media/papers/1755) from Team 33 provides an excellent guide to setting up a gyro.

[Alex.Norton]

I would definitally suggest the gryo. It is quite a bit easier to use becuase you don't need to use interupts in the programing.

However, either route will take a lot of programing to get to work correctly.

Alex

[Madison]

Our team is playing around with parts from last years robot and have been experimenting with multiple motors and 4 wheel drive but we need to synchronize the motors.

Is there an easy way to do this so that the motors on each side are running at the same speed?

We have one victor per motor and the victors per each side are sent the same PWM data. Is this just a matter of calibrating the victors?

Please advise

Thanks

Can you please clarify what you're trying to achieve? Particularly, in my mind, your description of "each side" is ambiguous and I'm not sure if you're trying to make the right and left side of your drive train go forward at the same speed or if you're combining two motors on one side and trying to ensure those motors turn at the same speed.

[Pat Fairbank]

If the motors that are on the same side are of the same type, and you are feeding them the same PWM values (you could use a Y-cable from a single PWM output to make sure of this), and your Victors are both calibrated properly, then any difference between the speeds of the motors can be considered negligible and won't have an impact on performance.

Clarification edit: This answer is assuming the original question is about synchronizing the speeds two motors on the same side of the robot.

[TubaMorg]

If the motors that are on the same side are of the same type, and you are feeding them the same PWM values (you could use a Y-cable from a single PWM output to make sure of this), and your Victors are both calibrated properly, then any difference between the speeds of the motors can be considered negligible and won't have an impact on performance.

Actually, as most new teams can attest to, if you send the same pwm signal, and your Victors are calibrated and outputing the same voltages to both sides, the final drive speed for each side will almost ALWAYS be different. That's why every team is dismayed the first time they turn their robot on and it drives in circles. The reason, as pointed out in previous posts, is that every motor is slightly different. The difference is compounded when you factor in varying amounts of friction from additional drive train components. Also, motors tend to have a bias so that they turn different speeds in different directions when the same voltage is applied. I bring this up because your motors on the left and right sides are likely spinning in opposite directions.

The solutions presented previously work great. Whether you use encoders or a gyro, they essentially provide feedback to your program on the speed each wheel is turning so that your program can dynamically adjust the pwm values to maintain a desired setting. In the case of going straight, your program would make sure that each wheel is turning the same speed which ultimately ensures you drive straight when you want to drive straight.

Another sort of wacky way we've played with works, but is more useful as an exercise than a practical way of controlling your robot. After we put our robot together, we used a strobelight tachometer and got the wheel speed of each wheel at each PWM value. We input this data into a spread sheet and plotted the results to visualize the curve. These data form the power curve for each wheel and includes losses to the power train. From this you can calculate an equation for each side that coverts pwm value to speed so that each wheel recieves the appropriate pwm input for a desired wheel speed.

While this worked and was interesting academically, it isn't likely to last for long. Changes in the drive train would eventually invalidate the curves.

Feedback mechanisms (Gyro/encoders) coupled with PID code work the best because regardless of wear and tear on your drivetrain, or even replacing entire components, your program will still compensate dynamically.

[Alex.Norton]

Another sort of wacky way we've played with works, but is more useful as an exercise than a practical way of controlling your robot. After we put our robot together, we used a strobelight tachometer and got the wheel speed of each wheel at each PWM value. We input this data into a spread sheet and plotted the results to visualize the curve. These data form the power curve for each wheel and includes losses to the power train. From this you can calculate an equation for each side that coverts pwm value to speed so that each wheel recieves the appropriate pwm input for a desired wheel speed.

This only works if the surface your driving on is consistent. If there are any variation such as from free spinning, to carpet, to concrete you will see large differences. There can even be large difference between on spot on a carpt and another. Say something sticky was spilled, the wheel that passes over it will drive at a different speed compared to the same wheel on non sticky carpet. Of course first fields are fairly consistent but if someone drops a part on the field this will affect a drivetrain that doesn't have feed back.

Alex

[EricH]

Actually, as most new teams can attest to, if you send the same pwm signal, and your Victors are calibrated and outputing the same voltages to both sides, the final drive speed for each side will almost ALWAYS be different. That's why every team is dismayed the first time they turn their robot on and it drives in circles. The reason, as pointed out in previous posts, is that every motor is slightly different. The difference is compounded when you factor in varying amounts of friction from additional drive train components. Also, motors tend to have a bias so that they turn different speeds in different directions when the same voltage is applied. I bring this up because your motors on the left and right sides are likely spinning in opposite directions.
He was talking about the same side, same motor, like you might get for a team running an AndyMark shifter system. And, if we're talking CIMs, I believe that the bias is less than the difference between motors.

Now, if it's two different motors on the same side, you've got about 30 days to start designing a gearbox so they'll be the same speed.

[Japper]

Can you please clarify what you're trying to achieve? Particularly, in my mind, your description of "each side" is ambiguous and I'm not sure if you're trying to make the right and left side of your drive train go forward at the same speed or if you're combining two motors on one side and trying to ensure those motors turn at the same speed.

Ok, to clarify...
We have two motors on the right side of the robot and two motors on the left side of the robot. This is a 4 wheel robot and each of the four wheels is driven by it's own motor.

First we would like to make sure that the wheels on each side are operating at the same speed. We have seen that even though both motors operate from the same PWM values, each motor tends to have unique characteristics and can operate at slightly different speeds. This can cause slight binding when both wheels on one side of the robot are not "in sync" speed wise.
We have calibrated the victors to our joysticks and this has helped tremendously.

Second, we would like to ensure that both sides operate at as close to the same speed as possible so that the operator doesn't have to compensate much with relative joystick positioning to make the robot track straight and true...

Hope that the above description is not too ambiguous...

thanks

[Leav]

Ok so to recap what people more experienced than me said here:

Regarding syncing two wheels on the same side, you can:

sync wheels using tachometer (this is a temporary solution, it will only work for a while and the effectiveness will probably fade)
sync wheels using a sensor that measures wheel speed in real time. (choose one wheel to be the reference and have the other change so that it is equal)
use a gearbox that accepts two motors and drives two wheels (this is food for future thought)


Regarding syncing the left wheel set to the right wheel set, you can:

sync wheels using tachometer (see above)
sync wheels using a sensor that measures wheel speed in real time. (integrates with the above option, so 4 sensors and a non-negligible amount of coding solves all your problems)
use a gyro (you should be able to use the size of the X value of the joystick as a base to compare gyro readings and adjust accordingly)


Good luck and don't hesitate to ask for clarification about anything or for more help!

-Leav

[EricVanWyk]

Has anyone here tried using the current sensors to do load balancing? If so, did it work well?

The basic concept would be to pull current information off of each motor, and use it to approximate the torque per motor. Then adjust the voltage sent to the motors so that they are contributing equal torque.

This only syncs the left side with itself and the right side with itself. It does not handle syncing left to right.

For the experts here: Can you please comment on how this balancing scheme might be impacted by motor variation? drive train variation? phase of the moon?

[Leav]

I think this would fall under the calibration idea, since as time went by the coefficient between the current and the speed would change and the whole system would go out of sync...

but that just off the top of my head.. the whole "breaking in" and "wearing out" effect i'm considering might only be significant to change the whole system by 0.5%, which means that the system would actually stay in sync for a long time...

unless someone did this before and tested in thoroughly there is no real way to know this but checking!

-Leav

p.s.
you would need to check what happens when there is maximum current and zero speed (i.e. the motor stalled [e.g. a pushing match])

p.p.s
don't you love recursive brackets? :)

[Richard Wallace]

...
For the experts here: Can you please comment on how this balancing scheme might be impacted by motor variation? drive train variation? phase of the moon?In my day job I design electric motors. My designs are not the same type that we use on FRC robots, but their basic physics is similar.

One of the most significant characteristics of any electric motor is its unloaded (free) speed at rated voltage. Let's take the CIM motor as an example: per its manufacturer's data sheet (http://web.archive.org/web/20050204235646/www2.usfirst.org/2005comp/Specs/CIM.pdf) its shaft will spin freely at 5310 RPM when 12V dc is supplied to its electrical terminals. Zoom in to view the table in the lower left corner of the data sheet linked above, and you will see that the manufacturer also states that the variation on the given free speed is +/- 10%. This variation is caused by differing strengths of the motor's permanent magnet material from one batch to the next, and by angular misalignment of the motor's commutation brushes with respect to those magnets.

The graphs shown next to the table on the data sheet linked above indicate that the CIM's current draw is proportional to the torque developed on its shaft. The constant of proportionality (i.e., the slope of the current vs. torque line on that graph) is determined by the same design factors, and the same variations, that determine the motor's free speed. So the stated +/- 10% free-speed variation applies to torque-per-Ampere also.

Because the causes of the variation are the same, using current sensors to 'correct' for free speed variation is probably not going to be very effective.

[EricVanWyk]

Because the causes of the variation are the same, using current sensors to 'correct' for free speed variation is probably not going to be very effective.

So using a current sensor *uncalibrated* is no better than just using uncalibrated PWM?

[Richard Wallace]

So using a current sensor *uncalibrated* is no better than just using uncalibrated PWM?Yes.

[Brandon Holley]

just to reiterate what others have said above me...

if you know the left side wheels are spinning the same speed as the right side wheels, your robot is more than likely going straight

how do you make sure your wheels are spinning at the exact same speed? richard made it clear that its almost guaranteed your motors will not be running at the same speed, so...using an encoder to check the wheels speed would most certainly make sure your robot is going straight.

[Daniel_LaFleur]

just to reiterate what others have said above me...

if you know the left side wheels are spinning the same speed as the right side wheels, your robot is more than likely going straight

how do you make sure your wheels are spinning at the exact same speed? richard made it clear that its almost guaranteed your motors will not be running at the same speed, so...using an encoder to check the wheels speed would most certainly make sure your robot is going straight.

Your statement makes a number of assumptions that may or may not be correct.

First assumption is that the floor (plane of travel) is perfectly flat, which will not happen on a carpeted arena surface.

Second assumption is that all wheels on the robot are the exact same size. This also will not be true, as variation in tread, tread attachment, or runner molding will create variances. It gets even worse with pneumatic tires ;)

If you intend on going only a short distance (under 10') then the error encountered by the above will probably not affect your performance, but going further will reduce your accuracy possibly to the point where you will miss your intended target zone. And none of this takes into account field obsticals(sp?), other robots, or wheel slippage.

To ensure you are going in the direction you wish to go in, the best ways (IMHO) are a gyro, a compass, or something like an optical mouse.

[Japper]

Ok so to recap what people more experienced than me said here:

Regarding syncing two wheels on the same side, you can:

sync wheels using tachometer (this is a temporary solution, it will only work for a while and the effectiveness will probably fade)
sync wheels using a sensor that measures wheel speed in real time. (choose one wheel to be the reference and have the other change so that it is equal)
use a gearbox that accepts two motors and drives two wheels (this is food for future thought)


Regarding syncing the left wheel set to the right wheel set, you can:

sync wheels using tachometer (see above)
sync wheels using a sensor that measures wheel speed in real time. (integrates with the above option, so 4 sensors and a non-negligible amount of coding solves all your problems)
use a gyro (you should be able to use the size of the X value of the joystick as a base to compare gyro readings and adjust accordingly)


Good luck and don't hesitate to ask for clarification about anything or for more help!

-Leav


Thanks for the info...
I have a power induction timing light that I use on timing automobile engines....

How might I connect this to the robot to measure/reference one of the wheels?

Would I connect it to 12v & ground and place the induction pick up coil around the positive motor lead and then draw a line on one of the wheels and the chassis for a reference point?

Please advise- any tips would be greatly appreciated

thank you!

[AdamHeard]

Your statement makes a number of assumptions that may or may not be correct.

First assumption is that the floor (plane of travel) is perfectly flat, which will not happen on a carpeted arena surface.

Second assumption is that all wheels on the robot are the exact same size. This also will not be true, as variation in tread, tread attachment, or runner molding will create variances. It gets even worse with pneumatic tires ;)

If you intend on going only a short distance (under 10') then the error encountered by the above will probably not affect your performance, but going further will reduce your accuracy possibly to the point where you will miss your intended target zone. And none of this takes into account field obsticals(sp?), other robots, or wheel slippage.

To ensure you are going in the direction you wish to go in, the best ways (IMHO) are a gyro, a compass, or something like an optical mouse.


294, and many other teams have used encoders to traverse in autonomous rather accurately; A gyro certainly helps, but it can be done without one.

[Daniel_LaFleur]

294, and many other teams have used encoders to traverse in autonomous rather accurately; A gyro certainly helps, but it can be done without one.

Truthfully, it depends on how far you are going and how accurate you need to be. With encoders alone, the further you travel the wider your target window needs to be.

[lukevanoort]

Truthfully, it depends on how far you are going and how accurate you need to be. With encoders alone, the further you travel the wider your target window needs to be.
Isn't that true of all sensors though? Gyros can drift; double integrating accelerometers isn't too accurate, and collision accelerations will probably exceed the number of Gs the device can handle; compasses are affected by EM fields; GPS won't always have a solid connection; optical mouse performance is heavily surface dependent; transmission encoders can be affected by wheelspin, tire variations, backlash, etc; pots have the same problems as encoders, but can also be affected by EM fields. Most of these errors end up being additive over the long run and result in a larger target region for longer distances.

The best way I can think of to eliminate the most potential problems is to run encoders on a non-driven, relatively hard, wheel. Wheelspin is no longer much of an issue, hard tires wear slowly (and if they wear too much, a little math in the code can easily correct for them getting smaller), and backlash can be more easily minimized since you would have far fewer possible sources of it.

[Daniel_LaFleur]

Isn't that true of all sensors though? Gyros can drift; double integrating accelerometers isn't too accurate, and collision accelerations will probably exceed the number of Gs the device can handle; compasses are affected by EM fields; GPS won't always have a solid connection; optical mouse performance is heavily surface dependent; transmission encoders can be affected by wheelspin, tire variations, backlash, etc; pots have the same problems as encoders, but can also be affected by EM fields. Most of these errors end up being additive over the long run and result in a larger target region for longer distances.

The best way I can think of to eliminate the most potential problems is to run encoders on a non-driven, relatively hard, wheel. Wheelspin is no longer much of an issue, hard tires wear slowly (and if they wear too much, a little math in the code can easily correct for them getting smaller), and backlash can be more easily minimized since you would have far fewer possible sources of it.


Agreed. And as the design engineer you need to decide which (mix?) of sensors will provide the accuracy for the task at hand.

My initial response was aimed at making sure that teams don't just "slap on" a few encoders and assume all will work.

Design in the sensors you need for the task at hand, and understand where your innaccuracies will come from. From there it's just a matter of limiting those inaccuracies and determining if the system you designed is accurate enough for the task at hand.

[TubaMorg]

Thanks for the info...
I have a power induction timing light that I use on timing automobile engines....

How might I connect this to the robot to measure/reference one of the wheels?

Would I connect it to 12v & ground and place the induction pick up coil around the positive motor lead and then draw a line on one of the wheels and the chassis for a reference point?

Please advise- any tips would be greatly appreciated

thank you!

Disclaimer:
If you choose to use the timing light option, keep in mind that it is the least effective of all the options presented thus far for a variety of reasons (all discussed previously).

I don't think an automotive timing light will work (I could be wrong) because it is typically triggered by the car's ignition system so that you get a flash every time the engine's #1 cylinder receives a spark. You need a strobe that is adjustable such that you can change the speed of the strobe to match the periodicity of the spinning object (the wheel).

Step by step for each wheel; robot on blocks; repeat forward and reverse:

1. Send a PWM value to the motor.
2. Wait for equilibrium.
3. Adjust strobe light until wheel appears to "stop". Be aware of harmonic frequencies: If the wheel is spinning at 100 rpm, the strobe will freeze the scene at a number of other possible frequencies. A single mark on the wheel will help eliminate some of the possibilities.
3. Note the PWM/wheel RPM values on your favorite spread sheet.
4. Increase PWM value (say by 5) and repeat until you maximize/minimize.

Once you have plotted the values for every wheel, you can now estimate how fast each wheel will turn for a given PWM value. In your program, you will take a joystick value to be a desired speed, then figure out what signal each wheel needs to match that speed.

This will work for a little while, but the more you drive your robot, the more changes will occur in the drive train components, which will lead to decline in reliability. Also you can see it is labor intensive to use this method. You really should consider using a GYRO!

Hope this helps.

[EricVanWyk]

Isn't that true of all sensors though? Gyros can drift; double integrating accelerometers isn't too accurate, and collision accelerations will probably exceed the number of Gs the device can handle; compasses are affected by EM fields; GPS won't always have a solid connection; optical mouse performance is heavily surface dependent; transmission encoders can be affected by wheelspin, tire variations, backlash, etc; pots have the same problems as encoders, but can also be affected by EM fields. Most of these errors end up being additive over the long run and result in a larger target region for longer distances.

The best way I can think of to eliminate the most potential problems is to run encoders on a non-driven, relatively hard, wheel. Wheelspin is no longer much of an issue, hard tires wear slowly (and if they wear too much, a little math in the code can easily correct for them getting smaller), and backlash can be more easily minimized since you would have far fewer possible sources of it.

Before you go this over-the-top, put together an error budget. Do you really need to be accurate to within an angstrom? How about a meter? Figure out just how sloppy you can be, and then start budgeting that sloppiness out.

This will also help you figure out what actually needs to be fixed. List all of your error sources and their contribution. You will end up with something that says "I can afford N% error, and right now I have a maximum of M% error." Then start chipping away at the important ones.

Don't compensate for Jupiter's gravitational pull before you make sure that your motors spin equally well forward and backward.

Pots being affected by EM fields? Probably not a big deal.
Getting hit by another robot? Probably a big deal.

Lastly, always remember that physics is a cruel mistress. She is out to get you. She is a bully. However, you can deal with bullies in two ways: Confront or Ignore. Ignore her minor grievances, save your energy for when she gets really out of hand.

[robogeek753]

Our team approaches this problem in a different way, and we have never had a problem with it. It works kind of like this, put two motors on one wheel (use a gearbox) and then use chain or a timing belt to link the two wheels (or, if you are really fancy, tracks!). Do this on both sides and the two motors act like one super powerful motor.

If you've never heard of us, we're the team that can push everyone else (well, almost everyone)

[Derek Bessette]

As Pat stated above, when it comes to motors on the same side there is no need to worry. If the gearbox ratio from the motor to the wheel is the same for each wheel then they will end up going the same speed. Any slight differences will not cause any binding.

As for making the robot go straight by balancing the two sides. Our tried and true method is to throw the motors on, setup the joystick trims and let her rip. If the robot goes straight you are done! If it doesn't then you can start using the encoders and gyro that you have designed into your drivebase along with some fancy PID programming to make that robot go straight.

If you don't need the encoders and gyro to make the robot go straight don't fret. Your time is not wasted. They will always come in handy when you start programming autonomous modes.

Good Luck!

[Brandon Holley]

Your statement makes a number of assumptions that may or may not be correct.

First assumption is that the floor (plane of travel) is perfectly flat, which will not happen on a carpeted arena surface.

Second assumption is that all wheels on the robot are the exact same size. This also will not be true, as variation in tread, tread attachment, or runner molding will create variances. It gets even worse with pneumatic tires ;)

If you intend on going only a short distance (under 10') then the error encountered by the above will probably not affect your performance, but going further will reduce your accuracy possibly to the point where you will miss your intended target zone. And none of this takes into account field obsticals(sp?), other robots, or wheel slippage.

To ensure you are going in the direction you wish to go in, the best ways (IMHO) are a gyro, a compass, or something like an optical mouse.

if you think i didnt know any of that, then thank you for trying to educate me, however i knew this, and based on the problem stated by the poster, and based on my overview of his/her knowledge i tried to make it as simple as possible.

[Al Skierkiewicz]

Japper,
In your original post you asked how to synchronize the motors on one side of the robot. In reality, if both front and back wheels on the same side are driven by similar motors with the same PWM value and both speed controllers are calibrated the same and the tread on similar sized wheels have a reasonable friction to the playing field surface, then the motors will drive the same speed. The only way they could not drive the same speed is for one of the wheels to be slipping.
The next step in complexity would be to use wheel encoders at both wheels with some software loop that allows you to modify the PWM values sent to the respective wheels. If the desire is to run straight and have all four wheels in sync then know that this is a mutually exclusive result. Running straight and in sync rarely occurs. It is more accurate to use a gyro system to run straight. However, the gyro does not give you distance traveled, so some form of wheel rotation sensor is still needed to run straight and to a specified distance.
Current monitoring on individual drive motors will give you no useful information unless you can correlate drive current and loaded speed on a motor by motor basis. The variations in motor construction (magnetic field, internal temperature, winding resistance, brush resistance, etc.) will affect the output loaded and unloaded speed of a motor. However, the transmission ratios will also be a determining factor in the wheel rotational speed.
The inductive timing light is triggered by the high voltage pulse that feeds the sparkplug. The pickup is actually a transformer where the sparkplug wire is a half turn primary winding. Since you have nothing on the robot that is in the 30kV range, there is no way to trigger the timing light.
The Banner sensors shining into a simple interuptor attached to the wheel make an excellent speed sensor. You can make a simple attachement for each wheel using a CAD program to draw a segmented circle with alternating light and dark areas. Divide your wheel into eight segments (four light and four dark) and you can get 16 transistions per rotation using this method. With a six inch wheel, this could give you resolution to a little over an inch of travel. Using two Banner sensors you can actually determine wheel direction as well.