DPRG
DPRG List  



[DPRG] Motor control

Subject: [DPRG] Motor control
From: Dale Wheat dale at dalewheat.com
Date: Sat Jun 7 22:39:01 CDT 2003

Kenneth,

You're right about the arithmetic.  Once I start writing code it will all be
in "encoder counts per timer tick", but for now let's discuss it in more
civilized terms.

OK, now we're on to something!  Assuming the robot is just going to go
around in circles, counter-clockwise as seen from above, the right wheel is
going to go faster/farther than the left wheel.  If the circle described by
the center point of the robot as it rolls around has a diameter of ten feet,
or a radius of five feet, and the wheelbase is one foot, then the path of
the right (outside) wheel is a circle with a diameter of 10 feet plus one
foot, and the path of the left (inner) wheel is a circle with a diameter of
10 feet minus one foot.

That sounds wrong, but only because I was talking in diameters and not
radii.  If the radius was 5 feet, the path of the right (outer) wheel would
be 5 feet plus half the wheelbase (the distance from the center of the robot
to the right whee), or 5-1/2 feet, same as a diameter of 11 feet.  The path
of the left (inner) wheel, likewise, would be five feet minus half the
wheelbase, or 4.5 feet.  It would seem that velocities would simply differ
by the wheelbase (per whatever time units the velocities are referenced).

Let's say that the robot is running in 10 foot circles at 1 ft/sec.  That
means it will take ~31.4 (PI * 2R) seconds to make the loop.  The right
wheel is actually going farther (PI * 2R + 1) in the same time, or 1.1
ft/sec (1 ft/sec + 1/10 ft/sec), and the left wheel is going 0.9 ft/sec (1
ft/sec - 1/10 ft/sec).  If it was a 20 foot diameter circle, the right wheel
would be going 1.05 ft/sec (1 ft/sec + 1/20 ft/sec), and the left wheel
would be going 0.95 ft/sec (1 ft/sec - 1/20 ft/sec).

So to turn in an arc with a radius R,

right_motor_velocity = Velocity + ((wheelbase / radius) / time)
left_motor_velocity = Velocity - ((wheelbase / radius) / time)

Where "Velocity" (with a capital V) is the desired velocity of the center
point of the robot, as described by David in his original post, and "time"
is equivalent to whatever unit you're using for "Velocity" (to keep our
units straight).

A radius of zero adds nothing to either the left or right motor velocities,
so the robot would go straight ahead.  A negative radius will turn to the
right instead of the left.

Is any of this right?  Is this just a special case for travelling in arcs?
I'm still wondering how to specify the original angular displacement over
time (Rotation) for doing things like spirals and tangents, etc.

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: "Dale Wheat" <dale at dalewheat.com>; "DPRG" <dprglist at dprg.org>
Sent: Saturday, June 07, 2003 9:03 PM
Subject: Re: [DPRG] Motor control


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


More information about the DPRG mailing list