I am new to Simulink and am trying to make a simulation of an active vehicle suspension with Simscape. For some reason, I am getting unreasonable results in my sim, despite following the examples on the mathworks website pretty closely. I have temporarily disabled the acceleration command for testing.
The input from the signal builder is a sinusoidal function. I don't understand why the values of the suspension motion for the top mass are higher than the input.
Not sure if this is the only issue, but I'd strongly recommend not using that Derivative block. The derivative you get there is a numerical approximation that is highly depending on the time step the solver takes. It can cause instability.
If you want the acceleration as a direct measurement, I would instead recommend grabbing an Ideal Force Sensor block, connecting it in series with the Mass block, and then dividing by the mass to get acceleration.
Related
I am working on modeling and controlling of a hydraulic system. Modeling of the system is modeled in Matlab simscape in simulink environment which is looks like this
and for basic controlling to control the piston position (Piston Pos in figure) I have established simple feedback to check the position.
While I run the simulation when this comes to control the position Simulation takes too much time. For example if I gave desired piston position 300 mm than while output comes to around 290-294 mm simulation time reaches at around 5.18sec than it is stuck on that for longer time.
I want to know that, is there any way to speed up the simulation ?
I am using Matlab simulink solver ode23t due to simscape modeling.
Speeding up simulations in general is vast subject. It seems the issue here is an event which triggers multiple small time-step in the variable step solver.
This can be perfectly normal, for example a clutch engaging, or a valve opening.
To check whether or nor this is the case you can execute (make sure time-logging is enabled):
semilogy(tout(2:end), diff(tout))
Sharp downward spikes indicate small time-steps were taken. For a more in-depth analysis you can use the Solver Profiler:
https://www.mathworks.com/help/simulink/ug/examine-solver-behavior-using-solver-profiler.html
This will give you detailed information as to which components are causing solver resets.
Such behavior can be difficult to debug if you're not used to the tool. I'd highly recommend getting in touch with MathWorks tech support if the behavior persists. They'll be able to look at your model and diagnose the issue.
I have been trying to implement a navigation system for a robot that uses an Inertial Measurement Unit (IMU) and camera observations of known landmarks in order to localise itself in its environment. I have chosen the indirect-feedback Kalman Filter (a.k.a. Error-State Kalman Filter, ESKF) to do this. I have also had some success with an Extended KF.
I have read many texts and the two I am using to implement the ESKF are "Quaternion kinematics for the error-state KF" and "A Kalman Filter-based Algorithm for IMU-Camera Calibration" (pay-walled paper, google-able).
I am using the first text because it better describes the structure of the ESKF, and the second because it includes details about the vision measurement model. In my question I will be using the terminology from the first text: 'nominal state', 'error state' and 'true state'; which refer to the IMU integrator, Kalman Filter, and the composition of the two (nominal minus errors).
The diagram below shows the structure of my ESKF implemented in Matlab/Simulink; in case you are not familiar with Simulink I will briefly explain the diagram. The green section is the Nominal State integrator, the blue section is the ESKF, and the red section is the sum of the nominal and error states. The 'RT' blocks are 'Rate Transitions' which can be ignored.
My first question: Is this structure correct?
My second question: How are the error-state equations for the measurement models derived?
In my case I have tried using the measurement model of the second text, but it did not work.
Kind Regards,
Your block diagram combines two indirect methods for bringing IMU data into a KF:
You have an external IMU integrator (in green, labelled "INS", sometimes called the mechanization, and described by you as the "nominal state", but I've also seen it called the "reference state"). This method freely integrates the IMU externally to the KF and is usually chosen so you can do this integration at a different (much higher) rate than the KF predict/update step (the indirect form). Historically I think this was popular because the KF is generally the computationally expensive part.
You have also fed your IMU into the KF block as u, which I am assuming is the "command" input to the KF. This is an alternative to the external integrator. In a direct KF you would treat your IMU data as measurements. In order to do that, the IMU would have to model (position, velocity, and) acceleration and (orientation and) angular velocity: Otherwise there is no possible H such that Hx can produce estimated IMU output terms). If you instead feed your IMU measurements in as a command, your predict step can simply act as an integrator, so you only have to model as far as velocity and orientation.
You should pick only one of those options. I think the second one is easier to understand, but it is closer to a direct Kalman filter, and requires you to predict/update for every IMU sample, rather than at the (I assume) slower camera framerate.
Regarding measurement equations for version (1), in any KF you can only predict things you can know from your state. The KF state in this case is a vector of error terms, and thus you can only predict things like "position error". As a result you need to pre-condition your measurements in z to be position errors. So make your measurement the difference between your "estimated true state" and your position from "noisy camera observations". This exact idea may be represented by the xHat input to the indirect KF. I don't know anything about the MATLAB/Simulink stuff going on there.
Regarding real-world considerations for the summing block (in red) I refer you to another answer about indirect Kalman filters.
Q1) Your SIMULINK model looks to be appropriate. Let me shed some light on quaternion mechanization based KF's which I've worked on for navigation applications.
Since Kalman Filter is an elegant mathematical technique which borrows from the science of stochastics and measurement, it can help you reduce the noise from the system without the need for elaborately modeling the noise.
All KF systems start with some preliminary understanding of the model that you want to make free of noise. The measurements are fed back to evolve the states better (the measurement equation Y = CX). In your case, the states that you are talking about are errors in quartenions which would be the 4 values, dq1, dq2, dq3, dq4.
KF working well in your application would accurately determine the attitude/orientation of the device by controlling the error around the quaternion. The quaternions are spatial orientation of any body, understood using a scalar and a vector, more specifically an angle and an axis.
The error equations that you are talking about are covariances which contribute to Kalman Gain. The covariances denote spread around the mean and they are useful in understanding how the central/ average behavior of the system is changing with time. Low covariances denote less deviation from the mean behavior for any system. As KF cycles run the covariances keep getting smaller.
The Kalman Gain is finally used to compensate for the error between the estimates of the measurements and the actual measurements that are coming in from the camera.
Again, this elegant technique first ensures that the error in the quaternion values converge around zero.
Q2) EKF is a great technique to use as long as you have a non-linear measurement construction technique. Be very careful in using EKF if their are too many transformations in your system, i.e don't try to reconstruct measurements using transformation on your states, this seriously affects the model sanctity and since noise covariances would not undergo similar transformations, there would be a chance of hitting singularity as soon as matrices are non-invertible.
You could look at constant gain KF schemes, which would save you from covariance propagation and save substantial computation effort and time. These techniques are quite new and look very promising. They actively absorb P(error covariance), Q(model noise covariance) and R(measurement noise covariance) and work well with EKF schemes.
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).
I'm simulating a shaft system in Simulink, where I have to find the displacement of a mass. I'm not sure how to model this in Simulink because of the shaft and pulley. I'm looking through the documentation and the closest thing I see to a shaft is the wheel and axle block. But the shafts are connected by a flexible shaft, which is similar to a spring. Any ideas?
This is a fairly trivial task when using SimScape, which is especially made to simulate physical systems. You'll find most of the blocks you need ready from the library.
I've used SimScape to create a model of a complete hybrid truck... In Simulink it can be done, but you'll need to build your own differential equations for the task. In your case, the flexible axle could be translated to another block with a spring/damper system inside.
If you haven't got access to SimScape, you may also consider to use .m (matlab) files to write your differential equations. This can then be used as a block in Simulink, varying (only) a few parameters over time.
Take this step by step:
1. Draw a free body diagram, write out equations for all the forces as a function of displacement, velocity and acceleration of every element (including rotation obviously). For instance, you know that force on the box m will be *c*dy/dt* plus whatever the pulley experiences.
2. Sort out the rotation of the rod first. You know that *T=I*d(omega)/dt* if you get rid of the rest of the system. So, do something analogous to the car engine example of MatLab: Divide the input T by I to get the acceleration, integrate it to get velocity and one more time to get rotational displacement.
3. Keep adding bits one by one. First, you know that there will be a moment proportional to k*(theta_1-theta_2) acting. This will oppose the motion of rod 1 and act to create motion of rod 2. Add a new "branch" to your model to get theta_2 same way you got theta_1.
4. Go on including further elements...
I have a Simulink xPC target application that has blocks with discrete states at several different sample rates and some sections using continuous states. My intention on keeping the continuous states is for better numerical integration.
What creates the problem: One block is reading a device at a very fast rate (500 hz). The rest of the application can and should run at a slower rate (say, 25 or 50 Hz) because it would be overkill to run it at the highest rate, and because the processor simply cannot squeeze a full application cycle into the .002 secs of the faster rate. So I need both rates. However, the continuous states run by definition in Simulink at the faster discrete rate of the whole application! This means everywhere I have continuous states now they're forced to run at 500 Hz when 25 Hz would do!
Is there a way to force the continuous states in xPC target to a rate that is not the fastest in the application? Or alternatively, is there a way to allow certain block to run at a faster speed than the rest of the application?
You are thinking about continuous solvers in the wrong way - continuous doesn't only mean that it's run as fast as possible - it uses a fundamentally different algorithm to solve the equations than discrete. Due to this, they must be run at least as fast as the discrete solvers.
From Using Simulink:
Continuous solvers use numerical
integration to compute a model's
continuous states at the current time
step from the states at previous time
steps and the state derivatives.
Continuous solvers rely on the model's
blocks to compute the values of the
model's discrete states at each time
step.
Mathematicians have developed a wide
variety of numerical integration
techniques for solving the ordinary
differential equations (ODEs) that
represent the continuous states of
dynamic systems. Simulink provides an
extensive set of fixed-step and
variable-step continuous solvers, each
implementing a specific ODE solution
method (see Solvers).
Discrete solvers exist primarily to
solve purely discrete models. They
compute the next simulation time step
for a model and nothing else. They do
not compute continuous states and they
rely on the model's blocks to update
the model's discrete states.
So the upshot is that no it's not good enough to have the continuous run more slowly than the fastest discrete solvers - otherwise they are, by definition, not continuous. You should reconsider why you are specifying them as continuous.
What are you trying to accomplish by slowing down the continuous solvers? Is this a simulation time/performance issue?
-Adam
My take on this is that it cannot be done. One way to approach this is to replace the continuous states by discrete ones (perhaps at an intermediate rate, say 100 Hz), and cross my fingers that the loss of precision is bearable.
Maybe it's possible to isolate a block and run it separately at a faster rate somehow, but I don't know.
Truly continuous computation is impossible in a digital processor such as your computer's.
What MATLAB/Simulink means by "continuous" is "I will (dynamically) try to guess what discrete step size is small enough so that discretization error is very small in your application".
If you already know, by knowing your application, that 20ms (50Hz) would be small enough, then use discrete - 50Hz.