On Sunday 11 Oct 2009, Alan Teeder wrote: > > -----Original Message----- > > From: leee [mailto:l...@spatial.plus.com] > > > > > ie if u stick in a new value to the FDM then it will react.. > > > That sucks in my oioiion.. I how have to create my own craqo > > > to make the model. that sucks to me.. > > > > > > pete > > > > You really need to chill a bit. Just moaning about things > > isn't the best way to go about getting stuff fixed. > > > > Anyway, in short, this 'problem' such as it is, is largely due > > to the rates at which the autopilots are run within FG. In > > real life, autopilot controllers, and the sensors that feed > > them the data they need to work with, run at much higher > > frequencies than are possible within the FG framework. > > Ideally, you want to be able to run the autopilots at several > > to many kHz but in FG, although you can specify very high rates > > in the autopilot config, you are effectively limited by the > > frame rate, so not only do they run much more slowly than is > > desirable but they also run at varying rates as the frame rate > > changes. > > Lee > > First, thanks for the quick into to Flightgear´s autopilot. > > I think that your premise that autopilots need to run at very > high frame rates is not realistic.
I guess it depends upon what you're trying to do. If you just need an autopilot for a light aircraft or an airliner, where you want fairly slow and gentle responses, you can get away with relatively low rates. Apart from frame-rate induced instabilities, I found the rates that I could get, on my relatively old kit, acceptable for the larger aircraft I did. For the faster and more maneuverable military jets though, I found that I really needed guaranteed higher rates to both ensure a crisp response and avoid instabilities. For example, I could tune an altitude-hold cascade that would work fine at speeds up to 400kt say, but which would become unstable above that. The reason was that the rate of deviation increases with aircraft speed as the control surfaces generate more force for a given deflection, so for a given deflection of the control surfaces by the controller, it sees a greater response result in its next sample. Eventually, it can't help but over-correct and go into oscillation. Running the controller at a higher rate though, would mean that it would see a smaller deviation because the aircraft would have moved less in the shorter time period. Now admittedly, I the autopilots I were working on were more like FBW/FMS systems. For example, I was using a three-stage cascade for elevator control and the final elevator driver stage had to be able to maintain pitch between take-off and landing speeds, up to top speed, a typically range of 130-1200 kts. To maintain control at take-of and landing speeds, the elevators need a lot of authority, and to be quite honest, pretty brutal, but you can't apply that brutefulness at top speed. One way to ameliorate this was to use reciprocal filters to reduce the controller gains as the speed increases, but once again, a higher guaranteed sample rate would be better. > > When I first got into autopilots and simulation, back in the > 60´s, all of our models had as the final element a 0.1 second low > pass filter which simulated the control surface actuator. This > turns out to be a reasonable approximation for most actuators and > is very simple to implement both in a analogue computer (which is > all we had then) and in digital ones. You can think of the different autopilot controllers and filters as analogue logic building blocks. You're pretty much building an analogue computer when you set up a complex autopilot. > > As there is such a filter in the inner loop means that there is > no need to simulate anything which has a faster response time > than this. Therefore there is no need to run the autopilot at > high frame rates. 10 or 20 per second is perfectly adequate. As I've mentioned, you can simulate the control surface actuators in the aircraft FDM config, both in JSBSim and YASim. > > Many of the outer loops (e.g. the heading mode) of the autopilot > can in practice be run at much slower frame rates as the response > of the aircraft is quite slow. > > Alan There's the rub really, "as the response of the aircraft is quite slow". LeeE ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
