DPRG
DPRG List  



[DPRG] Motor control

Subject: [DPRG] Motor control
From: Kipton Moravec kip at kdream.com
Date: Sat Jun 7 17:46:00 CDT 2003

At 02:15 PM 6/7/03, Dale Wheat wrote:
>David,
>
>Thanks for the good information about motor control.  Thanks also for
>explaining it to me in agonizing detail last Tuesday.  Although I'm chomping
>at the bit to understand PID motor speed control algorithms (which will be
>fun, because I barely know what an integral (The I in PID) is and until last
>Tuesday had no clue what a derivative (The D in PID) was), I have to make
>sure I completely understand what has been covered so far.
>
>As usual, I'd like to go over a few points in some more detail, mostly
>concerning units of measure.  Please correct me if my assumptions are
>incorrect.
>
>The "arbitrary scale" of -100 to +100 in the first method expresses a value
>of power applied to the motors.  This is "open-loop power control" and does
>not take into account variations in motors/gears/wheels, friction, voltage,
>slopes, etc.  Applying an equal amount of power to both wheels does not
>guarantee driving in a straight line.


That is correct. That is "open-loop" control.  By getting feedback from a 
sensor, like wheel encoders, you know how much the wheel turns, or the 
distance traveled.  That is "closed-loop" control.  The PID algorithm 
generates an estimate necessary to spin the wheels dispite the differences 
in "motors/gears/wheels, friction, voltage, slopes, etc."



>The next step involves dealing with the abstract quantites velocity and
>rotation.  Velocity is defined as distance over time.  For our purposes, the
>distance can be measured in shaft encoder counts (which hopefully can be
>accurately translated into some more traditional linear measurement like
>feet, inches, furlongs, parsecs, etc.), while the time is broken down into
>the units between each measurement made.  On SR04, for example, the time is
>50ms, since measurements are taken 20 times a second.  So (linear) velocity
>is expressed as encoder counts over timer ticks.

That is correct.

>Rotation (or more accurately rotational velocity) is defined as angular
>displacement over time.  To use the equations presented, where rotation is
>added or subtracted from the left and right velocities, respectively, the
>units of measure would of course have to be the same, namely encoder counts
>over timer ticks.  If the wheelbase (the effective distance between the
>wheels) is expressed in encoder counts, then the angular displacement can
>also be expressed in radians, using one of the odometry equations,
>specifically "theta = (right - left) / wheelbase".  The rotational velocity
>can then be expressed as the angular displacement (either in radians or
>encoder counts) per timer tick.
>
>If the observer (me) is looking down on the robot from a height (and until I
>build a flying/hovering robot, I will be), rotation to the left
>(counter-clockwise) would be expressed as a positive angle and rotation to
>the right (clockwise) would be a negative angle.  Since turning to the left
>necessitates slowing down the left motor, or speeding up the right motor (or
>both), shouldn't the equations be:
>
>Left_motor = Velocity - Rotation
>Right_motor = Velocity + Rotation
>
>instead of the other way around?

It depends on how you define your coordinate system. In general I do not 
like to mix units, so velocity and rotation can not be added or subtracted 
>from each other.  Always work in common units.  If you are working with 
speed, then stay in encoder ticks/ sec, or radians/timer tick or whatever 
you want.  But do not mix them up.  As a general rule, a good working 
system is to stay in encoder ticks/timer tick.  That makes most of the 
lowest level calculations dealing with simpler integers, and not as complex 
other units like feet/sec.  If you need feet/sec you can convert only when 
you need it.


>This next step seems like it will make things much simpler when traveling in
>a straight line (I wish!) or turning in place, but what about describing an
>arc?  It seems to me that it would be easier or at least more accurate to
>make a turn about a point other than the center of the robot, since the
>measured distances would be larger and suffer less from round-off error in
>odometry, or would these benefits be outweighed by the increased cumulative
>navigational error?  It occurs to me that there should be a simple way to
>express this given the level of abstraction already in place.  The exact
>translation escapes me at the moment.  Also, since all my robots seem bound
>and determined to travel in arcs, anyway, I think it would be wise to "go
>with your strengths" and find a way to let them do what they do best, and
>still do what I want.

To describe an Arc one wheel turns at so many encoder ticks/timer tick, and 
the other wheel runs at a different encoder ticks/timer tick.  (Don't 
forget you have to take into consideration the different diameters of the 
wheels.)



>Any thoughts would be appreciated.  All you other nav-geeks feel free to
>pitch in.  The last couple of days' discussion on "dead reckoning" have also
>been enlightening.

I would probably have "canned" arcs that I could choose from if that is the 
way you want to go.  Calculate the speed (encoder ticks / timer tick) for 
how many ticks for each wheel to make the arc you desire.


>Thanks,
>
>Dale Wheat
>http://dalewheat.com
>(972) 486-1317
>(800) 330-1915, access code 00

There is another approach to the problem.  That is to route plan for every 
tick.  Prior to reading the encoder value, you calculate what it should be 
to be on the path you desire at the speed you want.  You do this for each 
wheel, and the wheel tracks the given path.  This is different then the way 
David does it.

David's approach commands the wheels to go at a certain speed.  The PID 
Controller gets the wheels to that speed and holds that until something 
changes.  It is hard to predict the ramp-up and how fast it will reach the 
desired speed.  This can cause errors when turning.

The approach I described you would set the ramp up for each sample.  It is 
a tighter control, (and hopefully if used correctly) would reduce the 
angular errors (for turning).

It is a little more complicated as you have to have a route planner as well 
as the PID control to stay on the route.

Kip


>----- Original Message -----
>From: "David P. Anderson" <dpa at io.isem.smu.edu>
>To: <dprglist at dprg.org>
>Sent: Saturday, June 07, 2003 11:18 AM
>Subject: [DPRG] Motor control
>
>
> >
> > Howdy
> >
> > As per our discussion of motor control from last week's
> > RBNO, I thought I'd try to summarize the scribblings on
> > the whiteboard and perhaps clarify a couple of points.
> >
>(omitted)
>
> > Left_motor  = Velocity + Rotation
> > Right_motor = Velocity - Rotation
> >
>(omitted)
> >
> > Next week, the PID Speed Controller...
> >
> > hope this helps!
> > cheers,
> > dpa
> >
> > _______________________________________________
> > DPRGlist mailing list
> > DPRGlist at dprg.org
> > http://nimon.ncc.com/mailman/listinfo/dprglist
> >
> >
>
>_______________________________________________
>DPRGlist mailing list
>DPRGlist at dprg.org
>http://nimon.ncc.com/mailman/listinfo/dprglist


More information about the DPRG mailing list