Low resolution motor control

    You can use a software-implemented PLL to increase the effective
number of encoder counts.  This only works if the speed of the
wheels doesn't change more than 20% or so per polling period.

    Here's a useful paper:

       http://www.web-ee.com/primers/files/pll_tut_talk.pdf

    Before you attempt something that complicated, try putting
a low pass filter on the velocity; that may be almost as
good.

                John Nagle

mlw wrote:

I'll look at the paper, but I can't see how I can stay within that 20%
window when the margin of error is over 100% on fractional ticks.



That should have the same affect of reducing the sampling time.

The more I think about it, the more I like reducing the sampling time and
calibrating the various gains for a "slow mode." I'm pretty sure that the
motor behavior at or near stall is far different than rotating under
dynamic load.

It may be an interesting twist on the PID code to dynamically alter the
sample rate based on the speed. (As I write that sentence, it sounds
obvious.)

    No, the question is how fast the actual velocity changes, not the
encoder differences.  If the mechanical system has enough inertia
that the velocity changes slowly, relative to the polling period,
averaging over multiple polling periods will work.  If not, it
won't.

    Both the PLL and the low pass filter are averaging schemes.
The low pass filter has more lag; that is, the velocity value
will always be somewhat behind reality.  When you have lag,
the D gain has to be smaller, or the system will oscillate.

                John Nagle

We are talking very slow speeds, the motors are pretty powerful, and the
resolution very low. It has the tendency to lurch.


Tuning isn't an issue, it really is that the some cycles get no motion
feedback, and thus accumulate error. Then they bump up the power output and
then pass their projected position.

I've tried a slower sample rate, it behaves much better are slower speed. I
need to recalibrate gains for the slower sample rates.

I think I will just have two settings: creep and run.

Try increase the proportional gain and decreasing the integral gain.
You might need to add a constant offset to your voltage calculations.
Say Vout=Vmin+Kp*error+..., where Vmin=+/-(just below the minimum
voltage needed to keep things spinning); this will help counteract the
dead zone you have at low speeds.

Are you trying for position control or speed control?  If velocity
control, then you really need to filter the velocity signal; something
simple like v[new]=0.6*v[old]+0.4*v[calculated] can be very effective,
where 0.6+0.4=1; tweaking these numbers gives a faster or slower
response.  Another popular filter type is to use the weighted average of
the last few velocity calculations; something like
v[used]=0.5*v[now]+0.3*v[previous sample]+0.2*v[2 samples ago].


Lowering the sample rate is merely another way of averaging the values;
it has the same effect of delaying the values, but you don't get them as
frequently.  Simple filters like mentioned above will generally perform
equally or better under all conditions (fast or slow).  Unless processor
power is limited, at which time a slower sampling rate may be better.

Daniel

Nope, just starts to oscillate.


I do have an "acceleration" constant that may work, hmmm very interesting
thought.

Actually, the PID loop controls velocity as managed by a path planner which
works on position.


I wouldn't characterize it as a response time problem, it really is that the
period between transitions on the encoder are greater than or equal to the
sampling period.


Is it averaging?

Look up some articles on frequency counters. They have some interesting
solutions. In general the idea is not to count the number of 'ticks' in a
given interval, but to count the time elapsed between two 'ticks'. The
former one works for high speeds, the latter one for low speeds. There's a
combinational method as well: count the time elapsed between the first and
the last ticks, and the number of ticks, both over a fixed time interval.
Than devide the two numbers to get the avg. time between ticks. Something
along those lines.

Regards,
Andras Tantos

I was considering something like that for a while, I am using a mouse
interface for my two wheels. I can be fairly confident of the results over
time, but I don't think I can depend on them from point to point.

Is it a quadrature encoder ?
If it is, then you can interpolate in between counts
by looking at the analog signals.

If it's that mouse wheel thing, you could add another
sensor and make it a quadrature encoder : )

-JSM

mlw wrote:

It's the mouse wheel thing and it is a quadrature encoder and I have it at
the highest resolution. :-)

Can you get at the raw analog signals ?
They'll look like sine waves and you can interpolate the "angle" in
between counts.

mlw wrote:

I *could* if I were to implement encoder hardware in addition to sing the
PS/2 mouse system.

I did firmware for the servo system for the paper path on an inkjet
printer and we ran into similar problems, running out of information at
low speeds. The ugly part about low speeds is you start to get down into
the stick/slip area of motion and not having enough measurement
resolution made it impossible to deal with. Finally, we implemented
analog augmentation of the standard quadrature encoder and it solved the
problem. It was relatively easy to get 64 interpreted points per digital
transition. With enough measurement resolution, one of the techniques we
had tried earlier solved the problem.

Good Luck,
Bob

