[Flightgear-devel] RFC: Control surface position damping
When prssing the 5 key on the numeric keypad to reset the controls to zero, the control surfaces instantly move to their origin. Similar effects can also happen when an autopilot controller is activated, and when a noisy joystick is interfering with an autopilot controller. 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. Does anyone on the list have comments on this? -- Roy Vegard Ovesen - 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
Re: [Flightgear-devel] RFC: Control surface position damping
On Sunday 02 December 2007, John Denker wrote: That's not a good solution. That's highly unrealistic. In real life, in a small airplane, if I decide to stomp on the rudder pedal, the rudder is going to move real fast. The realistic time scale is not long compared to 1/30th of a second i.e. the inverse frame rate. That is to say, any filter with a realistic timescale wouldn't solve the problem. OK, thats one end of the scale. How about the other end, a big aircraft with huge control surfaces? The filtering would have to be configurable on at least a per aircraft basis. Possibly on a per control surface basis. The problem (as usual) lies with the nut behind the steering wheel. If you don't want the rudder to move real fast, don't command the rudder to move real fast. -- Specifically, if the problem is a noisy joystick, fix the joystick somehow; don't mess up the FDM. -- If 5 is doing the wrong thing, make 5 do the right thing. The problem that I am addressing is the fact that an object can not move from one position to another in an instant. That would of course require an unlimited amount of force. -- Roy Vegard Ovesen - 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
Re: [Flightgear-devel] RFC: Control surface position damping
On Sunday 02 December 2007, David Megginson wrote: That's true for control surface movement in general, but I had (mis)understood that Roy was proposing this specifically for the '5' key -- that's a simulator-specific key that has no real-life equivalent, so binding it to a new command that has a low-pass filter would probably be a good idea. We don't have to worry about realism for this key, just controllability. I mentioned the 5 key only as an example. I am not proposing to put a filter on that command. -- Roy Vegard Ovesen - 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
Re: [Flightgear-devel] RFC: Control surface position damping
On Sun, 2 Dec 2007, Curtis Olson wrote: This touches on an earlier design flaw in FlightGear. We have control inputs feed directly into surface positions, and that is it. There is some horsing around you can do with Nasal, but it's not ideal. What we really should have [I think] is pilot control inputs - [flight control black box] - desired surface positions - actual surface positions. This is certainly possible to do in JSBSim and I'd be very surprised if YASim can't do the same. Cheers, Anders -- --- Anders Gidenstam mail: anders(at)gidenstam.org WWW: http://www.gidenstam.org/FlightGear/JSBSim-LTA/ - 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
Re: [Flightgear-devel] RFC: Control surface position damping
On 02/12/2007, Roy Vegard Ovesen [EMAIL PROTECTED] wrote: I mentioned the 5 key only as an example. I am not proposing to put a filter on that command. In general, then, as others have mentioned, this belongs in the flight models rather than the input layer. The input layer *requests* a position -- it's up to the flight model to decide if or how fast to provide it. Putting the joystick to full right ailerons is just asking full right ailerons, please. I do like the idea of a filter on '5', though. All the best, David - 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
Re: [Flightgear-devel] RFC: Control surface position damping
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 - 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
Re: [Flightgear-devel] RFC: Control surface position damping
On 12/02/2007 10:18 AM, Roy Vegard Ovesen wrote: 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 Probably because in most cases, it would a very unrealistic way to deal with the reported problems. The problem that I am addressing is the fact that an object can not move from one position to another in an instant. Nobody is arguing that they should move in an instant. They can, however, move rather fast. The timescale is not long compared to the inverse framerate of the sim. Any filter that would be noticeable on this timescale would be unrealistic. The problem that I am addressing is the fact that an object can not move from one position to another in an instant. Why? Because it looks bad? If the pilot rapidly moves the control surfaces, it not only looks bad; it *is* bad. However, that doesn't mean it can't happen. http://www.ntsb.gov/publictn/2004/AAR0404.htm That would of course require an unlimited amount of force. Before we can discuss the laws of physics, you need to figure out what *you* are talking about. a) damping [from the subject line] ??? That's a stick force proportional to X dot. b) mass [above] ??? That's a stick force proportional to X dot dot. c) big aircraft with huge control surfaces [previous msg] ??? That can give rise to a stick force proportional to X. d) slew rate limiting in the hydraulic system ??? That's something yet again, not mentioned until now. e) programmed slew rate limiting in the autopilot ??? Since very few of our users have force-feedback joysticks, there is no realistic way to model (a), (b), or (c) ... and attempting to model any of those with the suggested low-pass filter is a bad idea ... worse than no filter at all. Item (d) makes more sense; it should be modeled by the FDM on the few aircraft that actually exhibit a significant amount of this behavior. Item (e) should be modeled within the autopilot. Real autopilots are sure-as-shootin slew rate limited. I mentioned the 5 key only as an example. I am not proposing to put a filter on that command. Too bad; that would have been a sensible proposal. The 5 key is essentially in the autopilot category; it should feed a smooth signal to the control system. This is *not* considered a limitation on how the control system responds to inputs; it is a limitation on the output from the autopilot and autopilot-like systems. = To repeat: 1) In the overwhelming majority of aircraft, Asking the FDM to low-pass filter the controls (to any significant degree) is unrealistic. 2) In the few aircraft where there is a significant limitation in the fly-by-wire system, sure, go ahead and model it. This will require a lot more than a low-pass filter. 3) As the proverb says, pilots are judged on their smoothness, not on their quickness. Smoothness is built into the pilots; it is not usually built into the hardware. - 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
Re: [Flightgear-devel] RFC: Control surface position damping
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
Re: [Flightgear-devel] RFC: Control surface position damping
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 Roy: Possibly, it is because many of the aircraft flight models were written before the specific capabilities became available. There are two flight control components provided by JSBSim which could be added into the control path for a JSBSim aircraft to affect movement of an aerosurface: a kinematic control and an actuator control. The kinematic control is more for flaps. The more recent actuator control provides rate and position limiting, hysteresis, and deadband, among other things. My suspicion is that an actuator would be a very good thing to have in there and the right thing to do. Also, a filter could be added. It is generally not a good idea to alter the inputs to the FDM (joystick and/or keyboard inputs) prior to the FDM getting ahold of the signal. From my point of view, when the simulation creates an artificial condition (such as a reset of some kind, or a skew, or trimming) which is driven by the simulator, then signals to the FDM (i.e. control inputs) can be processed, perhaps to prevent undesirable dynamics. But, for natural and actual inputs, the FDM control system should handle that. I'm unclear as to whether the situation you are referring to is natural or simulation-induced. For more information about the JSBSim actuator and kinematic control components, see: http://jsbsim.sourceforge.net/wiki/index.php/User%27s_Manual#Flight_Control_ Section You will have to scroll down a ways. Jon - 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
Re: [Flightgear-devel] RFC: Control surface position damping
Maik Sent: 02 December 2007 13:49 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] RFC: Control surface position damping Hi Roy, Roy Vegard Ovesen schrieb am 02.12.2007 14:13: When prssing the 5 key on the numeric keypad to reset the controls to zero, the control surfaces instantly move to their origin. Similar effects can also happen when an autopilot controller is activated, and when a noisy joystick is interfering with an autopilot controller. 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. Does anyone on the list have comments on this? With YASim you can limit the speed of any control surface, mostly used for flaps. I use it for all control surfaces where appropriate to simulate servo response time. I would not like key 5 to muck about with this in some pre-cooked and inappropriate way. Key 5 should be just centre the controls - that and no more. If individual aircraft designers want to modulate it in some way, that's down to them. This is a bad idea. Vivian - 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
Re: [Flightgear-devel] RFC: Control surface position damping
On Sun, 2 Dec 2007 14:13:49 +0100 Roy Vegard Ovesen [EMAIL PROTECTED] wrote: When prssing the 5 key on the numeric keypad to reset the controls to zero, the control surfaces instantly move to their origin. Similar effects can also happen when an autopilot controller is activated, and when a noisy joystick is interfering with an autopilot controller. 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. Does anyone on the list have comments on this? This would really mess up helicopter tuning ... the Robinson (in real life ) is very sensitive to minute control inputs ... Cheers -- SydSandy [EMAIL PROTECTED] - 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
Re: [Flightgear-devel] RFC: Control surface position damping
On 12/02/2007 01:14 PM, Jon S. Berndt wrote: In a C-172, for instance, ...there is a direct connection between the stick and rudder. Yup. And that's not limited to little Cessnas, either. Additional examples to illustrate the same point include: DC-9 pilots say that DC stands for Direct Cable from stick to control surfaces ... no hydraulic boost. Similarly MD-80 stands for Mechanically Driven control surfaces. Virtually all aircraft from WWII and before (including transports and bombers) had unboosted controls. The B-24 in particular was notorious for its heavy control forces. B-24 plots trained for athletic strength and endurance. The mass of the control system is not relevant to the pilot in these cases. There is no relevant damping in the control linkage, either. On 12/02/2007 01:42 PM, SydSandy wrote: the Robinson (in real life ) is very sensitive to minute control inputs Yes, that's another whole category of examples illustrating the same point. - 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
Re: [Flightgear-devel] RFC: Control surface position damping
On Sunday 02 December 2007, John Denker wrote: The problem that I am addressing is the fact that an object can not move from one position to another in an instant. Why? Simply because it's impossible, but if it can move faster than our simulator rate, then it does not matter. Or was this a rhetorical question. :-) d) slew rate limiting in the hydraulic system ??? That's something yet again, not mentioned until now. e) programmed slew rate limiting in the autopilot ??? Since very few of our users have force-feedback joysticks, there is no realistic way to model (a), (b), or (c) ... and attempting to model any of those with the suggested low-pass filter is a bad idea ... worse than no filter at all. Item (d) makes more sense; it should be modeled by the FDM on the few aircraft that actually exhibit a significant amount of this behavior. This is readily possible in JSBSim. I was not aware of this when I posted my initial RFC. Item (e) should be modeled within the autopilot. Real autopilots are sure-as-shootin slew rate limited. ... and this is readily possible in the autopilot configuration using the noise spike filter, where you can set the max rate of change. To repeat: 1) In the overwhelming majority of aircraft, Asking the FDM to low-pass filter the controls (to any significant degree) is unrealistic. 2) In the few aircraft where there is a significant limitation in the fly-by-wire system, sure, go ahead and model it. This will require a lot more than a low-pass filter. 3) As the proverb says, pilots are judged on their smoothness, not on their quickness. Smoothness is built into the pilots; it is not usually built into the hardware. -- Roy Vegard Ovesen - 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
