Low resolution motor control

Here is an interesting problem, at least I think so, at "cruising speed," or there abouts, my PID algorithm works fine. At really slow "creeping speeds"
the encoder resolution and wheel gearing becomes an issue.
At the sample speed of the system, really really slow movement resolves to 1 encoder click per sample, or even a fractional click.
The first solution, obviously, is to address the gear ratio and get more clicks per sample, I can do that by using smaller diameter wheels.
The purpose of the $500 robot is to use commonly and cheaply available parts. As such, one is willing to trade some precision, but smooth creeping speeds are sort of important for finding or tracking objects.
Smaller wheels will help. Maybe adjusting the sample rate for slower speeds would be useful.
Anyone ever address this? Come up with a novel approach?
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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:

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
John Nagle 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.)

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
mlw wrote:

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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
John Nagle wrote:

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.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
mlw wrote:

...
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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
D Herring wrote:

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?

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Andras Tantos wrote:

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.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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:

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Jason S. Mantor wrote:

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

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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:

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Jason S. Mantor wrote:

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

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
mlw wrote:

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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Wed, 01 Mar 2006 12:18:26 -0500, mlw wrote:

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
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Brian Dean wrote:

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.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Wed, 08 Mar 2006 19:04:46 -0500, mlw wrote:

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 control the speed pretty well. It was actually acceptable for speeds > 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
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.