(copied from my blog at hobbyuav.com)
Hey everyone!
I have not found a place where the fixed-wing control for the PX4 is being done so I started this blog.
Above is a Screen shot from XFLR5. I use it to mathematically model the physical form of an airplane. I can then take this description of said plane and then start modeling the flow of air over the surfaces described is the model. You can then send modeled air at it in different angles and at different viscosity. In other words different pitches and yaws as well as different air densities or altitudes.
I use it all the time to make U.A.Vs. I think it should be integrated into the PX4 so that we can start introducing into the mathematical models of the control algorithms, a model of the crafts interaction with its environment (air). Thus achieving a much more complete mathematical description of the system.
This can be implemented by modeling the aicraft in XFLR5 then taking the results and generating LUTs of the predicted air/air-frame interactions. just one example of this would be to use the generated full airplane polar graphs to predict what AOA at a given speed and air density, should produce level flight or even produce a desired vertical acceleration (climb or dive). This would greatly reduce the dependence on the PID loop to achieve a given altitude, making the system much more stable at a greater range of the aircrafts flight envelope.
This can also be applied to different control loops as well. yaw and roll control. It can also be applied to every control surface as well. XFLR5 can generate tables of inertial moment data as well giving you a Cm polar. this can be calculated for various control surface angles. You can then take the aerodynamic Cm data and combine it with a physical inertial model to do a full stability analysis. The output of the Cm and the inertial model data can then be feed in to the control loops to achieve desired rotational accelerations instead of purely relying on the PID loop. Giving the control loops a much wider dynamic range that is possible with just a PID loop.
Comments
@Wayne
Any progress on the project? Sounds very interesting...
@J
yes I fully plan on implementing this myself into the PX4. I know this will work. Aerodynamic and Inertial modeling can be found already working on the high end closed source autopilots the military and government uses. I think it is the missing piece in every open source AP I have seen to date. 4 to 6 weeks is when I will be able to start committing. I look forward to experimenting with these ideas and proving them in the field.
Thanks for your time everyone!
The current estimation loop runs with 500 Hz and is a constant gain Kalman filter. A full-fledged 12 state EKF for attitude is also in the codebase and currently validated - it will also be able to run at 500 Hz thanks to the hardware floating point unit. In addition to that we also have a Kalman filter for position estimation for multirotors in place, which we are currently testing. It uses the control inputs in addition to the position to improve the accuracy.
Note that the prevalent estimation technique so far are complimentary filters, not Kalman filters. Even fixed-point Kalman filters need more processing power than popular 8-bit autopilots have typically available. If you read up performance comparisons, you will however notice that various scientific publications have proven that the complimentary filter design, if tuned well, can perform very well and a full-fledged EKF might not be the best tradeoff of runtime speed and accuracy. Our main intent with following an EKF attitude estimation design is that it should be more robust to changes in the sensor noise distribution, e.g. due to frame vibrations.
http://diydrones.ning.com/profiles/blogs/introducing-the-px4-autopi...
The maximum rate of the ACC is 1000 Hz, the maximum rate of the gyros is 760 Hz. Note however that these are the update rates, the sensors sample internally much faster. Also note that MEMS sensors without an analog lowpass (on the sensor) enabled perform poorly, so you will want to use 760 Hz with a 150 - 50 Hz lowpass - that gives you still very fast updates (150-50 Hz is just the cutoff frequency for the damping, its not the maximum frequency you can measure).
The position estimator needs a bit of processing time, the other two processes almost none. By not starting the three you can maybe safe 5-10% CPU load
To change the frequency you would have to change apps/sensors/sensors.c
The EKF filter is a proof-of-concept and not validated. Don't assume at this stage that it will produce valid results. It is there mostly to estimate the processing time (0.5 ms per iteration), it still needs polishing. If you know how to edit Matlab files and improve the existing code, feel free, else I advise to wait for another 4-6 weeks until we had time to finish the work on it.
Maximum microSD speed was about 500 Hz for raw sensor data. It might be a bit faster now, since we've improved the memcpy performance dramatically.
The EKF on the PX4 only costs 20% of the processor & provides a point of reference for the frequency
git clone https://github.com/PX4/Firmware.git
see apps/examples/kalman_demo
Another option is particle filters. There are some good libraries available
dysil libs
http://www.indii.org/research/dysii
mrpt libs
http://www.mrpt.org/Particle_Filters
http://www.mrpt.org/Kalman_Filters
Very interesting proposal, but it's easy to go overboard and take the numbers of this analysis as realistic. The actual system is much more chaotic.
Another thing we should not forget is that surface deflections take a bit of time, they're not instant and there may be some slop in the control linkage, which defines the eventual limit of how accurate and precise a system can be controlled, no matter what you measure or calculate before. The aircraft must also be built and tuned precisely to spec with equipment that can measure tenths of degrees?
It would be an interesting experiment to extend PID controllers to govern attitude through a plane's pitch/roll/yaw moments. XFLR5 could provide either an approximation or scheduling (by airspeed) of the required deflection of control surfaces to achieve these moments and the effect should be measurable by the gyro's to provide a feedback signal. Sounds like such a controller would also have a better capacity to limit exerted forces on airframes/wings, with some help of the nav module.
I can see how the "trim" settings based on airspeed help remove the need for large integrators.
@jay
my point is this will make any controller algorithm better. this would be the data going into the control loop not a part of it. The better data any controller has coming the better the data coming out. garbage in, garbage out.
edit:
"flight at all the different speeds right into. wind vanes..."
should say "flight at all the different speeds right into the AP program. wind vanes..."
@andrew
ya I think you are getting it. for thouse still a little confused. let me illustrate further....
first off. lets forget about auto pilots and loops and gains etc. lets talk about how to fly a plane at different speeds and maintain level flight. (constant altitude)
we have all experienced that a positively stable airframe will pitch up and climb if you hit the throttle. and in order to fly super slow you must pitch the nose up.
so according to XFLR5 the techpod while weighing a whopping 6.5 lbs the techpods AOA looks like this to maintain the 6.5 lbs of lift need to for level flight (constant altitude)
@93.7 MPH the techpod will need to maintain a -2.0 deg AOA
@48.2 MPH the techpod will need to maintain a 0 deg AOA (cruse speed)
@36.6 MPH the techpod will need to maintain a +2.0 deg AOA
@28.7 MPH the techpod will need to maintain a +5.0 deg AOA
this is how an airplane naturally is flown. as a pilot this happens quite automatically with out much need for thought other then you will end up adding down trim at high speeds for perfect level flight and you will have to add up trim for level flight at low speeds. the idea is to program in this pitch/speed relationship need for level flight at all the different speeds right into. wind vanes or sensor do detect AOA are not need because we are assuming and trying to maintain level flight so at 0.0 degrees of pitch relative to earth, your AOA will be 0.0 degrees and unless you are doing exactly 48.2 MPH. if you are doing more the airplane will be climbing any less you will be losing altitude.
drag really does not need to be calculated. although it may be useful for motor control. absolute drag however is vastly more complicated to calculate. XFLR5 can however produce good relative drag numbers. what i mean is they are good when compared to other drag numbers produced by XFLR5 in other word less drag is less drag. exact drag real wold numbers are much more complex to predict.
I have to agree with Philippe.
If you take the time to make a sophisticated mathematical model, a you should consider a better regulator than an PID-Regulator.
Especially when a Kalman filter is on the Roadmap the LQR is a good way to go (the LQR is similar to the Kalman filter).
Any effects modelled in the mathematical model will be considered by the LQR-Regulator (For example different movements of the control surfaces at different speed).
The LQR-Regulator is an optimal regulator. This means it is mathematical proven that there is no better regulator (for given weighting factors and the mathematical model).
As far as gain scheduling goes, I think it is nothing like it. The MBC should deliver an open-loop or feed-forward term for the control surfaces which is subsequently trimmed by a limited authority PID feedback loop. The key difference between this method and gain scheduling is that the error term does not need to even exist for action to be taken. The response time of the system to large changes in circumstances can be much faster
-
1
-
2
-
3
of 3 Next