On Sunday 02 December 2007 15:18, Roy Vegard Ovesen wrote: > On Sunday 02 December 2007, Roy Vegard Ovesen wrote: > > I think moving a control surface, like for example the rudder, from > > full left deflection to rull right deflection in an instant is > > unrealistic. To make this more realistic I think we should put in a > > low pass filter somewhere in the chain from crontrol device to FDM. > > My first thought would be to do the filtering just befir handing > > the value over to the FDM. > > Turns out that JSBSim and YASim already has what I'm looking for. > > My question then is reduced to: why doesn't more FDM modellers use > these features of JSBSim and YASim to create cotrol surfaces that > seem to have mass > -- > Roy Vegard Ovesen
There are several aspects to this problem and I've not found a single solution to all of them. However, it's usually possible to get there using a combination of techniques. I agree that instant deflections are un-realistic and using the FDM features to set the speed at which control surfaces respond is the first step. To be sure, on some aircraft the deflection rates can be very high e.g. recent fbw fighter aircraft like the F-16 etc, but even with these the response is not instant so a suitable rate should be set in the FDM config. However, setting the deflection rate isn't sufficient in all cases because the the forces required to make a deflection can vary with speed and if we assume constant force control inputs then the effective maximum deflection rate will vary according to speed. Setting too low a deflection rate can also upset A/P PID controllers that work ok with higher deflection rates - I experienced this recently while working on the B-52F. I wanted to reduce the elevator deflection rate to simulate the very heavy stick and pedal forces that act as a natural pitch-damper but I found that setting it too low upset one of the controllers that worked ok with higher rates but I couldn't manage to re-tune it satisfactorily to get the same response with the lower rate. I think this problem is more to do with the rates, and therefore resolution, at which the controllers run in FG, typically less than 100Hz rather than in kHz ranges. Another aspect of this problem, as you mentioned earlier, is when an A/P controller is first switched in. At this point, if the controller sees no natural convergence between the current state and the required state it'll command a maximum output. For example, you're in level flight below the target altitude-hold setting and you switch on altitude-hold - the controller first sees zero climb-rate and therefore zero convergence and so swings to max output. Once the aircraft has responded to this initial max output the controller will then see convergence and back-off on it's output to achieve convergence in accordance with it's settings. It's possible to reduce the initial 'kick' from the controller but only by setting very low gain rates <Kp> and long periods <Ti> but these may not be compatible with the required performance i.e. it can take too long to start a climb and stabilise at the required rate. One way help with this is to use a noise-spike filter to limit the max rate of change on the output from the controller, the filter being tuned to the controller. This problem can also manifest itself when switching between different controller cascades, with different gains and periods, that operate on the same control surface. To get around this I've started using a common control surface driver that is used by all higher-level controllers/controller hierarchies. The lowest level controller is a common pitch-hold driver for the elevator - it takes a target pitch and tries to achieve it by deflecting the elevator. For vertical climb-rate hold you add a controller that outputs a target pitch to achieve a target rate of climb and for altitude hold you add a controller that outputs a target climb-rate. The end result is a two stage cascade for vertical climb-rate hold and a three stage cascade for altitude hold but because there is no switching between controllers at the control surface level, which has constantly been engaged, there is less likelyhood of sudden max output commands. Seems to work ok in practice too - I've used this method on several of the more recent aircraft I've done. Unfortunately though, this method can't be used with aircraft where elevons are used for both pitch and roll (e.g. SU-37) and the best bet there is to use more filters to limit the rates. There are a couple of things relating to this area that would be very helpful. One would be to be able to change some of the filter parameters while they are running or switch filters on and off. With this feature it would be possible to use different filter rates depending on circumstances and/or conditions but as it is, once a filter is running it is always running and with invariable settings. The other thing that would be useful is the flight-control 'black-box' that Curt mentioned, where control inputs could be intercepted and modified before being passed on to the control surfaces. This would be highly desirable for fbw aircraft - for the SU-37 I had to duplicate most of the control inputs in the YASim config so that I could optionally intercept them and modify them using nasal. LeeE ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
