Motor Bias

[gshosford]

Originally Posted by 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?

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]

Originally Posted by gshosford

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]

Originally Posted by gshosford

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. We verified Jim Rickertsen's data (see the attached plot) 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]

Originally Posted by KenWittlief

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]

Originally Posted by gshosford

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 from the 2005 FIRST Spec Sheet List, the CIM motor stall torque is 343 oz-in at 12volts. 12 volt free speed is 5310 rpm (+/- 10%)

-dave

[billbo911]

Originally Posted by gshosford

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]

Originally Posted by billbo911

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]

Originally Posted by dlavery

According to the CIM Motor Spec Sheet from the 2005 FIRST Spec Sheet List, 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]

Originally Posted by gshosford

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 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]

Originally Posted by gshosford

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.

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