On Saturday 10 Oct 2009, Pete Morgan wrote: > Roy Vegard Ovesen wrote: > > On Saturday 10 October 2009 22:33:01 Curtis Olson wrote: > >> Really, this is all in how the autopilot is tuned and > >> configured. > >> > >> FlightGear doesn't model realistic control surface deflection > >> rates so it's possible to command an instantaneous deflection > >> of the control surfaces. Control surface deflection rate can > >> be limited by inserting a low-pass filter between the output > >> of the final PID-controller and the control surface. THis is > >> done in the autopilot config file. > > I expected FlightGear to crete the realistic mdel.. and > deflection rate.. > > So your response cofirmas a few facts... > > 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. This isn't ideal, of course, but running an entire flight simulator on a single PC is always going lead to compromises. Having said that though, there are a number ways of working around most of the problems. There isn't really a problem with the autopilot code or the FDMs in flight gear, but that doesn't mean that individual FDMs and autopilots are always optimally configured. As Jon said, JSBSim incorporates actuator simulation, and I know that YASim allows you to set control surface deflection rate limits. These should really be set up in the aircraft FDM config and it is down to the developer to do this. However, few of the people developing aircraft for FG could be described as professionals in this field so you shouldn't expect everything to be absolutely perfect. So first of all, have a look at the FDM configs for the aircraft you're using and, depending on which FDM is being used, find out whether the actuators or rate limits have been set up correctly. The next thing to do is to look at the autopilot config. When the 'new' PID/PI autopilot was introduced, Roy set up a basic 'example' autopilot configuration to show how the new controllers could be used and this has formed the basis for most of the autopilots since then. The basic autopilot that Roy set up used two-stage controller cascades, where the output from the first stage controller was fed into the second stage. For example, in the true-heading-hold mode, the first stage controller would look at the true-heading-error-deg property and generate a desired roll setting to turn the aircraft and reduce the true-heading-error-deg to zero. The second stage would then take the desired roll setting and generate an aileron deflection to achieve the required roll. As the aircraft turns and true-heading-error-deg starts to approach zero, the controller will detect this and command a reduced degree of roll. Similarly, the second stage controller will look at the current degree of roll and compare it with the required degree of roll and if the two are very different the second stage controller will command a large deflection (this is where the jerkiness come from). Then, as the difference between the current roll and required roll reduces, the controller will command less deflection. The jerkiness then, can occur when the first stage controller sees a large difference between its current state and the state required, and quite reasonably commands the maximum change it is allowed. For example, if you're flying level and then tell the autopilot that you want to fly in the opposite direction it will quickly decide that it needs to command maximum roll. Now the second stage controller, which controls the ailerons to achieve the desired rate of roll, has to be quite aggressive in the way that it works if it is to tightly control roll, both because it has to operate over a much shorter time span than the first stage controller (to turn an aircraft through 180 degrees may take several minutes but to achieve 40 deg of roll may only take a few seconds) and also to prevent the aircraft from 'over-rolling' and then see-sawing as it then corrects itself, but this means that when it is told to change the current roll from zero to, 40 degrees say, it sees a very large error, just as the first stage controller has seen, and command its maxmum deflection. One way then, to ameliorate this is to use a filter between the two stages so that the difference between the current roll and required roll is relatively slowly increased: the first stage controller may command a 40 deg roll but the filter can limit the rate of change to, say 10 deg/second with the result that the second stage controller doesn't see a sudden change from zero to 40 deg but instead, a gradual change at 10 deg/second. (I know that Roy suggested that a filter be used on the output from the second stage controller, but I think this is probably better done in the FDM using the actuator sub-system in JSBSim or the rate limiters in YASim) Another way that jerkiness can occur is when switching between different modes and the problem here is rather different. In Roy's example autopilot, different pairs of controller cascades are used for different modes and when switching between modes this means that one pair of controllers are switched off and another pair are switched on. It may seem a bit strange to use entirely different pairs of controllers for different modes but this is because the inputs to the different modes are likely to be over completely different ranges and the gains and limits etc. will need to be very different to reflect this. The problem that arises from this is that the controllers, which rely upon a feedback loop, have no initial feedback when they are first engaged and because they will have different inputs, gains and limits etc. are likely to see an immediate error and initially command their maximum outputs. As soon as the aircraft responds to these commands though, the controllers get their feedback and can then start to work more smoothly. Regarding this aspect of the autopilot, I ended up using common final stage controllers i.e. a common aileron controller, that was then used by all the different first stage controllers, so that the aileron controller was always engaged and never switched off. However, this meant that the controller had to be very tightly tuned and controlled, which quite frankly took a lot of test-flying time and for pitch/altitude modes meant using a three-stage controller cascade. Another avenue to explore is to dynamically change the controller settings while in flight. It is possible to modify many of the controller settings, such as the gain etc. by the use of Nasal or by using other controllers and/or filters. This too can be very effective, but needs a correspondingly longer amount of time and effort in development and testing to get right. Perhaps I should apologise for going into this in so much depth but it seemed from your postings that you didn't really understand the problem; obviously, you won't be able to fix it until you do. As it happens, the autopilot framework in FG is very good indeed: the range of controller functions and filter types allow nearly anything to be done, at least in theory, and are only limited in practice by the rates at which they can be run. What you're trying to do sounds very interesting, but as I said, you'll not be able to do it without understanding what it is that you're working with. Working on developing and tuning the FG autopilots can take an awful lot of time and can lead to an awful lot of frustration but they're not magical or mystical and impossible to understand, and it is very rewarding when you finally get them working. 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
