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 Bill,
Thanks for the comments! Getting yaw hold with no compass to within two degrees over 600 seconds is incredible. That implies an extremely low gyro drift rate. For the code I'm working on how I've assumed a maximum drift rate of 0.02 degrees/s/s.
Have you plotted your omegaI components over time to get an estimate of what drift rates you really see?
Here is a plot of omegaI over a 6 minute flight with a small quadcopter and APM:
On APM we're currently sampling the gyros and accels at 1kHz, and doing a simple average to feed DCM. We run the DCM matrix update on ArduPlane at 50Hz and on ArduCopter at around 200Hz.
Nice work. Did you consider using the system identification tool from matlab (if you have it)?
If you have some raw input - output data i could give it a go myself and see what kind of transfer function i can compute. It doesn't need to be an impulse response, just the recording of general flight should suffice as it usually contains a large enough spectrum, especially at the frequencies you're most interested in.
Aliasing is hard (almost impossible) to deal with (except by raising the sampling rate).
Do you have any details on the decimation filters you are using?
I guess you are measuring the closed loop response, i.e. with the PID controller active?
Hi Bill,
Very interesting work, as always. I think the whole quad community is going to benefit from your research.
Regarding the high sample rates in the MatrixPilot firmware. If I remember correctly sample/hold amplifiers were the limiting factor in the UDB3 boards. Does this mean that using a different A/D converter with even higher sampling rates might return even better results?
Also, I have been wondering about your views on using digital sensors. In particular I wonder how the digital low pass filters they implement would influence the DCM calculations...?
Kind regards,
Wouter
Andrew,
A couple more comments about rotational vibration. What I decided to do is to treat rotational vibration as a real signal. So, as a long as I sample and integrate it at a high enough frequency, the result reflects the actual orientation.
The reason I decided to try sampling and integrating at a high rate was the realization that much of the "drift" of the gyros was not really drift, but an accumulation of error from the white noise included in the gyros. A higher sampling rate attenuates the effects of white noise. It also turned out to be a solution to the problem of vibration effects.
Best regards,
Bill
@Brian
Yes, I think that the airflow itself is part of the dynamics. Definitely
@Andrew,
I have looked at "noise" propagation in DCM, and realized that one approach to dealing with the effects of translational and rotational vibration is to treat it as signal, not as noise. As a result, in MatrixPilot we have gone to 8000 samples per second, and we use an "integrate and dump" filter to decimate the sampling rate down to our frame rate. The integration at a high sampling rate prevents the vibration signals from building up errors. For example, MatrixPilotQuad is able to hold yaw to within a couple of degrees for the duration of a 10 minute flight of my draganflier, without needing a magnetometer, all the while my draganflier is vibrating like a paint shaker. In other words, I can hover in place for 10 minutes without touching the yaw control at all, and with only minor inputs to roll and pitch.
In other words, sampling and integrating at 8000 samples/second achieves zero error build up in attitude estimation.
Best regards,
Bill Premerlani
Great stuff Bill! I'm really looking forward to what you suggest for the feedback controller.
I also found your comments on the noise interesting. I've been spending a lot of time recently looking at how well DCM as implemented in ArduPlane/ArduCopter deals with noise, which has resulted in some significant changes that we are looking at pushing out soon. I've been modelling it with our SITL simulation of planes and copters running at 1kHz, adding either white noise or noise based on motor speed. I've come to the conclusion that a lot of the control issues we've been seeing in APM are due to buildup of errors in the omegaI matrix in DCM as a result of noise in the accel and gyro data.
Have you looked at how noise propogates in DCM? The sort of noise we want to cope with is fairly large - around 0.5g of noise in accels and around 0.5 radians/s noise on the gyros.
Cheers, Tridge
Interesting work. Keep it up!! :) Reading your report now.
Bill,
Interesting results. Do you think the inertial response of the airflow as the prop RPM is changed affects the delay? On larger rotorcraft, the time required for rotor inflow to respond to a change in rotor speed or blade angle can be approximated as a first order lag with a time constant ~0.1 sec.
-
1
-
2
-
3
of 3 Next