DPRG
DPRG List  



[DPRG] Motor control

Subject: [DPRG] Motor control
From: Kenneth Maxon kmaxon at uswest.net
Date: Sat Jun 7 20:27:01 CDT 2003

In David's system to implement an arc wouldn't one command a rotation at the
same time as a translation?

     -Kenneth
      (Unit 3's in trouble and it's scared out of its wits) -Geddy Lee
----- Original Message -----
>From: "Kipton Moravec" <kip at kdream.com>
To: "Dale Wheat" <dale at dalewheat.com>; <dprglist at dprg.org>
Sent: Saturday, June 07, 2003 5:45 PM
Subject: Re: [DPRG] Motor control


> 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
>
> _______________________________________________
> DPRGlist mailing list
> DPRGlist at dprg.org
> http://nimon.ncc.com/mailman/listinfo/dprglist
>


More information about the DPRG mailing list