I have face a problem for last few months where solution to it seems like a dream to me! :D
Work i followed...
Initially i high pass a certain signal to remove dc shift of it using filtfilt function of matlab. The results were as intended.
But when i implement the same high pass filter in real time with matlab fdatool (butterworth filter with order2) filter response changes dramatically.
Seems like filtfilt function implementation is perfect possibly due to zero phase.
It's also important to notice phase plays a important in my filtering process?
Can anyone help me to design a real time filter which gives matlab filtfilt performance?
Related
I would like to make a discrete filter, where the sampling rate can be controlled by an input. I am trying to understand how the discrete filter block looks, "under its own mask." Is there anyway to retrieve the code behind this block so it can be modified for my use?
You can use an user-defined function as a filter, pick the filter transfer function, translate it into a difference equation (the discrete-time equivalant to the diferrential equation), implement that difference equation in a function and feed the sampling rate as an input (the sampling rate will appear as a constant in your difference equation).
The block is too complex and has too many options to simply be able to look under the mask. Your best option is to have a look at the documentation, which does show some detailed implementation of the block in some articular cases to get an idea and then try to recreate the discrete filter you want from basic building blocks, using a constant sample time at first, until you can validate your own implementation against the Simulink library block. Only then, start considering how you will change the sample time. Your main problem though is that the filter coefficients will change with the sample time, so you need to be able to re-calculate them on the fly. It's not an easy problem, I don't even know if it's possible.
This is a question that possibly borders on the intersection of the general usage of MATLAB and/or signal processing. Thought I would first ask the question in a MATLAB forum before trying signal processing.
So our lecturer read out his notes/paper and said the equation
could be implemented as a filter.
At first, it seemed difficult to follow the idea but when realizing that integration is same as finding areas under the curve which seems similar to applying a low pass filter so that only the portion of the signal under the threshold is allowed to pass through, it made a bit of sense. But how - meaning to say which function - can I use to implement the above equation? Do I need three filters or can I use just one? How do I use the terms preceding the integrals in the filter?
Thanks in advance
How to use rate limiter with square signal and variable step size in Simulink?
Here's a screenshot of the model I'd like to set up:
model:
I feed a customized rectangular signal to a rate limiter to avoid vertical slopes.
Unfortunately that doesn't seem to work. I'm using ode15s, it's a requirement. Here's the error message Simulink throws:
Error: Input signals to Rate Limiter '.../Rate Limiter' are neither
discrete nor continuous sample time signals. Only discrete or
continuous input signals are supported
Quite surprisingly I found a workaroud by adding an integrator directly followed by a derivative. This works:
workaroud:
But it's ugly and I'm getting some very annoying stability issues in some cases. And I doubt very much that it is considered "good practice".
So how is one supposed to use this rate limiter block in such a situation?
John
Thank you both for your answers.
I forgot to say I had already checked the sample time with the colour display. It was "Fixed-in-Minor-Step".
Actually it was quite simple. If I get it right, the sample time was not specified or specified in a wrong way in my subsystem. Specifying Continuous in the rate limiter dialog box solved the problem!
thewaywewalk, I'll keep your suggestion in mind. Since I'm using steps a lot it might be useful.
Try displaying the sample time colours in your model to check what sample times your signals are using.
Introducing an integrator block will force the signal to become continuous, hence why it works. Maybe using a Signal Specification block or a Rate Transition block with a sample time of [0, 0] (for continuous signal, see Specify Sample Time in the documentation) will achieve the same thing and be slightly more elegant (using the derivative block is not considered good practice).
When running the GlobalSearch solver on a nonlinear constrained optimization problem I have, I often get very different solutions each run. For the cases that I have an analytical solution, the numerical results are less dispersed than the non-analytical cases but are still different each run. It would be nice to get the same results at least for these analytical cases so that I know the optimization routine is working properly. Is there a good explanation of this in the Global Optimization Toolbox User Guide that I missed?
Also, why does GlobalSearch use a different number of local solver runs each run?
Thanks!
A full description of how the GlobalSearch algorithm works can be found Here.
In summary the GlobalSearch method iteratively performs convex optimization. Basically it starts out by using fmincon to search for a local minimum near the initial conditions you have provided. Then a bunch of "trial points", based on how good the initial result was, are generated using the "scatter search algorithm." Then there is some more convex optimization and rating of "how good" the minima around these points are.
There are a couple of things that can cause the algorithm give you different answers:
1. Changing the initial conditions you give it
2. The scatter search algorithm itself
The fact that you are getting different answers each time likely means that your function is highly non-convex. The best thing that I know of that you can do in this scenario is just to try the optimization algorithm at several different initial conditions and see what result you get back the most frequently.
It also looks like there is something called the 'PlotFcns' property which would allow you get a better idea what the functions the solver is generating for you look like.
You can use the ga or gamulti objective functions within the GlobalSearch api. I would recommend this. Convex optimizers wont be able to solve a non-linear problem. Even then Genetic Algorithms dont gaurantee the solution. If you run the ga and then use its final minimum as the start of your fmincon search then it should result in the same answer consistently. There may be better ones but if the search space is unknown you may never know.
First for those, who are not familiar with Simulink, there is a imaginable outside-Simulink partial solution:
I need to create a vector satisfying the following conditions:
known initial value a1
known final value a2
it has a pre-defined step size, but the length is not pre-determined
the first derivative over the whole range is limited to v_max resp. -v_max
the second derivative over the whole range is limited to a_max resp. -a_max
the third derivative over the whole range is limited to j_max resp. -j_max
at the first and the final point all derivatives are zero.
Before you ask "what have you tried so far", I just had the idea to solve it outside Simulink and I tried the whole stuff below ;)
But maybe you guys have a good idea, while I keep working on my own solution.
I'd like to generate smooth ramp signals (3rd derivative limited) based on a trigger signal in Simulink.
To get a triggered step I created a triggered subsystem propagating the trigger output. It looks like that:
But I actually don't want a step, I need a very smooth ramp with limited derivatives up to the 3rd order. The math behind is:
displacement: x
speed: v = x'
acceleration: a = v' = x''
jerk: j = a' = v'' = x'''
(If this looks familiar to you, I once had a very similar question. I thought about a bounty on it, but after the necessary edit of the question both answers would have been invalid)
As there are just rate limiters of 1st order, I used two derivates and a double integration to resolve my problem. But there is a mayor drawback, I can not ignore anymore. For the sake of illustration I chose a relatively big step size of 0.1.
The complete minimal example (Fixed Step, stepsize: 0.1, ode4): Download here
It can be seen, that the signal not even reaches the intended step height of 10 and furthermore is not constant at the end.
Over the development process of my whole model, this approach was satisfactory enough for small step sizes. But I reached the point where I really need the smooth ramp as intended. That means I need a finally constant signal at exactly the value, specified by the step height gain.
I already spent days to resolve the problem, and hope to fine some help here now.
Some of my ideas:
dynamically increase the step height over the actual desired value and saturate the final output. If the rate limits,step height and the simulation step size wouldn't be flexible one could probably find a satisfying solution. But as everything has to be flexible, there are too much cases where the acceleration and jerk limit is violated.
I tried to use the Matlab function block and write my own 3rd order rate limiter. Though it seems possible for me for the trigger moment, I have no solution how to smooth the "deceleration" at the end of the ramp. Also I'd need C-compilers, which would make it hard to use my model on other systems without problems. (At least I think so.)
The solver can not be changed siginificantly (either ode3 or ode4) and a fixed step size is mandatory (0.00001 to 0.01).
Currently used, not really useful approach:
For a dynamic amplification of 1.07 I get the following output (all values normalised on their limits):
Though the displacement looks nice, the violation of the acceleration limit is very harmful.
For a dynamic amplification of 1.05 I get the following output (all values normalised on their limits):
The acceleration stays in its boundaries, but the displacement does not reach the intended value. (not really clear in the picture) The jerk is still to big. (I could live with that, but it's not nice)
So it appears to me that a inside-Simulink solutions is far from reality. Any ideas how to create a well-behaving custom function block?
Simulation step size, step height, and the rate limits are known before the simulation starts. (But I have a lot of these triggered smooth ramps in a row, it should feed a event-discrete control). So I could imagine to create the whole smooth ramp outside simulink and save it as a timeseries object and append it on the current signal when the trigger is activated.
The problems you see are because the difference is not conditioned very well.
Taking the difference amplifies the numerical that exists in your simulation.
Also the jerk will always be large if you try to apply an actual step.
I guess for your approach it would be better to work the other way around:
i.e. make a jerk, acceleration and velocity with which your step is achieved.
I think your looking for something like the ref3 block:
http://www.dct.tue.nl/home_of_ref3.htm
Note the disclaimer on the site and that it is a little cumbersome to use.
An easy (yet to be improved) way is to use a rate limiter and then a state space model with a filter. From the filter you get the velocity, which in turn you can apply a rate limiter to. You continue with rate-limiter and filters until you have the desired curve.
Otherwise you can come up with numerical rate-limiters of higher order using ie runge kutta formulas or finite differences. However it was pointed out, that they may suffer from bad conditioning.
What I usually do is to use one rate limiter and a filter of 3rd Order and just tune the time constant (1 tripple pole), such that my needs are met. This works well, esp
Integrator chains of length > 1 are unstable!
There is a huge field of research dealing with trajectory planning. The easiest way might be to use FIR filters (Biagotti et al) or to implement an online trajectory planner (Ezair et al 2014 / Knierim et al 2012).