Electronics > Mechanical & Automation Engineering

PID control and different sampling rates

(1/2) > >>

Hi there,
the task is to design and implement PMSM Motor controller. Current control works nice with PI, no issue there.
Controller is called every second PWM tact, what is enough in comparison to time constant of motor winding.
Real challenge is measurement of motor speed. Until now there was an incremental encoder with 4096 steps.
The speed as number of encoder steps in controller unit time was enough.
Now comes the challenge. I have to use Hall encoder only. It has 6 steps over the full evolution (pole pairs = 1).
The problem I have already stated is: Over many (even few thousends) PID cycles position reported thru Hall stays unchanged if the motor rotates slowly. It means that controller is blind to reaction until the Hall slope comes.
What can I do to improve this situation? Is an low pass filter on speed signal a good solution? Filter will cause delay and potentialy stability issue within closed loop control.
Thank you in advance for any ideas.

Ah, the problem of having to control slow motor speeds with insufficient resolution for speed sensing. There is no good or simple solution this, or solution at all. By far the best idea is to use a higher resolution encoder.

You can, of course, interpolate the encoder position e.g. by assuming that the time difference between two latest events (i.e. speed) remains constant and thus keep ramping the position variable blindly.

Or just try to make the control loop as good as humanly possible, meaning extreme effort at tuning the PID variables but also adding other strategies like feedforwards. Anytime your feedback signal sucks, feedforward is the obvious solution, but then you need some kind of model of the system. Simplest types of feedforwards are, (1) just add a term with a ff_constant * setpoint, (2) add ff_acceleration_constant * (setpoint - prev_setpoint).

I had similar situation with a mobile robot with two motorized wheel with only the 6-steps per electrical revolution hall sensors. At high speeds it maneuvered fine but slow speeds were impossible to tune. FF(setpoint) + FF(derivative of setpoint) + P + I + D all carefully tuned made it relatively OK-ish but the final thing that fully stabilized it was another feedback, from gyroscope yaw angle angular rate directly to motor currents. That one reacts very fast, even to small changes. Like, if one motor was getting just a half of a hall step ahead of the other, that was already showing as significant rotation of the robot, drunk mode oscillations ensuing. Gyro feedback fixed that simply with just a few lines of new code. Much easier than trying to solve the problem by tuning the PID loop until cows come home.

I could have added feedforward component from the orientation of the robot; i.e., going uphill more current is needed. The advantage of feedforwards is, they react quick and can't cause oscillations.

So maybe see if you can find secondary sources (other than the measured rotor speed) for feedbacks/feedforwards. If nothing physical to measure, then feedforwards from the setpoint and setpoint derivative still help.

A complex possibility is to implement some kind of model-based control. If you can somehow measure the power inputs and outputs from the motor and driven equipment, and if you can measure or calculate the inertia of the system, then you can potentially predict the motor speed by doing a dynamic power balance or torque balance. The inputs from the hall sensor can then be a feedback correction on what is otherwise a feedforward system.

Granted, this may not be practical, but in the spirit that you asked for ideas, it is a suggestion.


Without an high resolution encoder there are severe limits on controlling the motor at low speeds, while with a (reasonably) high resolution encoder, you can control the motor down to zero rpm (for example deliver torque, but no movement).

So whether you can achieve your goal depends on the motor, and how low the speed you need is. A higher pole count helps at low speed. Depending on your application, a stepper motor may be a better option. There are also 3 phase stepper motors, and those are very similar to PMSM motors, but have a higher pole count.

If you know the motor position with a high enough resolution (encoder) then you can generate a 90 degree phase difference to generate torque even when the motor is at a standstill. With only Hall sensors, this is simply not possible anymore. (Unless those hall sensors are combined in some high resolution encoder contraption, but that is another topic).


[0] Message Index

[#] Next page

There was an error while thanking
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod