PID Motor control - Page 1
Forum section: electronics / projects

author: perdrix
author_rank: Frequent Contributor
timestamp: January 12, 2022, 03:36:06 am
content: Is there anyone skilled in this field who'd be prepared to help me?If so please contact me off-list mailto:david.partridge@perdrix.co.ukThanksDavid

author: waymond91
author_rank: Regular Contributor
timestamp: January 12, 2022, 10:14:43 am
content: There's a lot of information available for this.Here is a remote motor tuning I did with a custom PCB, firmware, software etc for a robot in California while I was living in Seychelles:Is there something in particular you need help with? How precise of a system do you need? What kind of motors are you using?

author: waymond91
author_rank: Regular Contributor
timestamp: January 12, 2022, 10:26:38 am
content: Here it is with the finalized platform:

author: Siwastaja
author_rank: Super Contributor
timestamp: January 12, 2022, 11:50:00 am
content: Single most helpful piece of advice which is most difficult to find anywhere, and I'll give it to you for free:Add feedforward. PID alone may be insufficient to achieve stability. Feedforward term is a trivial addition, let it do bulk of the work with P,I,D all set to zero, and only after that start tuning the P,I,D.

author: Mechatrommer
author_rank: Super Contributor
timestamp: January 12, 2022, 05:05:10 pm
content: Quote from: Siwastaja on January 12, 2022, 11:50:00 amwhats the catch?a) need to figure out mathematical model for the plant? and embed it in feed forward/back loop? let alone finding inverse function of it.b) add more sensors to detect disturbances?

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: January 12, 2022, 05:53:09 pm
content: I've never found the "D" in PID to be helpful in motor control. The derivative term is often noisy and difficult to tune. PI control seems adequate for most motor control applications.

author: Siwastaja
author_rank: Super Contributor
timestamp: January 12, 2022, 06:05:23 pm
content: Quote from: Mechatrommer on January 12, 2022, 05:05:10 pmOh, just feedforward from the setpoint is a start. It's utterly trivial. Another feedforward from the derivative of setpoint is almost as trivial, if you need to go further.In layman's terms, FF from setpoint is based on the fact that you need certain output to sustain certain speed (overcoming friction etc), and this is fairly linear relationship. FF gain models this part of the output.FF from the derivative of the setpoint is based on the fact that accelerating or decelerating a mass requires change in plant output, obviously.So these are simple physical models that require no sensing, and not much extra code, because you already have all the variables in the scope, you just add another constant (the FF gain(s)).Just instead ofoutput = P * err + I * err_accum + D * err_diff,useoutput = FF * sp + P * err + I * err_accum + D * err_diff,or evenoutput = FF * sp + FF_ACC * sp_diff + P * err + I * err_accum + D * err_diff,where err_diff obviously is cur_err - prev_err, but more importantly, sp_diff = cur_sp - prev_sp.The idea is to let the FF do the job which would otherwise require the I term to "catch up", making it either laggy to react (small I) or unstable (high I). Depends of course from the application and whether the controlled output is PWM duty, or actual current setpoint. If the output is PWM duty to the bridge (not the optimal way of doing thing, but it still sometimes happens you have just done that), driving a brushed motor for example, FF is specifically helpful, it will get you almost there alone!Best of all, FF from setpoint is easy to tune. Just turn P,I,D completely off and adjust FF so that the speed control works in the right ballpark. It can't obviously keep the right speed alone because of no feedback, but I mean, you can make car go roughly 50km/h by just "knowing" how far to push the pedal (feedforward from setpoint; no feedback). Actual speed if you don't look at the speedometer might be 30 km/h to 70 km/h, but hey, it's in the ballpark, this means when you add feedback, it needs to just tune the output, not take full responsibility of it. And FF's response to setpoint changes is instant, like with P, but without the instability of high P.Obviously, adding more "physical" feedforwards from extra sensors is the ultimate killer, but that may be excessively complicated.I managed to tame a very difficult, oscillating PID loop in a robot, by the following:FF from setpointFF from change of setpointFF from gyroPID (nearly unnecessary as said by Sal Ammoniac, but left it there anyway. Itwasimportant when the whole loop was iffy without the feedforwards. D helped at least a bit)Because the gyro was there to begin with, in the same bare metal codebase, this was trivial and I should have added it years earlier but just didn't think about it. It was a one-hour job. But if you have toaddthe gyro just for this, or cross difficult abstraction layers between realtime and non-realtime, then obviously the level of complexity totally changes.The root cause for issues in that particular case was the low encoder resolution in the wheels so that robot already turned many degrees before a "click" registered, fundamentally preventing any attempt of tuning the PID. Feedforwarding from the measured rate of rotation (gyro registers tiny changes like 0.1deg just fine, if they happen quickly), directly to motor currents which can be quickly adjusted regardless of the partially unknown position, fully stabilizes it.

