Drill Motor Inconsistency

FIRST General Forum
1

Posted by Raul, Engineer on team #111, Wildstang, from Rolling Meadows & Wheeling HS and Motorola.

Posted on 4/15/99 10:14 AM MST

We have noticed that the drill motors on our practice robot do not run at the same speed at full throttle. One of the motors is running as much as 20% faster in one direction and 5% in the other. The obvious affect is that the robot travels on an arc instead of in a straight line.

Has anyone else dealt with this problem? We obviously cannot try to fix this with HW because then spare drill motors will have different characteristics. Did anyone have an efficient SW fix for this?

Raul

2

Posted by P.J. Baker, Engineer on team #177, Bobcat Robotics, from South Windsor High School and International Fuel Cells.

Posted on 4/15/99 12:24 PM MST

In Reply to: Drill Motor Inconsistency posted by Raul on 4/15/99 10:14 AM MST:

I don’t know of an easy SW fix, but make sure that it isn’t a problem w/your speed controllers (i.e. test motor speed hooked up directly to a battery). I’m sure that you guys have tried this, but it’s the only thing that comes to mind. Good luck. I’m looking forward to visiting Wildstang in the pits next week.

P.J.

3

Posted by Raul, Engineer on team #111, Wildstang, from Rolling Meadows & Wheeling HS and Motorola.

Posted on 4/15/99 2:31 PM MST

In Reply to: Re: Drill Motor Inconsistency posted by P.J. Baker on 4/15/99 12:24 PM MST:

: I don’t know of an easy SW fix, but make sure that it isn’t a problem w/your speed controllers (i.e. test motor speed hooked up directly to a battery). I’m sure that you guys have tried this, but it’s the only thing that comes to mind. Good luck. I’m looking forward to visiting Wildstang in the pits next week.

: P.J.

Yes, we hooked both drill motors to the same voltage source and used an oscilliscope to count the RPMs. So, we know it is not the speed controllers.

We actually ran with these mismatched motors at Great Lakes and were having problems going straight at high speeds. We had brought spare drive modules and decided to replace them because the thread on the wheels of the ones we had shipped had worn out a bit from the previous regional.

Raul

P.S. I am also very anxious to see all the great new robots in the pits that we did not get to see at Great Lakes.
P.S.S. You guys did a nice job of showing your robot capabilities on your website. Our team decided not to do the same. We figured that our strengths will be self-evident when you watch us play.

4

Posted by Jerry Eckert, Engineer on team #140 from Tyngsboro, MA High School and New England Prototype/Brooks Automation.

Posted on 4/15/99 5:27 PM MST

In Reply to: Re: Drill Motor Inconsistency posted by Raul on 4/15/99 2:31 PM MST:

: Yes, we hooked both drill motors to the same voltage source and used an oscilliscope to count the RPMs. So, we know it is not the speed controllers.

I’m intrigued… How do you measure the motor RPMs with an oscilloscope?

As for using software to compensate: the only way I can think of doing
this is using te yaw rate sensor. Between the resolution of the sensor
and the limitations of the control system, I’m not sure if you’ll be able
to achieve an acceptable level of control, though.

- Jerry
5

Posted by Joe Johnson, Engineer on team #47, Chief Delphi, from Pontiac Central High School and Delphi Automotive Systems.

Posted on 4/15/99 6:44 PM MST

In Reply to: Re: Drill Motor Inconsistency posted by Jerry Eckert on 4/15/99 5:27 PM MST:

One possible SW fix would be to slow down the fast motor, not ideal but better than driving in circles.

Here is how I would appoach it to keep from being locked into on particular motor pair (assuming that you don’t want to have to reprogram with each motor change).

I propose that you define two ‘special modes’ for you controller. A rocker switch works just fine.

While the rocker is rocked forward, use the value of an non self-centering pot (Wheel1 for instance) to modify the full forward value of one motor or the other (e.g. pot values above 128 would reduce the high value of the RH motor, while values below 128 would reduce the high value of the LH motor).

Write the values to EEPROM space while the button is held down (at fewer than 20 writes per second it would take forever to reach the write limits of the EEPROM).

While the rocker is rocked back, use the value to modify the full reverse value of one value or the other. (using the same technique as above).

Then, each time through the main loop, scale the values of the outputs to these motors by the values stored in EEPROM.

Essentially, you need define a piecewise linear function that scales the outputs so that 128 maps to 128 and 254 maps to the appropriate value determined while in adjustment mode(s). 0 similarly scales to the adjusted value from the EEPROM.

To tweek the motors, drive the machine forward while in ‘forward adjust’ mode, using the pot to get the machine to go straight. Do the same for reverse.

When you let go, your controller knows how hard to drive each motor in order to have the speeds match.

Pretty cool…

Joe J.

P.S. I know that something like this works because we do a similar scaling in order to ‘zero’ our joysticks. We got tired of ripping off the tape we have covering the trims on the joystick in order to prevent our robot from drifting off on us. It really works well. If you see Jeremy ‘The Stamp2 Guru’ Husic in the pits, I am sure he’d show you the code and give you a demo. JJ.

6

Posted by Jerry Eckert, Engineer on team #140 from Tyngsboro, MA High School and New England Prototype/Brooks Automation.

Posted on 4/15/99 7:19 PM MST

In Reply to: a possible SW fix posted by Joe Johnson on 4/15/99 6:44 PM MST:

: P.S. I know that something like this works because we do a similar scaling in order to ‘zero’ our joysticks. We got tired of ripping off the tape we have covering the trims on the joystick in order to prevent our robot from drifting off on us. It really works well. If you see Jeremy ‘The Stamp2 Guru’ Husic in the pits, I am sure he’d show you the code and give you a demo. JJ.

