Team,
Presently I am doing work on multicopter modeling and control. One topic of interest to me is how can the tilt dynamic model of a multicopter be accurately determined from flight data, without disabling the controls or injecting any sort of intrusive signals. It turns out it can be done from normal flight data using a few basic concepts from signal processing. The method is described here. The above plot is the measured pitch dynamic impulse response of my draganflier. The x axis is time. The y axis is the pitch rate impulse response to an impulse command sent to the ESC. There are two curves in the plot. h(t) is the response, computed from flight data. H(t) is an exponentially decaying sinusoid fitted to the measurement. In this case, the Laplace transform of the impulse response is 5/(s*s+4*s+29), which is of exactly the form you would expect to arise from an analysis of fixed pitch control. Basically, in the case of my draganflier, there is about a 0.25 second delay between the time a new tilt rate is commanded to the motors and when quad begins tilting. I have measured a similar delay for the ArduCopter. The cause of this delay is mainly the inertia of the propellers, which delays the response of propeller thrust to change in motor torque, and the inertia of the quad, which delays the tilt rate response of the quad to propeller thrust.
As a check on the accuracy of the method, it is possible to convolve H(t) with control inputs to predict tilt rate. The following is a comparison of measured and predicted pitch rate during a flight of my draganflier.
Don't get too excited about the way the model seems to predict the high frequency features. If you are curious about that, read my report.
From the form of the tilt dynamic model it is possible to determine the form of an optimal feedback controller. It is not a PID controller. But that will be the subject of another report.
Best regards,
Bill
Comments
Hi Brian,
The reason I zeroed out the first three time steps in the spreadsheet is that there is a processing latency of about three time steps in the MatrixPilotQuad software, which I estimate the total is as follows: the time the data is measured (1/2 time step), response is computed (one time step), pulse is generated for the ESC (one time step) and ESC response (1/2 time step). I was not sure what the algorithm really produced for negative time of the impulse response. Also, I was pretty sure that the actual, physical impulse response for small values of time should start from zero and rise positive.
Best regards,
Bill
Team,
By the way, I would expect that the details of the tilt impulse function of a quad will depend on flight conditions. In particular, I would expect that the following four situations would produce slightly different responses:
1. Hover in ground effect.
2. Hover at altitude.
3. Steady state forward flight.
4. Accelerated flight.
I would expect the impulse response functions for each of these situations would be approximately the same, with just some slight variations in the parameters of the model. But that is just my opinion at this point. Once the weather gets better here, I will go outside and gather more test data to make some quantitative conclusions.
All of the test data that I have used so far has been from flights in which I hovered the quad for 10 minutes, sometimes in ground effect, sometimes at altitude. I do not have any data yet for forward flight or for accelerated flight.
Best regards,
Bill
Hi Brian,
I am rather sure that the negative response is due to the motion of the air in response to the thrust of the propellers. In any case, I know that it is not due to the closed loop response.
Just to be clear what the method computes, and what the impulse response function that I computed is: it is the open loop response of the tilt rotation rate of my draganflier to a single, short, impulse provided to the motors, computed from the inputs to the motors and tilt rotation rate during a normal flight, with the control loops engaged.
The interesting thing about the technique that I am using is that it measures the response of the quad to inputs to the motors, regardless of the closed loop response of the system, and regardless of the particulars of the inputs to the motors, provided all inputs to the dynamic model are accounted for.
The only unaccounted input to the dynamic model that matters is the vibration of the motors and propellers. And that certainly gave me some trouble at first. Vibration did cause the computations to produce a distorted result. Though what it did was to create a negative response at the beginning, not at the end.
The problem with vibration is that it creates an output (rotation rate) that is not caused by an input (motor control signals), so it cannot be fit by a causal model.
But once you somehow deal with vibration, the method is "clean".
If you read through the equations in my paper, you will see that the method will work no matter what the nature of the input is, even if it is the result of feedback, provided that the matrix computed from the autocorrelation of the input is invertible. That matrix is invertible for all of the flights that I made. Its actually very well behaved.
The autocorrelation matrix contains the information about how the feedback loop "colors" the input to the motors. If it were not for the feedback, the autocorrelation of the input to the motors computed over a long flight would be an impulse function. However, because the feedback depends on the rotation of the quad, there is some interesting behavior that shows up in the autocorrelation matrix. Then, the inverse of the autocorrelation matrix compensates for the fact that the model that we are trying to estimate is inside of a closed loop. If you look through the spreadsheet for the computations on the data from my test flight, you will see that inverse of the autocorrelation matrix is not the identity matrix.
By the way, I have used this particular method before in several projects for my day job. It is well documented in the literature and in books on signal estimation theory and is known to work even if the system being estimated is inside of a control loop.
Best regards,
Bill
Hi Marko,
There are a couple of directions I am exploring after this. One of them is to design a controller that takes advantage of the form of the tilt dynamic model. The result is that the controller can compensate for the time lag of the dynamic model. I have already done that, I just have to write it up. The other direction is to work out a way to compute the dynamic model in real time during the flight.
Regarding the negative impulse response after about 0.65 seconds, I think that is due to air motion. There is an action-reaction effect. The change in thrust of the propellers accelerates the rotation of the aircraft in one direction, and the reaction force on the air accelerates the air in the opposite direction. So, after the response of the propellers decays, there is some residual air circulation in a direction opposite to the initial rotation of the aircraft, that takes a little while to dissipate.
Best regards,
Bill Premerlani
Hi Tom and Tridge,
Regarding the sources of noise on the gyro power bus, I found the biggest culprits are servos. It is best if you can power servos separately from the electronics, especially if they draw a lot of power. I found that with quads, since there are no servos, and there are no large power draws from the BEC, the noise on the gyro power bus is not too bad. Still, the best approach, in my opinion, is to provide regulated power to the gyros.
Best regards,
Bill
The different vector matrix methods are a neat discussion. What I have found important is that there needs to be little mechanical vibration to the IMU.
Hi William and hi all,
I think you can get even more accurate results using a similar strategy but working in the Frequency Domain. Here is what you can do (without so much effort):
1. Conduct experiments where you give inputs that correspond to a frequency sweep. You can add this to your input signal (add a chirp signal there) but even if you do not want to do this then at least you should be able to provide the needed frequencies through your reference commands. The controller is going to mix them through the feedback of the data but more or less they are going to be there. As long as the order of the model is higher than 1 and you are recording the control actions then it is possible to identify the model.
2. Try to conduct the experiments in a way that you start and end at trim.
3. Use frequency-domain based tools to check if your excitation was good enough.
4. Develop a Grey-box of your model. This means that you take the 6DOF model or decoupled verions of it (Roll - Pitch - Yaw and so on). So you have a specified structure but unknown parameters.
5. Use a regressor (MATLAB is good for that - it also has a special tool for system id) and solve the problem in the FREQUENCY DOMAIN. This means that you solve the regression between the frequency response of the experimental flight response and the estimated frequency response of the model to be identified. Frequency domain poses several advantages, and the first (and very related with the fact that you are working with feedback enabled) is the frequency seperation and the capability to focues on the frequencies produced from the vehicle and not from noise.
6. Validate the model in time-domain as well as frequency domain.
The aforementioned general steps are ok even for the open-loop unstable model, which is another key feature of the frequency domain.
Regarding the online implementation you have to look for an ARX model. Keep the model order low and you can generally ensure convergence of the parameters. The open-loop unstable dynamics (critically stable) are going to be quite tricky then. Are you also interested for adaptive control tuning?
Bill,
we also measure drift in degrees/s, what I am talking about is the slope of omegaI. The y axis of the graph I showed you is in degrees/s, but its average slope is around 0.02 degrees/s/s. My apologies for not labelling my axes! As I understand it, the ki value in DCM that controls the growth of omegaI is essentially a limit on that slope.
Regarding the effect of the mag on omegaIz, I agree completely, and it is a problem I'm trying to deal with right now in the context of the Madgwick quaternion system (I have a compile time option to switch between DCM and the Madgwick MARG system).
Quite possibly. I rewrote our gyro calibration code yesterday because I suspected that it was producing a poor value. I'm going to watch the logs from users to see if the initial slope of omegaI decreases as a result. I think it will.
In APM2 we use a Invensense MPU6k. In APM1 we use a IDG500 for x/y and a ISZ500 for z.
I don't think it is temperature effects however. In our simulator I've been able to produce very similar 'drift' just by injecting white noise. I suspect the PI values we're using to control omegaI are not good and our 1kHz sample rate is not high enough to control it, combined with a base drift from poor calibration.
We've only just started recording the chip voltage during flight, so we don't have much data yet. I'm hoping that future user logs will allow us to see if the logged chip voltage is in any way correlated with the accumulation of error in the DCM (we're now logging the magnitude of the errors terms in DCM, as well as the omegaI integrator components).
Cheers, Tridge
Hi Kari,
Yes, I am using a 200 tap mean filter. Just to be clear, that is the theoretically correct thing to do for the critical downstream computations that are basically integrators. I am not trying to attenuate anything in the signal, I am treating everything as signal, and then integrate it. That has provided incredible performance.
And yes, the data in the spreadsheet is at 40 Hz.
Best regards,
Bill
Andrew,
One more observation. Part of the problem could be the reference vectors themselves. Non-zero values of omegaI simply mean that the gyros and the reference vectors disagree.
For example, I find that uncompensated yaw drift is essentially zero. But if I hook up a magnetometer, I will see a non-zero value of omegaIz, because of magnetometer errors.
So, the problem that we face is that the gyros and reference vectors have different sorts of errors, and once you rely on a reference vector for drift compensation, you are stuck with the errors it introduces.
In your case, I suspect that accelerometer errors are contributing to what you see in roll and pitch, and magnetometer errors are contributing to yaw.
When I have some time, I could look into this on my end with UDB and MatrixPilot, so that we could compare notes. Right at the moment, though, I am tied up with a bunch of other things, including some things that I am working on for GE. (They have rehired me back out of retirement.)
Best regards,
Bill
-
1
-
2
of 2 Next