Motor Bias

[gshosford]

We have observed that the CIM motor has a bias with different torque-speed characteristics depending on the direction of rotation. Karthik lists the torque speed characteristics for the CIM with CCW rotation. Does anyone have the torque and speed characteristics for the CIM motor in the CW direction?

[ConKbot of Doom]

The CIMs are supposed to be wound without bias, and haven't given us any trouble in the last competition that would seem to show a bias. But it would be nice if someone who had the facilities could get torque-speed curves for both CW and CCW.

Are you sure that its in the motors and not in the drivetrain hooked to the motors?

[Mike Betts]

We did extensive testing with the CIM motors last year and found no bias. However, we did note non-linearity in motor speed versus PWM command in the RC/Victor/CIM system. Also, we observed "bias" with the joysticks.

Both effects can be corrected in software.

A search of these fora (fori?) should give you more information on these topics.

Regards,

Mike

[mgreenley]

I concur with Mr.Betts,

The drill motors do have a bias, but as noted by Mr.Ross (post #7), here (http://www.chiefdelphi.com/forums/showthread.php?t=33847&highlight=Motor+Bias) , The CIM's should preform the same forwards and backwards.
In my experience, there is always a little difference between individual motors, but that is easily corrected for by your driver. If there's a large discrepancy, try calibrating the drive system (use dashboard to set your joysticks neutral, or use the "cal" button on the victors; hold it in then go through the full range of movement for your joystick.).
In autonomous mode, a way my team has found to compensate for this drift is to use encoders on both of your transmissions. That way, you can tell your program (In advance, I'm not a programmer, but hypothetically, this is how I'd use the encoders) to increase voltage to each side until they are equal at x rotations instead of telling the motors to increase their voltage to y Volts.
What I'm trying to get at is that it's probably easier to just minimize the difference, but if you're looking to completely equal it out, you'll probably need some sort of feedback via sensors to your RC. Hope this helps!

Mike

[ahecht]

We have found some variation in the CIM motors. Some will have no bias while other will have noticable forward or reverse bias. This is one of the reasons why we twisted the cans on ours to balance them last year -- to make them all consistant.

[greencactus3]

We have found some variation in the CIM motors. Some will have no bias while other will have noticable forward or reverse bias. This is one of the reasons why we twisted the cans on ours to balance them last year -- to make them all consistant.
twisted the cans? can you explain further on this? do you mean you realigned the brushes to the magnets? is that allowed?

[Billfred]

gc3, here's the further reading: http://www.chiefdelphi.com/forums/showthread.php?t=39818&highlight=190+servo+magazine

[dlavery]

twisted the cans? can you explain further on this? do you mean you realigned the brushes to the magnets? is that allowed?
No, modifying the timing of the motors in the kit is NOT allowed (at least not under the rules in 2005 and prior years). Okay, since this topic keeps coming up, lets try to take care of it once and for all. This issue was covered in Rule <R31> last year, and further reinforced in update #5 and in multiple Q&A answers. In 2005, Rule <R31> stated the following:
<R31> So that every robot’s maximum power level is the same, the motors in the kit may not be modified except as follows:

• It is acceptable to modify the mounting brackets and/or other structural parts of the motors (output shaft, housing, etc.) as long as the electrical system is not modified and the integral mechanical system of the moving parts (bearings, bushings, worm gear output stages, etc.) is not changed or removed.

• The gearboxes for the Fisher-Price, and Globe motors are not considered “integral” and may be separated from the motors. FIRST will not provide replacements for parts that fail due to modification.

[Clarified in Team Update #5: ] The intent is to allow teams to modify mounting tabs and the like, not to gain a weight reduction by potentially compromising the structural integrity of any motor.
Notice the underlined phrase. Make a logic flow chart and trace out the logic path if you have to. If you do ANYTHING to modify the performance of a motor, it is subject to Rule <R31>. The rule is very straightforward - YOU MAY NOT MODIFY THE MOTOR. It doesn't matter if you are rewinding the armature, reducing the rotating mass, strengthening the magnets, altering the structure to modify the field strength, or anything else - including altering the timing of the motor. And let's be very clear, altering the timing of a motor is definitely a modification to the performance of the motor - otherwise why would you be doing it - so any such alteration would be subject to this rule.

The rest of the rule provides for two, and only two, exceptions. The first exception permits modification of the mounting surfaces of the motors for the sake of attaching the body of the motor to the robot, and the output shaft of the motor to the structure to be actuated (as even further clarified by the note in Update #5). The second exception explicitly permits the removal of the gearboxes from the Fisher-Price and Globe motors. These two exceptions do not enable any other modifications. There is nothing in either of these exceptions that would permit altering the timing of the motor. Since the exceptions do not cover such a modification, then such a modification would be subject to the primary statement of the rule - "the motors in the kit may not be modified."

The rule is explicit (read the WHOLE RULE, not just the exceptions). The logic is clear (map out the logic of the rule - it is really quite simple). The intent of the rule is explained ("so that every robot's maximum power is the same" is pretty clear). If you alter the timing on the motors, or drill holes in the casings (which alters the airflow, thereby changing the cooling characteristics thus altering the performance), or turn down the casing thickness (which alters the field strength, thereby affecting the performance), then you have violated the rule. Such modifications are NOT allowed. If a team violated the rule but didn't happen to get caught by an inspector, that does not change the fact that the rule was broken. If the rule was violated accidentally because they didn't read the rules or didn't understand them, then it is incumbent on the team to correct the situation immediately when their error is discovered.

-dave

[Joe Johnson]

And besides... ...there are many teams that just make their drivers deal with it!

I will repeat my mantra again:
Drive time and less engineering trumps clever engineering and no drive time.

Don't short change your drivers. They really need drive time.

Joe J.

[Tytus Gerrish]

much like people No two motors are exactly identical. nor will be there precise speed in forward and reverse. but when you have these motors plugged into a robot moving it around the field the difference in performance is Hardly if not Completely unnoticeable. so honestly just don't worry about it these are 130 pound robots made by high school kids as long as they can move where they need to move and do what they need to do its a perfect robot it doesn't matter if it does not move completely straight. Even for aton mode the difference in performance of motors has no humanly noticeable effect on the functionality of a robot. Damage, poor lubrication. goofed up wheels, chain tension, belt tension, wear and tear, un-symmetrical chassis and less than perfect drive trains are the Prime contributors to a robot not moving in a straight line.

[JVN]

We have found some variation in the CIM motors. Some will have no bias while other will have noticable forward or reverse bias. This is one of the reasons why we twisted the cans on ours to balance them last year -- to make them all consistant.

I've never seen anyone SO proud of breaking a rule.

[sanddrag]

Yes. See the thing is, how do we all know that you didn't make them "consistent"ly 15% more powerful than stock? We don't. And for this reason the motors must be left stock. As I see it, there is really no good reason I can think of to even loosen their screws. If you had a motor that were really dissimilar to the others (maybe 6% or more out of spec) than perhaps it had a manufacturing defect and you should have obtained a new one.

[Andy A.]

After a lot of run time, the brushes on a motor may wear in such a way that one direction will have more and cleaner contact then another. This could have an impact on speed/torque in one direction and not the other.

I have seen motors that over time loose power in one direction, but seem like new when run in the other direction. This was very apparent in motors used in a roller system that almost never has to be run in reverse. Forward would clearly be slower and have less torque then reverse even when accounting for things like wear in the drive train.

I'm just guessing that the cause has something to do with an uneven wear or gunk build up on the brushes. Could some one with more expertise on DC motors clear that up for me?

Out of the box, the CIM motors should be unbiased.

-Andy A.

[KenWittlief]

I would think that maybe over time parts of the motor would become magnetized, that would make them run better in one direction?

if you degaused them, they would go back to normal, or ran them backwards for a while?

[MikeDubreuil]

I've never seen anyone SO proud of breaking a rule.

I don't want to jump on the WPI bashing bandwagon... but last year WPI defended their right to reduce the thickness of the housing in the CIM motor in this thread (http://www.chiefdelphi.com/forums/showthread.php?t=33313). I'm not exactly sure what is going on in Worcester but it appears to me that some rules are being followed a bit too liberally.

[gshosford]

The CIMs are supposed to be wound without bias, and haven't given us any trouble in the last competition that would seem to show a bias. But it would be nice if someone who had the facilities could get torque-speed curves for both CW and CCW.

Are you sure that its in the motors and not in the drivetrain hooked to the motors?

We changed the program to lower the maximum pwm to each motor. As I recall we calibrated the Victors before we started our test. We put the robot up on blocks to check wheel rotation so the wheels were not in contact with the floor. With a PWM of 127 + 32 to one Victor and 127 - 32 to the other Victor there was a significant difference in the two motor speeds. When we moved the joystick to the opposite extreme, the motor that had been the faster of the two became the slower of the two and the one that had been the slower of the two became the faster of the two. The observations are qualitative, but there were significant differences between CW and CCW motor speeds.

[KenWittlief]

When we moved the joystick to the opposite extreme, the motor that had been the faster of the two became the slower of the two and the one that had been the slower of the two became the faster of the two. The observations are qualitative, but there were significant differences between CW and CCW motor speeds.

Where they both faster going 'forward' on your robot? most bots have the motors mounted so one is running cw and the other is ccw when the bot goes forward.

I wonder if its the motors that are biased, or your drivetrain. If both sides run faster in the bot-forward direction, I would say its your drivetrain.

also, it would really help to measure wheel RPMs. Basing your estimate of speed on how the drivetrain sounds can be very misleading.

[Mike Betts]

We changed the program to lower the maximum pwm to each motor. As I recall we calibrated the Victors before we started our test. We put the robot up on blocks to check wheel rotation so the wheels were not in contact with the floor. With a PWM of 127 + 32 to one Victor and 127 - 32 to the other Victor there was a significant difference in the two motor speeds. When we moved the joystick to the opposite extreme, the motor that had been the faster of the two became the slower of the two and the one that had been the slower of the two became the faster of the two. The observations are qualitative, but there were significant differences between CW and CCW motor speeds.

The effect that you saw was discussed in length in this thread (http://www.chiefdelphi.com/forums/showthread.php?t=31903). We verified Jim Rickertsen's data (see the attached plot (http://www.chiefdelphi.com/forums/attachment.php?attachmentid=3100)) and were able to linearize the CIM speed to PWM command.

Note that this is a system issue. I never determined if it was the IFI controller or Victor issue and did not care... The bottom line is that it is NOT the CIM.

Regards,

Mike

[KenWittlief]

Its easy to get the victors and robot controller out of the loop

unhook the motors from the victors, and power them directly from a battery, measuring the rpm's of the wheels going forward and reverse

[gshosford]

Where they both faster going 'forward' on your robot? most bots have the motors mounted so one is running cw and the other is ccw when the bot goes forward.

I wonder if its the motors that are biased, or your drivetrain. If both sides run faster in the bot-forward direction, I would say its your drivetrain.

also, it would really help to measure wheel RPMs. Basing your estimate of speed on how the drivetrain sounds can be very misleading.

With the joystick in the full forward position, the right motor, for sake of explanation, was turning faster than the left motor. With the joystick in the full reverse position, the left motor was turning faster than the right motor.

This surprised both of us that were working on it because all the discussions state that the CIM has virtually no bias.

The observations were visual not audible. We could see that one motor was turning much faster than the other motor.

Mike Betts' response with the link to the free-speed data was helpful. Does anyone have the stall torque data?

[dlavery]

With the joystick in the full forward position, the right motor, for sake of explanation, was turning faster than the left motor. With the joystick in the full reverse position, the left motor was turning faster than the right motor.

This surprised both of us that were working on it because all the discussions state that the CIM has virtually no bias.

The observations were visual not audible. We could see that one motor was turning much faster than the other motor.

Mike Betts' response with the link to the free-speed data was helpful. Does anyone have the stall torque data?


According to the CIM Motor Spec Sheet (http://www2.usfirst.org/2005comp/Specs/CIM.pdf) from the 2005 FIRST Spec Sheet List (http://www.usfirst.org/robotics/2005/specsheets.htm), the CIM motor stall torque is 343 oz-in at 12volts. 12 volt free speed is 5310 rpm (+/- 10%)

-dave

[billbo911]

With the joystick in the full forward position, the right motor, for sake of explanation, was turning faster than the left motor. With the joystick in the full reverse position, the left motor was turning faster than the right motor.

This surprised both of us that were working on it because all the discussions state that the CIM has virtually no bias.

The observations were visual not audible. We could see that one motor was turning much faster than the other motor.

Mike Betts' response with the link to the free-speed data was helpful. Does anyone have the stall torque data?
I don't mean to state the obvious, but......
By any chance, were you configured for one joystick drive? If so, you could quite easily have this behavior even if you had two perfectly matched CIMs. All that would need to have happened for this was that the Y axis trim pot on the CH joystick be off center. This might not even show up with the stick in center position. With a dead band of ~+/- 10, you could have been adding 9 to one side and subtracting it from the other. Then in the opposite direction, the reverse would be true. Your description bears this out.

[Matt Leese]

Did you at all check the calibration of the Victor? You could put a voltmeter on the output of the Victor and measure the voltage. It should be the same in both directions (well, one should be the negative of the other). It would also be interesting to see what the current draw of the motor in both directions was.

Matt

[Billfred]

I don't mean to state the obvious, but......
By any chance, were you configured for one joystick drive?
Indeed, 1293 has used nothing but one joystick to drive since the days of window motor drive.

I suppose our Saturday just got more interesting.

[gshosford]

According to the CIM Motor Spec Sheet (http://www2.usfirst.org/2005comp/Specs/CIM.pdf) from the 2005 FIRST Spec Sheet List (http://www.usfirst.org/robotics/2005/specsheets.htm), the CIM motor stall torque is 343 oz-in at 12volts. 12 volt free speed is 5310 rpm (+/- 10%)

-dave
I'm sorry that I was not more specific. Does anyone have the stall-torque data over the full range of PWM outputs through the Victor, comparable to the free-speed data in the graph to which Mike Betts' response (#18) is linked?

[Joe Johnson]

I'm sorry that I was not more specific. Does anyone have the stall-torque data over the full range of PWM outputs through the Victor, comparable to the free-speed data in the graph to which Mike Betts' response (#18) is linked?

There is a lot of debate as to why the freespeed vs PWM value does not follow a linear relationship as one would expect by the simplication of saying

(Voltage to Motor) = K * (PWM Duty Cycle)

I have seen this in my former day job with Delphi. I will put in my two cents as to how to understand this nonlinear response on the tail end of that message at some later date.

BUT... ...everything I have seen in my outside FIRST experience is that this non-linearity pretty much disappears at when the motor is stalled.

(Stall Torque of Motor) = K * (PWM Duty Cycle)

There is some loss due to frequency effects especially at low duty cycles but for the most part, my experience has found this to be a minor effect.

Getting data on this is more bother than free speed because the motors get hot which causes its own problems. If I had time, I would run this case in a Matlab simulation... ...too much to do... ...too little time...

Joe J.

[Gdeaver]

If you follow the thread that Mike Betts referenced there is a link that does explains the nonlinear response. Basically, the motors are not a pure resistive load. The motors have rest stance, capacitance, and inductance. The motors are not being driven by a constant DC voltage. They are driven by a pulse. Found it. Here's the link-speed controllers (http://homepages.which.net/~paul.hills/SpeedControl/SpeedControllers.html) One thing that the link does not mention is the internal resistance of the battery. It also can affect the performance curve. Last year on our bot we had to increase the right side drive train by 4 PWM counts to drive straight. It was applied for both forward and reverse. I attribute it to the gear box. It had more backlash and was noise from day one.

[Eldarion]

We changed the program to lower the maximum pwm to each motor. As I recall we calibrated the Victors before we started our test. We put the robot up on blocks to check wheel rotation so the wheels were not in contact with the floor. With a PWM of 127 + 32 to one Victor and 127 - 32 to the other Victor there was a significant difference in the two motor speeds. When we moved the joystick to the opposite extreme, the motor that had been the faster of the two became the slower of the two and the one that had been the slower of the two became the faster of the two. The observations are qualitative, but there were significant differences between CW and CCW motor speeds.

I have "experimentally" (unknowingly!) verified this. After an hour of "why won't the robot drive straight!??!", we got the bright idea to flip the motor output wires on the Victors and send the same values to all the drive PWMs.

Suprise, all the problems went away and the robot drove straight as an arrow. :rolleyes:

This can be a very frustrating problem at first, though! :)