author: langwadt
author_rank: Super Contributor
timestamp: January 12, 2022, 06:20:46 pm
content: Quote from: Siwastaja on January 12, 2022, 11:50:00 amyep, it depends a little on what you are doing, but for something like speed of a motor or temperature of a heater it never made sense to me no to add feed forward when you know that you need some drive in steady state.and if the output is already maxed out from P and D don't keep integrating, it doesn't help

author: Mechatrommer
author_rank: Super Contributor
timestamp: January 12, 2022, 06:58:04 pm
content: Quote from: Siwastaja on January 12, 2022, 06:05:23 pmthinking about it, setpoint can be anything, a coordinate, angle of rotation, temp etc. without comparing it with say current actual point, simply multiplying an absolute value of sp to a gain, rather than relative (comparison) value, sounds like a blind attempt to stabilize a system. do you have academic note on this? FF_ACC *sp_diffsounds like more reasonable though...Quote from: Siwastaja on January 12, 2022, 06:05:23 pmisnt physical model needs mathematical model to model the physical system?Quote from: Siwastaja on January 12, 2022, 06:05:23 pmiirc from my last attempt, D does help in "braking" the driving/actuating force when system is near setpoint, or help "reversing" when overshoot. the oscillation will be different with and without the D. but i have to admit i never made a motor that behaves like what i want it to (not stable or not robust enough) due to lack of time resource to really dig into on some hobby projects.

author: Siwastaja
author_rank: Super Contributor
timestamp: January 12, 2022, 07:56:53 pm
content: No, a motor control PID loop won't have temperature as a setpoint.There really are not many options for setpoints; motors can do one thing only, rotate. Normally there are 2-3 layers of feedback loops:1) Current feedback loop on the lowest level (see FOC for example). Setpoint: current. Output: PWM duty for example.2) On top of the previous: Speed feedback loop. Setpoint: speed. Output: current.3) On top of the previous: Position feedback loop. Setpoint: position. Output: speed.Chances are very very high that OP is asking about a speed controller.Current feedback loop is trivial (PI loop does it, and tuning is non-critical, right ballpark is OK.).Speed feedback is the usually challenging part.And of course, of course we can treat robot navigation around real surroundings "a feedback loop", but that can't be solved with any PID-like tool and surely this isn't what the OP means.Otherwise, I don't understand your reply and won't try to play your games since it usually makes no sense.

author: asdf336
author_rank: Contributor
timestamp: January 13, 2022, 12:37:01 am
content: Quote from: Siwastaja on January 12, 2022, 11:50:00 amFeedforward impacts performance. It shouldn’t impact stability. If it does stability is probably still marginal.

author: Mechatrommer
author_rank: Super Contributor
timestamp: January 13, 2022, 01:58:26 am
content: Quote from: Siwastaja on January 12, 2022, 07:56:53 pmi'm talking about any type of control system generally speaking

author: Siwastaja
author_rank: Super Contributor
timestamp: January 13, 2022, 09:27:08 am
content: Quote from: asdf336 on January 13, 2022, 12:37:01 amOf course it impacts stability, because less feedback is needed, and P, I, D gains can be reduced or completely eliminated. Stability issues are because of oscillating feedback, i.e., feedback overcorrecting, in other words, gain > 1 at crossover frequency. Most classically caused by excess P gain brought that high "for performance". If you get the same performance from FF, you can reduce P.Extreme example is a system which works well enough with feedforward alone. With no feedback, there is no way to it be unstable.

author: waymond91
author_rank: Regular Contributor
timestamp: January 13, 2022, 02:04:27 pm
content: I have found it useful in servo systems, but you're right, the term is super noisy. In my robot example above I had to pass the derivative term through an FIR filter to get rid of the noise.

author: jbb
author_rank: Super Contributor
timestamp: January 13, 2022, 10:05:58 pm
content: Yeah, the Derivative term is noise sensitive. I do power electronics, which often use Proportional-Integral (PI) controllers because there’s too much noise about.Adding some low pass filtering to the D term could help, I guess, by removing some of the higher frequency noise.Adding some low pass noise filtering (above the closed loop control bandwidth) to the Proportional can help with cleanup too. If you pursue that, it’s best not to add low pass filter to the Integral part, because a low pass adds phase delay and and integrator adds 90 degrees phase delay and that could eat up your phase margin.