Solutions for implementing combined feedforward and feedback control

[banksey255]

I have combined feedforward and feedback control to achieve quite good control, however there is a limitation that I'm interested in getting ideas for solving.

The problem is both the feedforward and feedback control respond to setpoint disturbances, as they should (the setpoint is the feedforward control input and the error, which is the setpoint minus the process variable, is the feedback control input), and in the continuous time domain this is fine, but in the discrete time domain where my controller operates, this is a problem as my controller update interval is not deterministic, thus when my controller updates, the feedforward control can't extrapolate forward to the next controller update to know what it should output, and thus must remain causal (that is, it's output can only be based on the current setpoint function). As such, error will, in general, acrue with respect to the change in setpoint between controller updates (we use piecewise ramped setpoint profiles, so the setpoint is continuously changing), thus the feedforward and feedback control end up both responding to setpoint changes whereas, in an ideal world, only the feedforward control should, which results in overcompensation.

The only idea I have for solving this is for the special case where I know the feedforward control output won't change frequently, in which case every time it does I could skip the feedback control update. I'm hoping there is a more elegant general solution. Making my control update interval deterministic is impossible unless I forcibly slow it down significantly due to my controller running on Windows and being dependent on the time it takes to communicate with hardware, both of which aren't deterministic.

No need for LabVIEW code on this one, conceptual ideas will be more than adequate.

[banksey255]

I worked through the mathematics in the z transform domain and found that theoretically implementing feedforward in discrete time requires knowing what the setpoint will be the next controller update, so I suppose that means to improve things, one way for my situation is to compute the average controller update interval and extrapolate based on that, but a proper solution requires a deterministic controller update interval.

I'm still curious if anyone can suggest any alternative solutions.

[Bob_Schor]

Having never formally taken Advance Signal Theory (or class with a similar name), I don't have an answer for you, but surely this is a topic that has been studied.  I'm not even sure I'd know how to "Ask Google" to suggest articles to read, but you, I suspect, will know this better than I.

If you find helpful and useful information, come back here and point us to "learning material".

Bob Schor

[banksey255]

Hi Bob, I found another approach, but it only supported my original conclusion. That is, for quasi-perfect setpoint tracking, an alternative to feedforward is the Zero Phase Error Tracking Control (ZEPTC) algorithm, and like feedforward, it requires knowing what the setpoint will be at future controller update(s): https://engineering.purdue.edu/ME576/ZPETC_Tomizuka.pdf. Mind you, mathematically it appears they are equivalent, so perhaps it's not surprising that they lead to the same conclusion.

Having pursued this line of inquiry, I am beginning to suspect that actually backlash may the most significant contributor to the imperfect setpoint tracking that I am observing, with limitations in my feedforward control implementation playing a less significant role. That is, I effectively get feedback from the next part in the mechanical sequence to my motor, and when I set a constant position setpoint, I observe limit cycles, as described by https://pure.tue.nl/ws/files/4295876/633392.pdf, and because of backlash, when I start a ramped position setpoint, it takes a moment for my motor to apply motion to that next part in the mechanical sequence.

[Bob_Schor]

Makes sense.  Noise and non-linearities have a way of confounding control algorithms -- sometimes the better strategy is "don't try to be perfect ...".

Bob Schor

[banksey255]

I will have a play and see how much I can improve things, but that won't be until April, so is some way off.

In the meantime, as a follow-up: Is anyone aware of a way to easily distinguish a critically damped response from an overdamped response? I ask as an underdamped response is easy to identify as it has the unique characteristic that it will oscillate as it decays, whilst, in contrast, unless I've missed something, it appears there is nothing unique and obvious about the overdamped response. If so, then the only way to identify whether the response is overdamped is to adjust the controller transfer function to theoretically make the system response less damped and to see if it becomes underdamped, and if it doesn't, then we can conclude that it must have been overdamped, however this is trial and error, which I'm not a fan of.

[Bob_Schor]

Your description of how to distinguish critically damped from over- or under-damped is basically the "definition" of those three states:

• If it "rings" (or overshoots, then undershoots, and eventually reaches equibrium), it is "underdamped".
• If it doesn't ring, it is either "over-damped" or "critically damped".
• The setting that gets it to equilibrium in the shortest time gives you the "critically-damped" state.

Bob Schor