I ran into this on our DARPA GC vehicle - a 1987 Chevy suburban.  We did
not have a large budget, so we made use of what we had where we could.
What we had at first was the odometer cable and speed sensor which was
basically a flat piece of metal on the end of the unit.  I made a simple
sensor which sensed the metal blade pass by the sensor as the odometer
cable turned:

  http://www.insightracing.org/pictures/test9.5.04/images/DSC00544.jpg

This unit sat on the end of the odometer cable and I got two pulses per
revolution.

Similar to your problem, the resolution is just too low and there's not
enough information delivered for low speeds.  I worked on this quite a
while and about the best I could come up with at the time was instead of
measuring the pulses within a given period, I simply measured the time
between pulses.  The problem with that was that the speed of rotation of
the blade was non-linear.  I.e., within a single revolution, the
rotational speed of the cable changed dramatically and seemed very
springy. I think this was due to the way the cable twisted and snaked up
from the transmission to the back of the dashboard.

At any rate, with some averaging, I did get reasonably acceptable results
for speed around 4 to 5 MPH and above.  But it was still poor for speeds
below that.  Also, the PID algorithm was interesting in that the frequency
of data update was variable.  The faster we went, the faster it updated.
This is different than the usual method of counting ticks for a fixed
period which results in a fixed update period and I had to adjust my
algorithms accordingly to record and utilize the time interval between
updates since this was not longer fixed.

We eventually just bit the bullet bought a few high resolution quadrature
encoders which were 600 count per revolution (we got two, one was a
spare). We also cut the odometer cable and mounted the encoder under
the truck frame as close to the odometer cable attachment point as
possible to reduce the wind-up springy problem of the odometer cable.
This worked very well.

My MAVRIC-IIB and my PID routines were much happier with this. The 600
count encoder allowed extremely tight speed control of our 5500 lb truck.

So if you can get a higher resolution encoder, that is by far the
easiest solution.  It doesn't have to be expensive.  We got ours off
e-bay for under $70 for the pair.

But I'm surprised you don't get better resolution, especially since
your mouse encoder is attached to the fast spinning motor rotor, as
opposed to the slower turning output gear shaft.

-Brian
--
Brian Dean
ATmega128 based MAVRIC controllers
http://www.bdmicro.com/


 Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
    ** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------        
                http://www.usenet.com

I suppose I could figure out a way to do that, but I'm using a PS/2 mouse as
the encoders, and I'm not sure I would trust the time difference.

LOL, odemeter cable. I'm kind of a car buff, I know exactly what you are
saying. Funny problem, though.

Hmm, thinking about PID and control of a truck, presumed to have an
automatic transmission, did your system wig-out on shifts?


Yup, my encoders cost $4.99 for both of them. LOL, using a PS/2 port mouse.
I found a higher resolution mouse in my basement, I may try that. I am also
thinking about slowing down the sample rate at "creeping" speed, and
lastly, smaller diameter wheels.

As a side note, I really feel the mouse system is really really reliable.
The only problems I have has have been typical of any R/D motor control
project.


The gear ratio is not as good as you might think. I have it written down,
but if I recall, it is like 1/2 or 1/4 a turn per cm at the wheel. A
smaller wheel will make that better. That combined with an optional slower
sampling speed and maybe a high resolution encoder should fix it.

Actually, It may make sense to keep the lower resolution encoder. When it is
"creeping" one presumes this is for precision movement and sampling less
often may leave more CPU time available for processing. Also, at higher
speed, the higher resolution encoder has a higher risk of losing counts.
I'm not using a real time system.

Nope.  It was very smooth, even through gear changes.  Our DARPA chase
vehicle driver commented to us after driving behind it all day through
the harsh desert environment that the control was super-smooth.  He
said we went through stuff where he wouldn't want to drive himself,
and it was very gentle on the gas, did not spin in the soft sand.  He
was worried we were going to spin-out and get stuck in a few places,
but the PID and controls did their job very well and we kept on going.
At least up to the point where we had an apparent transmission problem
at dreaded mile 28.  I also capped vehicle acceleration so I'm sure
that helped to keep us from spinning out and getting stuck.

But the smooth control all begins with a high feedback rate which
provides you with the ability to adjust the throttle and brake at an
equally high rate.  There's only so much you can do to accomodate a
low update rate.  Low update rate = poor response.  High update rate =
crisp response.  Considering how low the update rate was before we
upgraded our encoder, it is a testament to just how good a well tuned
PID algorithm is that it could compensate and that we were able to
5 to 7.  But due to the squirreliness of the odometer cable sensor and
its non-linear rotational speed, we'd still get the occasional 200 MPH
sensor reading even then which would need to be filtered out.  But
once we got the encoder and I adapted the code to use it instead of
the slow feedback sensor, the difference was night and day.

-Brian
--
Brian Dean
ATmega128 based MAVRIC controllers
http://www.bdmicro.com/


 Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
    ** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------        
                http://www.usenet.com