We got around this by programming a dead zone in the center range of the
joystick. If the input value is in the range 118-138 it is set to 128.

This doesn’t eliminate the need for taping the trimmers, but we haven’t
had to readjust them yet.

- Jerry
7

Posted by Michael Betts, Engineer on team #177, Bobcat Robotics, from South Windsor High School and International Fuel Cells.

Posted on 4/16/99 7:26 AM MST

In Reply to: Re: a possible SW fix posted by Jerry Eckert on 4/15/99 7:19 PM MST:

:
: : P.S. I know that something like this works because we do a similar scaling in order to ‘zero’ our joysticks. We got tired of ripping off the tape we have covering the trims on the joystick in order to prevent our robot from drifting off on us. It really works well. If you see Jeremy ‘The Stamp2 Guru’ Husic in the pits, I am sure he’d show you the code and give you a demo. JJ.

: We got around this by programming a dead zone in the center range of the
: joystick. If the input value is in the range 118-138 it is set to 128.

: This doesn’t eliminate the need for taping the trimmers, but we haven’t
: had to readjust them yet.

: - Jerry

We do the same on the Bobcat.

8

Posted by Raul, Engineer on team #111, Wildstang, from Rolling Meadows & Wheeling HS and Motorola.

Posted on 4/16/99 5:41 AM MST

In Reply to: Re: Drill Motor Inconsistency posted by Jerry Eckert on 4/15/99 5:27 PM MST:

: : Yes, we hooked both drill motors to the same voltage source and used an oscilliscope to count the RPMs. So, we know it is not the speed controllers.

: I’m intrigued… How do you measure the motor RPMs with an oscilloscope?

This is how it was explained to me by Jim Butler, our EE, who did the measurements:

These measurements were made with an oscilloscope and a current-sensing resistor. As conditions required, the period of the brush-induced spikes in voltage (measured at the motor) or current (measured across the resistor)
were measured using the oscilloscope. ‘As conditions required’ means that sometimes the voltage, and sometimes the current, was the simplest waveform in which to ‘see’ the spikes.

Spikes are most easy to measure in groups of five and the reason is that there’s ‘five’ spikes per rotation of the armature. It turns out that various conditions, presumably related to the condition of the brushes and commutator, cause the waveform (as least the smooth part of it, which is related to the steady-state flow) to be periodic; I saw quite a bit of variation in this waveform between the six motors and even between direction on each motor, which seems to indicate that certain areas of their brushes/commutators aren’t making great contact.

9

Posted by Michael Betts, Engineer on team #177, Bobcat Robotics, from South Windsor High School and International Fuel Cells.

Posted on 4/15/99 3:52 PM MST

In Reply to: Drill Motor Inconsistency posted by Raul on 4/15/99 10:14 AM MST:

Raul,

We have not seen this problem (at least nothing of this magnitude).

I assume that you have tried replacing the slower motor… That would eliminate brush problems.

Short of a very improbable factory problem where motors are wound with a different number of turns, I would guess that the speed difference is due to friction.

Try testing the speed without the gear cases attached.

Mike

10

Posted by Joe Johnson, Engineer on team #47, Chief Delphi, from Pontiac Central High School and Delphi Automotive Systems.

Posted on 4/15/99 7:06 PM MST

In Reply to: Re: Drill Motor Inconsistency posted by Michael Betts on 4/15/99 3:52 PM MST:

Raul,

Did I miss something?

I assumed that you had the motors out and on a bench.

While those cool homemade gearboxes allow you to swerve with the best of them, they are definitely a suspect when trying to track down your speed variation.

We have been building gearboxes for our FIRST robots for 4 years now. We have yet to have them work without ALOT of handwork.

Look to the gearboxes if you haven’t already.

Joe J.

11

Posted by Rick Berube, Engineer on team #121, Rhode Warriors, from Middletown H.S…

Posted on 4/17/99 4:35 PM MST

In Reply to: Drill Motor Inconsistency posted by Raul on 4/15/99 10:14 AM MST:

: We have noticed that the drill motors on our practice robot do not run at the same speed at full throttle. One of the motors is running as much as 20% faster in one direction and 5% in the other. The obvious affect is that the robot travels on an arc instead of in a straight line.

: Has anyone else dealt with this problem? We obviously cannot try to fix this with HW because then spare drill motors will have different characteristics. Did anyone have an efficient SW fix for this?

: Raul

Yes. We saw this problem both last year and this year. our motor’s this year are much more closely matched however. The biggest problem is due to the topology. Mounting the motors in a symetric fashion typically forces one motor to always run in the reverse direction of the other.
We got around this in software. basically we generated PWM to RPM curves for the motors. Since motor’s are pretty much linear creatures at heart, (within most of their operating range), we limited the operating range of the faster of the two motors to that of the slower. We then overlaid the two PWM/RPM profiles using y= mx + b. By tweaking m & b coefficients accordingly, you should be able to align any two motors. We felt being able to control the robot worth the trade off in speed/power.
this year, since the mismatch is not as nearly pronounced, our kids simply make the adjustment when driving. They drive tank-style so this has not been a problem for them. we do not use the X-axis of the sticks. If we did, we would have chacterized and made the same adjusments we made last year.

PS. A word of warning. While it is tempting to use the look up features of the PBASIC language, this can be terribly slow when the number of terms get large. the lookup function on the PIC is reading EEPROM for stored coeffecients to compare against. If you plan to use a lookup statement, keep the number of terms down to a minimum. Otherwise, while you may find the control very linear, but the response very sluggish. Also because the lookup function may traverses the list differently base on he value of the stick position, the delay imposed on your control loop will vary accordingly. Scaling and adding an offset imposes a small delay which is always fixed in duration.

Hope this helps,

Rick