How to turn the PID parameters of the motor driver when the speed is low

I assume you are trying to tune a 500 Hz (cycle/second) or 1KHz motor. You start with finding the modes of the system, then drive it with the proper equations. Reactive forces might change with speed, but modes does not.

Your problem isn't really in controlling the motor itself, it arises from using the an encoder, whose output becomes insufficient as the speed gets very low.

I'll tell you right now, if you don't happen to have the hardware in place than you need and if you can't add it, then your options are limited.

First, and conceptually easiest, change your sensor: add a tachometer to your motor, get an encoder with many more counts, or use a resolver. You probably don't have room or budget to do any of these or you would have already, but it's nice to think about.

With the tachometer, feed it's output to and ADC, and there you are -- velocity feedback. You'll have to put some deadband around your position error so you don't hunt around an integer increment of the encoder, but that's life.

With the enhanced resolution encoder or the resolver, it's even easier -- just change your scaling, and there you are. Motor systems always have oddball start-stop behavior because of friction, if you select an encoder with a resolution well below the limits of this nastiness then you will have done your best.

If your stuck with your mechanical plant, but you can hang timers on the encoder inputs, then time the edges of the motor pulses to get the motor speed. Your "vibration" is most likely jerkiness caused by inaccurate speed estimates caused by encoder resolution, coupled with insufficient filtering in your differentiator -- keying off of the phase transition times will go a long way to alleviating this problem.

If you can't do _that_, then you're getting into some pretty difficult territory. The best bit of control system wisdom that I ever heard from a greybeard was "you can't make a silk purse out of a sow's ear". Bode proved part of this theorem with his Sensitivity Integral, which says you can't make the silk purse if your bandwidth is restricted; experience and common sense tells you that any real system is going to have a bandwidth that's restricted by the mechanical plant. If your mechanical plant is so restricted that it's a sow's ear -- there you are.

So you can experiment with deadband and with changing your tuning parameters as the motor speed changes, and you may be able to get something that works well enough with what you have. But be careful, because you may also end up with an overly-tuned system that only works on your laboratory test example, and completely fails to work in the real world.

Why not change from measuring counts per second to measuring seconds per count, when the speed is slow. Then convert that to counts per seconds and continue?

to

from

with

says.

Thank you very much for your good advise. We also want know what resolution of the encoder is appropriate to our application. Is there any exact formula to compute? Thank you for your advise again!

to

from

with

is

from

gets

to

You

position

--

encoder

the

motor

from

you

and

bandwidth

real

Your ideal is good and novelty! But how can we achieve it as the present encoder mostly measures by counts per second! Thank you for your advise!

It's not exactly novel, but it is certainly a good idea. You need some sort of timer triggered on the edges of your encoder inputs, and simply time the length of the pulses. Just make sure you trigger on the same edge of the same signal each time (encoder pulses make *look* square on an oscilloscope, but they are never truly square).

Could you please avoid using two hyphens as an em-dash in your posts? After re-wrapping in later quotations, these have ended up at the start of a line and then newsreaders will treat them as the start of a signature, and snip half the post.

mvh.,

David

Not novel >>>> speed. Your "vibration" is most likely jerkiness caused by inaccurate

Instead of deciding on the method in advance, simply count both timer ticks and events until one of the two exceeds a threshold, then stop on the next occurence of the other. A division then gives you the rate. That means two interrupts, and some common code. Each can shut down the other, but startup launches both and sets the thresholds.

If your reader does that it is wrong. A sig marker is a line containing ONLY "-- ". Nothing more (apart from the '\n'). If the result of a rewrap there will be at least a quote marker before it.

Yes, that's the way it is normally done if you have a wide enough range of speeds. I started trying to explain that, but deleted my text because it sounded too complicated for the OP (although your explanation is simpler than my aborted attempt).

My newsreader (Thunderbird) is correct - it is reacting to lines that contain only a "-- " in mjjun's earlier post (the one I replied to). Try it out with your own newsreader.

It would appear to be mjjun's newsreader ("EmbeddedRelated.com usenet HTML frontend") which is broken, and inserting the quote markers before re-wrapping. Proper newsreaders can normally deal with such broken quotation handling, but the wrapped sig marker seems to be a bigger challenge. I realise that the "correct" reaction is to tell mjjun to get a proper newsreader, rather than asking Tim to cramp his style and avoid "--".

I think you still should have tried. It would convince the OP that increasing the resolution of his feedback is the way to go or at least the first step. Companies like BEI make high resolution encoders that can provide 500,000 counts per revolution.

Peter Nachtwey

Actually, the resolution of the feedback is not necessarily relevant. The *accuracy* of the feedback (i.e., the consistency of the positioning of the encoder pulses at a given constant speed) is important - and higher resolution encoders will have more accurate pulses. But the resolution only affects the minimum sample time for your samples (and thus the slowest speed you can measure in a given time interval). The resolution of your sampling timers is more directly related to the accuracy of the result.

But as I said, a higher resolution encoder will be more accurate, and is therefore preferable. It may also let the OP use a simple counts-per-time-interval measurement.