Re: [Flightgear-devel] auto-coordination broken
-- From: leee l...@spatial.plus.com Sent: Tuesday, December 22, 2009 10:05 PM To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] auto-coordination broken On Tuesday 22 Dec 2009, Alan Teeder wrote: [snip...] The Ercoupe and certain other aircraft (e.g. TSR2) may have an aileron-rudder interconnect, but this is very aircraft specific and should be part of the aircraft FCS model. The YASim BAC-TSR2 doesn't/didn't/shouldn't have an aileron-rudder interconnect. Sorry, I should have been clearer. I was referring to the real aircraft, not your YASim model. It was needed to counteract the yaw due to the tailerons. Alan -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] auto-coordination broken
On Wednesday 23 Dec 2009, Alan Teeder wrote: -- From: leee l...@spatial.plus.com Sent: Tuesday, December 22, 2009 10:05 PM To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] auto-coordination broken On Tuesday 22 Dec 2009, Alan Teeder wrote: [snip...] The Ercoupe and certain other aircraft (e.g. TSR2) may have an aileron-rudder interconnect, but this is very aircraft specific and should be part of the aircraft FCS model. The YASim BAC-TSR2 doesn't/didn't/shouldn't have an aileron-rudder interconnect. Sorry, I should have been clearer. I was referring to the real aircraft, not your YASim model. It was needed to counteract the yaw due to the tailerons. Alan Aha - thanks. I didn't know that. LeeE -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] auto-coordination broken
Ron Jensen wrote: Are you sure you don't have some noisy input device like a joystick or pedals connected that might affect the rudder axis? If two input axes are bound to the same control the last write wins. Thanks for the hint. That helps. It makes sense from a developers' point of view. However ... we still have a bug from the users' point of view. The documentation explicitly mentions the case where the user has a rudder input device but lacks the skill to handle the proper ratio ... and recommends --enable-auto-coordination in this case. If users are required to have zero-noise ailerons and zero-noise rudders, this is quite a serious restriction. This should be prominently mentioned in the documentation. Users will not be pleased. O.K. I guess the documentation should say to remove your rudder pedals when auto-coordinating, or perhaps joysticks configs could pick up on it and not try to drive the rudder. I think all that is required is that we make clear that auto-coordination is designed to help people without any rudder control axis, and that a proper rudder axis (or even a twist axis on a joystick) is preferable. I'll do that in the documentation. However, to hijack the thread further ... ;) There was some previous discussion about the fact that we have manual controls and some autopilots all mapping to a single set of control properties (/controls/flight/[aileron|elevator|rudder]). This is realistic, but because of the limitations of the simulator environment, this can cause them to fight for control - the classic example being someone moving their joystick while the autopilot is switched on. I think if we every fix that, we should consider auto-coordination as another channel into that control mixer. -Stuart -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] auto-coordination broken
Moving the joystick or throttle should override the autopilot/autothrotle and cause it to disconnect. Yaw dampers, stick pushers and other stability augmentation demands are added to the pilots´s joystick/rudder input, they would not normally override it. In a training mode there is a case for letting the autopilot automatically re-engage when the pilot has stopped playing around so that the aircraft returns to stable flight. The Ercoupe and certain other aircraft (e.g. TSR2) may have an aileron-rudder interconnect, but this is very aircraft specific and should be part of the aircraft FCS model. Surely the deadspace function of the joystick configuration is meant to cope with noise problems.. Alan -- From: Stuart Buchanan stuart_d_bucha...@yahoo.co.uk Sent: Tuesday, December 22, 2009 9:35 AM To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] auto-coordination broken Ron Jensen wrote: Are you sure you don't have some noisy input device like a joystick or pedals connected that might affect the rudder axis? If two input axes are bound to the same control the last write wins. Thanks for the hint. That helps. It makes sense from a developers' point of view. However ... we still have a bug from the users' point of view. The documentation explicitly mentions the case where the user has a rudder input device but lacks the skill to handle the proper ratio ... and recommends --enable-auto-coordination in this case. If users are required to have zero-noise ailerons and zero-noise rudders, this is quite a serious restriction. This should be prominently mentioned in the documentation. Users will not be pleased. O.K. I guess the documentation should say to remove your rudder pedals when auto-coordinating, or perhaps joysticks configs could pick up on it and not try to drive the rudder. I think all that is required is that we make clear that auto-coordination is designed to help people without any rudder control axis, and that a proper rudder axis (or even a twist axis on a joystick) is preferable. I'll do that in the documentation. However, to hijack the thread further ... ;) There was some previous discussion about the fact that we have manual controls and some autopilots all mapping to a single set of control properties (/controls/flight/[aileron|elevator|rudder]). This is realistic, but because of the limitations of the simulator environment, this can cause them to fight for control - the classic example being someone moving their joystick while the autopilot is switched on. I think if we every fix that, we should consider auto-coordination as another channel into that control mixer. -Stuart -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] auto-coordination broken
On 12/22/2009 02:35 AM, Stuart Buchanan wrote: I think all that is required is that we make clear that auto-coordination is designed to help people without any rudder control axis, and that a proper rudder axis (or even a twist axis on a joystick) is preferable. On 12/21/2009 08:59 PM, Curtis Olson wrote: Yup, it's never been intended to be more than a simple work around for people without rudder pedals or a twist grip on their joystick. A game feature is a good description I think. In order to document it as a game feature we need some basic information. What do gamers actually use the auto-coordination feature for? -- what game? -- what model aircraft? -- what benefit are they getting from this feature? Out of the 358 aircraft available in my copy of FG, I can think of only a handful that I would expect to have better coordination with auto-coordination enabled. No, the Ercoupe is not one of them; it has an aileron/rudder interconnect even without this feature, and does not benefit from the feature. Even the Sopwith Camel, which in the Real World was notorious for its unharmonious controls, in the Sim World benefits only slightly from the auto-coordination feature. I doubt most gamers would notice. Most modern aircraft come from the factory with reasonably harmonious controls. That is, under cruise conditions, they fly just fine with feet on the floor (as opposed to feet on the pedals). Such aircraft handle distinctly worse with auto-coordination turned on. As for the default c172p, auto-coordination might not make it much worse ... but that's only because the model's basic aerodynamics is so messed up. It has an order of magnitude too much adverse yaw at cruise. Rather than messing with auto-coordination and all the attendant limitations and bad side-effects, it would be mch easier to use a saner set of aero coefficients ... especially when you consider that some users have rudder pedals, and use them, and want to use them with more realism. A patch to improve the c172p is available. If we are going to document the auto-coordination feature, we must document the restrictions. The user must a) have no rudder-axis input devices, or b) unplug all rudder-axis devices, or c) make sure any rudder-axis devices have zero noise, or d) edit the .xml driver to discard rudder events, or e) never use the auto-coordination feature Chez moi the preferred option is (e). The only other option would be (d), since my joystick has an integrated rudder axis that cannot be unplugged. Its noise level is just low enough that when sporadic events come in, they are surprising. I suspect that most gamers would be pretty unhappy with options (c) and (d). I suspect that most people on this list stick with option (e). Also the user must: x) make sure the aileron input device has zero noise, or y) rely on CWS (control wheel steering) to the exclusion of other steering features (e.g. keyboard insert/enter), or z) never use the auto-coordination feature. All in all, it's hard to come up with plausible use-case scenarios for this feature. We've heard how this feature was intended to be used. If anybody knows how it is actually used, please let us know. As I asked before, how hard would it be to implement a feature that actually improved coordination, perhaps something that works more like a yaw damper? Or is it better to forget about the whole topic, and let rudderless gamers rely on the natural feet-on-the-floor behavior of the aircraft? = I won't bother to ask why some people consider a discussion of auto-coordination to be hijacking an auto-coordination thread. I reckon we all know the answer to that one. On 12/22/2009 03:04 AM, Alan Teeder wrote in part: Yaw dampers, stick pushers and other stability augmentation demands are added to the pilots´s joystick/rudder input, they would not normally override it. Quite so. Also, the aileron/rudder interconnect on aircraft such as the Beech Bonanza is springy such that you can overpower it using the obvious technique, by pushing the yoke one way and pushing the pedals the other way. This allows you to slip the aircraft e.g. for a crosswind landing. The auto-coordination feature does not provide a good model of this. Evidently it was never intended to do so. The pilot is out of luck if he needs to make a crosswind landing. This makes a certain amount of sense from the developers' viewpoint, but from the users' viewpoint it is all quite mysterious and unhelpful. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev
Re: [Flightgear-devel] auto-coordination broken
On 22 Dec 2009, at 12:23, John Denker wrote: I won't bother to ask why some people consider a discussion of auto-coordination to be hijacking an auto-coordination thread. I think that comment was because you replied to the 'autopilot broken' thread to start the auto-coordination discussion. At least, that's what my mail client thinks happened, in terms of its threading display. Regards, James -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] auto-coordination broken
On Tuesday 22 Dec 2009, Alan Teeder wrote: [snip...] The Ercoupe and certain other aircraft (e.g. TSR2) may have an aileron-rudder interconnect, but this is very aircraft specific and should be part of the aircraft FCS model. The YASim BAC-TSR2 doesn't/didn't/shouldn't have an aileron-rudder interconnect. In fact, it only has flaps on the wing and lacks proper ailerons and instead it uses the slab elevons for roll control (although fully floating, in real life the fully floating tailplanes also incorporated powered flaps but these aren't modelled in the YASim BAC-TSR2 config. The tailfin lacks any actuated control surfaces but is entirely fully floating, like the tailplanes, so the whole thing twists. Anyway, I didn't include any link between the roll and rudder controls in the BAC-TSR2. Also, I was under the impression that auto-coordination was a JSBSim feature and did nothing when enabled for other FDMs. LeeE -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] auto-coordination broken
Hi, The –enable-auto-coordination feature never worked very well, but now it even more broken than it used to be. I observe different symptoms in different aircraft. In the default c172p, it appears to have no effect at all. If so, then it must be something happened recently. With CVS from 11/27/2009 the Auto-Coordination I see no problems, it shows the excepted effect. In the SenecaII, the most observable effect is that it makes it impossible to steer when trying to taxi. In the air it does not noticeably improve the coordination. Sometimes I see an intermittent flutter in the rudder, suggesting that one process is trying to throw the rudder hard over while another process is trying to center it. Did you try to turn on/off jaw damper? All those aircrafts named here are JSBSim- how do YASim-aircrafts react? Cheers HHS __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] auto-coordination broken
On Mon, Dec 21, 2009 at 3:21 PM, Heiko Schulz wrote: Did you try to turn on/off jaw damper? Hah, I tried that on my wife and it didn't work ... :-) (jaw being a bone in the mouth, yaw being side to side motion.) Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] auto-coordination broken
Did you try to turn on/off jaw damper? Hah, I tried that on my wife and it didn't work ... :-) (jaw being a bone in the mouth, yaw being side to side motion.) Curt. -- Upss...Lol! :D Maybe I used this word instead because thinking of my own jaw which still pains a bit after surgery last week! ;-) Well, of course I meant Yaw-damper! Sorry! Cheers HHS __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] auto-coordination broken
On Mon, 21 Dec 2009, John Denker wrote: In the default c172p, it appears to have no effect at all. In the SenecaII, the most observable effect is that it makes it impossible to steer when trying to taxi. In the air it does not noticeably improve the coordination. Sometimes I see an intermittent flutter in the rudder, suggesting that one process is trying to throw the rudder hard over while another process is trying to center it. Hi, It seems to work ok here. Are you sure you don't have some noisy input device like a joystick or pedals connected that might affect the rudder axis? If two input axes are bound to the same control the last write wins. Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] auto-coordination broken
On 12/21/2009 02:36 PM, Anders Gidenstam wrote: It seems to work ok here. Interesting Are you sure you don't have some noisy input device like a joystick or pedals connected that might affect the rudder axis? If two input axes are bound to the same control the last write wins. Thanks for the hint. That helps. It makes sense from a developers' point of view. However ... we still have a bug from the users' point of view. The documentation explicitly mentions the case where the user has a rudder input device but lacks the skill to handle the proper ratio ... and recommends --enable-auto-coordination in this case. If users are required to have zero-noise ailerons and zero-noise rudders, this is quite a serious restriction. This should be prominently mentioned in the documentation. Users will not be pleased. = I just now spent some time looking into this, and found a few surprises. When auto-coordination is turned on: 1) The feature is implemented as an aileron-rudder interconnect with a fixed ratio (half a unit of rudder per unit of aileron) in the aileron-rudder direction and not vice versa. This is not very sophisticated or very useful. In almost every aircraft I can think of, it is literally worse than useless in cruising flight. It makes the coordination worse. If this is the desired behavior, I would hate to see what undesired behavior looks like. The documentation indicates that auto-coordination is supposed to make the coordination better. It doesn't. 2) It has the remarkable side-effect that while taxiing, you can steer by deflecting the ailerons! This is unrealistic and unhelpful; better ways of doing the steering are readily available. 3) While taxiing, you can steer using the rudder in the usual way, overriding auto-coordination ... provided you don't touch the ailerons! That is counterintuitive, undocumented, and unhelpful. The FAA says you should be deflecting the ailerons when taxiing, if there is any crosswind. You must not touch the ailerons, and must hope there is no noise on your joystick aileron axis. This is in addition to the previous requirement for no noise on your rudder axis. = How hard would it be to replace all this with something useful? I notice that several of the aircraft models have yaw dampers. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] auto-coordination broken
On Mon, 2009-12-21 at 17:45 -0700, John Denker wrote: On 12/21/2009 02:36 PM, Anders Gidenstam wrote: It seems to work ok here. Interesting Another thread hijacked. Are you sure you don't have some noisy input device like a joystick or pedals connected that might affect the rudder axis? If two input axes are bound to the same control the last write wins. Thanks for the hint. That helps. It makes sense from a developers' point of view. However ... we still have a bug from the users' point of view. The documentation explicitly mentions the case where the user has a rudder input device but lacks the skill to handle the proper ratio ... and recommends --enable-auto-coordination in this case. If users are required to have zero-noise ailerons and zero-noise rudders, this is quite a serious restriction. This should be prominently mentioned in the documentation. Users will not be pleased. O.K. I guess the documentation should say to remove your rudder pedals when auto-coordinating, or perhaps joysticks configs could pick up on it and not try to drive the rudder. = I just now spent some time looking into this, and found a few surprises. When auto-coordination is turned on: 1) The feature is implemented as an aileron-rudder interconnect with a fixed ratio (half a unit of rudder per unit of aileron) in the aileron-rudder direction and not vice versa. This is not very sophisticated or very useful. In almost every aircraft I can think of, it is literally worse than useless in cruising flight. It makes the coordination worse. If this is the desired behavior, I would hate to see what undesired behavior looks like. This is the behavior in the rudder pedal-less Ercoupe. And that aircraft flies with FAA approval. The documentation indicates that auto-coordination is supposed to make the coordination better. It doesn't. 2) It has the remarkable side-effect that while taxiing, you can steer by deflecting the ailerons! This is unrealistic and unhelpful; better ways of doing the steering are readily available. 3) While taxiing, you can steer using the rudder in the usual way, overriding auto-coordination ... provided you don't touch the ailerons! That is counterintuitive, undocumented, and unhelpful. The FAA says you should be deflecting the ailerons when taxiing, if there is any crosswind. Again, the behavior in the rudder pedal-less Ercoupe. And that aircraft flies with FAA approval. Seriously, if you're trying for an FAA level of realism when taxiing why are you flying with auto-coordination at all? You must not touch the ailerons, and must hope there is no noise on your joystick aileron axis. This is in addition to the previous requirement for no noise on your rudder axis. In my view --enable-auto-coordination is a game feature, and usable for people without a rudder axis control. A group you seem to have completely overlooked. = How hard would it be to replace all this with something useful? I notice that several of the aircraft models have yaw dampers. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] auto-coordination broken
On Mon, Dec 21, 2009 at 9:54 PM, Ron Jensen wrote: In my view --enable-auto-coordination is a game feature, and usable for people without a rudder axis control. A group you seem to have completely overlooked. Yup, it's never been intended to be more than a simple work around for people without rudder pedals or a twist grip on their joystick. A game feature is a good description I think. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
