DPRG
DPRG List  



[DPRG] Motor control

Subject: [DPRG] Motor control
From: Kenneth Maxon kmaxon at uswest.net
Date: Sat Jun 7 21:00:02 CDT 2003

Okay, sorry, where was my brain?  Missing when I wrote the last post, most
likely.

The difference in velocity of the 2 wheels is dictated by the 2 different
circumferences that you want them to traverse.

For example if you want to arc left around a point 5 inches to the left of
the robot for 1 second then the left wheel needs a velocity of 2*PI*5
in/sec.  If your robot is 4" wide, the right wheel then needs a velocity of
2*pi*(5+4) in/sec.  The relationship is defined by the distance between he
wheels on your robot.

As was previously mentioned, it may be much easier to do this math in
encoder tics/internal robot state update.

     -Kenneth
      (Unit 3's in trouble and it's scared out of its wits) -Geddy Lee
----- Original Message -----
>From: "Dale Wheat" <dale at dalewheat.com>
To: "Kenneth Maxon" <kmaxon at uswest.net>
Sent: Saturday, June 07, 2003 6:40 PM
Subject: Re: [DPRG] Motor control


> Kenneth,
>
> I believe you are right.  What I wanted to know was the relationship
between
> the values used for linear velocity (Velocity) and angular velocity
> (Rotation) for an arc of a given radius.
>
> For example:  The robot should start going forward and arc to the left.  I
> want the radius of the arc to be 5 ft (let's call that 5,000 encoder units
> for those who don't like to mix units).  If the linear velocity is set to
> some reasonable value, what would the angular velocity (Rotation) be?
>
> There's got to be a geometric way to figure this out, and not resort to
> empirical methods.  Or maybe not.  I'd like to know if this approach
> supports this.
>
> Thanks,
>
> Dale Wheat
> http://dalewheat.com
> (972) 486-1317
> (800) 330-1915, access code 00
>
> ----- Original Message -----
> From: "Kenneth Maxon" <kmaxon at uswest.net>
> To: "Kipton Moravec" <kip at kdream.com>; "Dale Wheat" <dale at dalewheat.com>;
> <dprglist at dprg.org>
> Sent: Saturday, June 07, 2003 8:31 PM
> Subject: Re: [DPRG] Motor control
>
>
> > 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