DPRG
DPRG List  



[DPRG] PWM drift correction

Subject: [DPRG] PWM drift correction
From: David P. Anderson dpa at io.isem.smu.edu
Date: Sat May 20 00:06:45 CDT 2000

Howdy,

Patrick Innes writes:

> Recently, one of the other threads on this list has
> mentioned using PWM adjustments to correct for drift
> that arises from differences in motors, wheels,
> traction, etc.

PWM signals (Pulse Width Modulation) can be used to drive
an H-Bridge or similar device that's providing the power
for a DC motor.  Varying the pulse width effectively varies
the RMS voltage that drives the motor, and that varies the
speed of the motor.

So two motors that are controlled by PWM signals can have
their input voltages adjusted independently, and in this
way make up for differences in motor performance, friction,
un-matched wheels, and so forth.

It cannot make up for the drift that arises from problems
with traction and varying loads, and inclined or otherwise
un-level surfaces.  These need some kind of closed-loop
feedback system that can adjust the PWM values automatically.

A common method of doing this employs shaft encoders mounted
on the output wheels or directly to the motors.  These are
used to measure the precise speed of the wheels.  A software
routine monitors these encoders for each wheel and adjusts the
PWM values to the motors to maintain a constant speed.  This
makes the robot run straight as an arrow, quite impressive.

An alternate method is to use a tail-wheel with a shaft encoder
on it's vertical axis.  Something as simple as a pot read by
an A/D port can be used to return a value proportional to the
tail wheel's absolute location.  The idea is to get the robot
to drive in a straight line by monitoring the position of
the tail wheel and using that to adjust the PWM values to
maintain the line.

My experience has been that PWM alone, without some kind of
feedback, is much less effective.  

Clay Timmons used open-loop PWM (no feedback) for one of his robots.
He steered the robot by setting the PWM values for each wheel.  So a
left turn might have a PWM value for the right (outer) wheel of n,
and a PWM value for the left (inner) wheel of n/2.  The left wheel
would run slower than the right wheel and so the robot would turn left.

One of our Lego robots works the same way, and has the same problem.

The problem he had was that the loads on the two wheels were different
>from one type of floor (carpet) to another.  So the size of the turn
was different on different types of floor.  Further, the loads on the
wheels changed in the course of the turn, so the size of the curve
changed from beginning to end of a single turn, in an unpredictable
way.  All this meant that it was difficult to time the length of the
turn, or to know when it was finished.

Shaft encoders, a tail wheel rotation sensor, or some similar feed-
back mechanism (GPS?) solves these and related problems by making
the speed of the wheels independent of the load.  PWM values do not
have to be carefully set by the Builder, but rather are set automatically
by the feedback system, and respond to changing loads and even changing
battery levels.  Turn sizes can be specified very exactly, and these
are independent of the type of floor, incline, etc (within limits.)

> I am aware that the "Mobile Robots" book addresses
> this issue with code for an HC11-based board, however,
> as programming is not my strong point (THAT'S an
> understatement!), I was unable to puzzle out exactly
> what was going on with it.  

PWM generation on the HC11 is very hardware specific, essentially
run by timers built into the microprocessor.  A cool but not
particularly generic solution.

> Has anyone ported this code for use on a BASIC stamp
> or similar unit?  Can it be done?

Bound to be.  With all the BASIC stamp robots out there.  Ask
James Vroman for a pointer.

dpa



More information about the DPRG mailing list