How to Filter a Commanded Position to have Velocity and Acceleration Limits in Simulink

I want to filter a commanded position signal to limit (saturate) its velocity and acceleration. I made the following model, but it has issue with the initial conditions and drift. If the signal is not saturated, I want it to equal the commanded position signal. Any suggestions on how to best model this?

[Mathieu NOE]

see

matlab - 3rd-order rate limiter in Simulink? How to generate smooth triggered signals? - Stack Overflow

Answer 1

[Paul]

I'm not sure that it's feasible to meet all of the stated requirements, particularly "If the signal is not saturated, [it should] equal the commanded position signal." One option that may be close to what you want is to drive the input through a high bandwidth, low pass filter, and use the appropriate thresholds on the states in the filter. Like this:

Set the velocity and the acceleeration limits in the block parameters of the second order integrator. Choose the gains to give a smooth and fast response relative to your input. One option would be:

K1 = w^3; K2 = 3*w/K1; K3 = 3*w^2/K1;

where w is chosen such w/3 is about 10 times larger than the largest frequency in the position command. You might have to play with that parameter for the specific position commands of interest.

This approach should yield position, velocity, and acceleration that are consistent with each other, but the position won't ever be exactly equal to the position command. It will get closer as w increases, which will also decrease the simulation step size, assuming use of a variable step solver.

[Sonoma Rich]

This filter design seems to be what I am looking for. I noticed that if the gains are high, you can get this ringing effect at intermediate input frequencies. At high input frequencies, the filter is a bang-bang controller. At low frequencies, it follows the signal very well. I am wondering if there is a way to reduce the ringing effect. Thanks for the submission.

[Paul]

What gains and what input result in the ringing effect?

The transfer function of the filter (when not in saturation) using the gains posted above is

which should shouldn't have a ringing effect. The idea is to choose w large enought such that H(s) ~ 1 for all input frequencies of interest.

Or did you mean some sort of ringing effect when going in and/or coming out of saturation, in which case what are the input, gains, and saturation levels that show that response?

[Sonoma Rich]

The ringing is due to the saturation limits as the output signal tries to keep up with the input signal and bounces around. See picture below.

[Paul]

I do think there will be some sensitivity of this approach to the gains, the thresholds, the input frequency, and the solver settings. If only interested in sine wave inputs, there might be a way to come up with a rule of thumb to set the gains based on the other parameters. For this particular example, I used:

w = 150*3; K1 = w^3; K2 = 3*w/K1; K3 = 3*w^2/K1;

and the result was

which doesn't look too bad. But the solution never did reach the acceleration saturation threshold. Increasing the gains yields

 w = 3*150*3; K1 = w^3; K2 = 3*w/K1; K3 = 3*w^2/K1;

[Paul]

With this approach, start-up transients could be minimized by setting inital conditions on the integrators based on the input signal.

Answer 2

[Captain Karnage]

I believe I have a much simpler solution if you'd like to see it.

First of all, for your velocity limit, use the built-in rate limiter block instead of derivative + saturation. That will take care of your velocity without the issue of initial conditions when you re-integrate it, and it's only one block.

Since you also want acceleration, you will need to do a derivate (to get velocity after the rate limit) + rate limiter (to limit the acceleration) then integral (to get position back).

Then what you can do for the integral step for your initial conditions is as follows: go to the "block parameters" and for "Initial condition source" select "external". This will add a port to your integrator to feed your initial conditions to so you don't lose them. See my example here:

Here is the integrator block setting:

Like Paul's answer, it's still a little off on the final position, but it's really close.

[Paul]

Hi Captain,

I tried this approach compared to mine with the following parameters:

Input: sine wave, amplitude = 8, freuqency 2*pi/0.4.

Gains: w = 3*150*3; K1 = w^3; K2 = 3*w/K1; K3 = 3*w^2/K1;

Limits: Acceleration: -+1.5e4, velocity: -+100.

Initally I was running with the default solver settings. The auto selected solver for my approach was ode45. When I added your approach into the model, the auto selected solver was ode23t and the simulation ran incredibly, unbearably slow. Our results were pretty close to each other, just comparing scopes by eye. Then I forced the solver to be ode45 and the simulation ran as fast as it should and the results for positiion and velocity were very close to each other, though my approach tended to come off the rate limit a bit later, presumably due to the lag in the filter.

I try to avoid using Derivative blocks whenever possible.

[Captain Karnage]

Thank you for the analysis, Paul, I appreciate the comparison that I didn't have time for myself. I should have mentioned my default is ode45. I do find the auto selected solver is often not the best and I often use ode45 as the baseline to compare. Of course, I occaisionally run into a model that doesn't run well on it and have to pick something else.

[Sonoma Rich]

Thank you for the suggestion. This works fine as long velocity limit (rate limit on position) is small and is reached before the acceleration limit (rate limt on velocity). If the velocity limit is large, the behaviour on the acceleration limit is not approprate, particularly when using square wave for the position signal. In the example below, the position signal was a square wave. The velocity limit was set to +/-100 and the acceleration limit was set to +/-20. The velocity limit was never reached, but the acceleration was short duration square waves.