Re: [Flightgear-devel] auto-coordination
Hi Syd,
This is now in git:
The auto-coordination and auto-coordination-factor properties now live
in /controls/flight. A backward compatibility check in aircraft.nas
checks if somebody created /sim/auto-coordination and if so, spits out
a warning messages and makes this property an alias pointing to the new
one in /controls/flight.
The auto-coordination-factor gets initialized with the default value of
0.5 if it does not exist but keeps it's value if it does exist.
This implementation does not break the existing behavior (well,
hopefully). One now may change the amount of rudder deflection due to
aileron deflection (if auto-coordination is on) by changing the factor
property. Setting the factor property to zero does not move the rudder,
even if auto-coordination is on.
Long message for something that simple, just give it a try ;-)
FG and FGDATA pull required!
Torsten
Am 10.03.2012 15:21, schrieb syd adams:
Sounds good to me.Thanks for dealing with this.
Syd
On Sat, Mar 10, 2012 at 2:45 AM, Torsten Dreyertors...@t3r.de wrote:
This is in fact my preferred solution.
- it does not break existing aircraft
- it keeps existing --enable-auto-coordination behavior
- it is configurable, even at runtime
- minimal code change
I have the patch ready and I'm about to commit it. While at it, I'd like
to move the involved properties out of /sim/ to /controls.
/sim is so very much unstructured and a melting pot for properties that
never found an appropriate location. And I think /controls just fits
better than don't know where, so put it in /sim. Objections?
I'll take care of the wrightFlyer1903, the pa22, the waveXtreme150, the
Saitek X52 and the bintest protocol in FGDATA and adjust the names
accordingly.
Torsten
Am 09.03.2012 21:41, schrieb syd adams:
Now that sounds like an even better idea.Less chance of breaking
anything , but still adjustable.Thanks Torsten.
On Fri, Mar 9, 2012 at 1:32 PM, Torsten Dreyertors...@t3r.dewrote:
Am 09.03.2012 20:44, schrieb syd adams:
Ok I haven't entirely given up on the idea of removing the
auto-coordination from the code.Wouldn't it be more appropriate to add
that rudder control to controls.nas?
Then it can be replaced if need be on a per aircraft basis , but not
break anything
otherwise.And maybe it could be slip/skid-ball driven ... my whole
point is NOT to disable it but make it configurable.
Currently the rudder is set to 0.5 * aileron if autocoordination is
enabled. The value of 0.5 is hardcoded.
An easy and portable way to implement your request might be to introduce
a new property (e.g. /sim/auto-coordination-factor) with the default
value of 0.5. and change the code
if ( auto_coordination-getBoolValue() ) {
set_rudder( aileron / 2.0 );
}
to
if ( auto_coordination-getBoolValue()
auto_coordination_factor-getDoubleValue()0.0 ) {
set_rudder( aileron * auto_coordination_factor-getDoubleValue() );
}
so that setting /sim/auto-coordination-factor to a value of zero or less
disables the hardcoded auto-coordination but leaves the command-line
argument and the enable-property usable.
Torsten
--
VirtualizationCloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
VirtualizationCloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
Virtualization Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
Virtualization Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
Re: [Flightgear-devel] auto-coordination
On Thu, 8 Mar 2012 23:51:16 -0700, syd wrote in message CABS5FFOT8DrHfY63Aw=keqvrb7oh31qjg0fymgxjny2efps...@mail.gmail.com: On Thu, Mar 8, 2012 at 10:19 PM, Curtis Olson curtol...@gmail.com wrote: Hi Syd, That was a hack from the very early days of the project, so if it went away, it wouldn't bother me. Fred might have a check box in the window launcher, and there may be a command line option or property value to hunt down and remove. Curt Thanks , Curt. Actually I'd prefer the auto-coordination property to remain , and the options to enable it too , just that it be handled in an autopilot file rather than hard-coded. I've added a sort of auto coordination to the R22 below a certain airspeed, ..sort of like an RC helicopter tail lock (yaw control) gyro? otherwise I cant get it off the ground no matter how fast I tap those rudder keys , and enabling auto-coordination would be a easier in these situations, i think. ..I disagree, I believe a yaw control gyro would work better than locking the rudder to the aileron controls, as you will have the correct yaw trim immediately on starting climb-out, if you let the plane lift off as it is ready to fly, even works for short field take-offs, just kick in flaps and rotate early to take the weight off the wheels asap as you would on a slushy dirt field. ..and I take it we wanna model RC choppers and fpv flying too, and some of the fpv guys use 3-axis gyro etc autopilots. ..now, if yank it off... ;o) At least for those of us without rudder pedals. ..try a 3-axis stick, or an RC transmitter 2 stick box, some real RC transmitters can also be used with the sound card, some use usb wires. ..at the other end of the scale, try the keyboard on an eeepc @ ~3fps... ;o) if you guys wanna cure your habits of over-controlling... ;o) ..the c172p is easier if you give it the first flap step, full pwr, release parking and keep it straight with rudder, @ ~40kts give it two clicks up, then be ready to pick up the low wing with right rudder on lift-off, takes about 4 to 7 clicks, ease off one click on the elevator to keep the nose down, you wanna climb at 70kts. ..at 300ft you're ready to clean up the wing | bring up the flaps and climb at 75kts or so. At say 500ft, back off throttle to ~75%, zero elevator, use elevator trim to set your speed, and back off 2 or 3 or 4 clicks of right rudder until you're turning the way you wanna turn. ;o) ..to cruise straight ahead, pick the closest rudder click, then play with elevator trim and power settings until you're straight. ..if the c172p moves around too quickly on you, try Tante Ju (ju52) or a twin with counter rotating props, e.g. a P38, or the mc-72, they fly straight until you start playing with assymmetric power. It would mean more work for aircraft designers , but a simple filter should easily do what the code does. Syd -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] auto-coordination
haven't had your morning coffee yet ? ;) -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] auto-coordination
This is in fact my preferred solution.
- it does not break existing aircraft
- it keeps existing --enable-auto-coordination behavior
- it is configurable, even at runtime
- minimal code change
I have the patch ready and I'm about to commit it. While at it, I'd like
to move the involved properties out of /sim/ to /controls.
/sim is so very much unstructured and a melting pot for properties that
never found an appropriate location. And I think /controls just fits
better than don't know where, so put it in /sim. Objections?
I'll take care of the wrightFlyer1903, the pa22, the waveXtreme150, the
Saitek X52 and the bintest protocol in FGDATA and adjust the names
accordingly.
Torsten
Am 09.03.2012 21:41, schrieb syd adams:
Now that sounds like an even better idea.Less chance of breaking
anything , but still adjustable.Thanks Torsten.
On Fri, Mar 9, 2012 at 1:32 PM, Torsten Dreyertors...@t3r.de wrote:
Am 09.03.2012 20:44, schrieb syd adams:
Ok I haven't entirely given up on the idea of removing the
auto-coordination from the code.Wouldn't it be more appropriate to add
that rudder control to controls.nas?
Then it can be replaced if need be on a per aircraft basis , but not
break anything
otherwise.And maybe it could be slip/skid-ball driven ... my whole
point is NOT to disable it but make it configurable.
Currently the rudder is set to 0.5 * aileron if autocoordination is
enabled. The value of 0.5 is hardcoded.
An easy and portable way to implement your request might be to introduce
a new property (e.g. /sim/auto-coordination-factor) with the default
value of 0.5. and change the code
if ( auto_coordination-getBoolValue() ) {
set_rudder( aileron / 2.0 );
}
to
if ( auto_coordination-getBoolValue()
auto_coordination_factor-getDoubleValue() 0.0 ) {
set_rudder( aileron * auto_coordination_factor-getDoubleValue() );
}
so that setting /sim/auto-coordination-factor to a value of zero or less
disables the hardcoded auto-coordination but leaves the command-line
argument and the enable-property usable.
Torsten
--
Virtualization Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
Virtualization Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
Virtualization Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] auto-coordination
Sounds good to me.Thanks for dealing with this.
Syd
On Sat, Mar 10, 2012 at 2:45 AM, Torsten Dreyer tors...@t3r.de wrote:
This is in fact my preferred solution.
- it does not break existing aircraft
- it keeps existing --enable-auto-coordination behavior
- it is configurable, even at runtime
- minimal code change
I have the patch ready and I'm about to commit it. While at it, I'd like
to move the involved properties out of /sim/ to /controls.
/sim is so very much unstructured and a melting pot for properties that
never found an appropriate location. And I think /controls just fits
better than don't know where, so put it in /sim. Objections?
I'll take care of the wrightFlyer1903, the pa22, the waveXtreme150, the
Saitek X52 and the bintest protocol in FGDATA and adjust the names
accordingly.
Torsten
Am 09.03.2012 21:41, schrieb syd adams:
Now that sounds like an even better idea.Less chance of breaking
anything , but still adjustable.Thanks Torsten.
On Fri, Mar 9, 2012 at 1:32 PM, Torsten Dreyertors...@t3r.de wrote:
Am 09.03.2012 20:44, schrieb syd adams:
Ok I haven't entirely given up on the idea of removing the
auto-coordination from the code.Wouldn't it be more appropriate to add
that rudder control to controls.nas?
Then it can be replaced if need be on a per aircraft basis , but not
break anything
otherwise.And maybe it could be slip/skid-ball driven ... my whole
point is NOT to disable it but make it configurable.
Currently the rudder is set to 0.5 * aileron if autocoordination is
enabled. The value of 0.5 is hardcoded.
An easy and portable way to implement your request might be to introduce
a new property (e.g. /sim/auto-coordination-factor) with the default
value of 0.5. and change the code
if ( auto_coordination-getBoolValue() ) {
set_rudder( aileron / 2.0 );
}
to
if ( auto_coordination-getBoolValue()
auto_coordination_factor-getDoubleValue() 0.0 ) {
set_rudder( aileron * auto_coordination_factor-getDoubleValue() );
}
so that setting /sim/auto-coordination-factor to a value of zero or less
disables the hardcoded auto-coordination but leaves the command-line
argument and the enable-property usable.
Torsten
--
Virtualization Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
Virtualization Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
Virtualization Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
Virtualization Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] auto-coordination
Also, the real pa22 Tri-Pacer has a spring rudder interlock with the ailerons so it can be overridden by the pilot when he wants to have cross control as in a cross wind. Dave P. On 03/09/2012 02:45 PM, Adam Dershowitz, Ph.D., P.E. wrote: Few, but at least one: http://en.wikipedia.org/wiki/ERCO_Ercoupe --Adam On Mar 9, 2012, at 12:05 PM, Curtis Olson wrote: The counter argument here is that the existing auto coordination system is nothing more than one line of code that forces some rudder deflection in proportion to aileron deflection -- basically implementing some sort of hard linked manual system. I am sure there are very few (if any?) real life aircraft rigged in such a way. Curt. On Fri, Mar 9, 2012 at 1:57 PM, Renk Thorsten wrote: Ok I haven't entirely given up on the idea of removing the auto-coordination from the code. Why? Wouldn't it be more appropriate to add that rudder control to controls.nas? Nasal runs per graphical frame, FDMs may need to run faster at low framerates. Nasal AP systems tend to become unstable below 15 fps or so (see the F-14b). Then it can be replaced if need be on a per aircraft basis , but not break anything otherwise. You can replace it now on a per aircraft basis at the simple expense of setting a single property to false. If the aircraft is equipped with a better system, then that system can do so. Why is that a problem? And maybe it could be slip/skid-ball driven ... my whole point is NOT to disable it but make it configurable. Yes, them make it configurable on any aircraft you like. But it should not be absent from any aircraft you haven't touched. Cheers, * Thorsten -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net mailto:Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com http://www.atiak.com/ - http://aem.umn.edu/~uav/ http://aem.umn.edu/%7Euav/ http://www.flightgear.org http://www.flightgear.org/ - http://gallinazo.flightgear.org http://gallinazo.flightgear.org/ -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] auto-coordination
Am 09.03.2012 07:51, schrieb syd adams: On Thu, Mar 8, 2012 at 10:19 PM, Curtis Olsoncurtol...@gmail.com wrote: Hi Syd, That was a hack from the very early days of the project, so if it went away, it wouldn't bother me. Fred might have a check box in the window launcher, and there may be a command line option or property value to hunt down and remove. Curt Thanks , Curt. Actually I'd prefer the auto-coordination property to remain , and the options to enable it too , just that it be handled in an autopilot file rather than hard-coded. I've added a sort of auto coordination to the R22 below a certain airspeed, otherwise I cant get it off the ground no matter how fast I tap those rudder keys , and enabling auto-coordination would be a easier in these situations, i think. At least for those of us without rudder pedals. It would mean more work for aircraft designers , but a simple filter should easily do what the code does. Syd I can add it to the generic-autopilot-helper or generic-autopilot and remove the hardcoded part. Aircraft overwriting the generic-autopilot (defining their own A/P) will have to implement their own auto-coordination, though. Torsten -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] auto-coordination
Some of us don't have a joystick and fl with a mouse and autopilot.. auto-coordination has to stay.. however.. just realised it DOES mess up the autopilot... pete On Fri, Mar 9, 2012 at 6:51 AM, syd adams adams@gmail.com wrote: On Thu, Mar 8, 2012 at 10:19 PM, Curtis Olson curtol...@gmail.com wrote: Hi Syd, That was a hack from the very early days of the project, so if it went away, it wouldn't bother me. Fred might have a check box in the window launcher, and there may be a command line option or property value to hunt down and remove. Curt Thanks , Curt. Actually I'd prefer the auto-coordination property to remain , and the options to enable it too , just that it be handled in an autopilot file rather than hard-coded. I've added a sort of auto coordination to the R22 below a certain airspeed, otherwise I cant get it off the ground no matter how fast I tap those rudder keys , and enabling auto-coordination would be a easier in these situations, i think. At least for those of us without rudder pedals. It would mean more work for aircraft designers , but a simple filter should easily do what the code does. Syd -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] auto-coordination
syd adams wrote: Actually I'd prefer the auto-coordination property to remain , and the options to enable it too , just that it be handled in an autopilot file rather than hard-coded. I'm not sure if I understood what you had in mind, therefore, beware, I might miss you point. Anyhow from my perspective the auto-coordination is very much user specific and in no way aircraft specific. Therefore I think it's not a clever idea to remove the global auto-coordination feature because those who don't have pedals will need it for _every_ aircraft. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] auto-coordination
OK ,I was just gathering opinions , and it appears it should stay.Now I know how to proceed. Thanks guys. Syd -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] auto-coordination
On Fri, Mar 9, 2012 at 4:28 AM, Martin Spott martin.sp...@mgras.net wrote: syd adams wrote: Actually I'd prefer the auto-coordination property to remain , and the options to enable it too , just that it be handled in an autopilot file rather than hard-coded. I'm not sure if I understood what you had in mind, therefore, beware, I might miss you point. Anyhow from my perspective the auto-coordination is very much user specific and in no way aircraft specific. Therefore I think it's not a clever idea to remove the global auto-coordination feature because those who don't have pedals will need it for _every_ aircraft. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel My thoughts were to keep the auto-coordination option , that is user specific, but to have the autopilot files manage the controls rather than having it hard-coded,which would allow it to be fine tuned per aircraft , but the general opinion seems to be 'bad idea' which is fine with me . Syd -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] auto-coordination
Ok I haven't entirely given up on the idea of removing the auto-coordination from the code.Wouldn't it be more appropriate to add that rudder control to controls.nas? Then it can be replaced if need be on a per aircraft basis , but not break anything otherwise.And maybe it could be slip/skid-ball driven ... my whole point is NOT to disable it but make it configurable. Syd -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] auto-coordination
Ok I haven't entirely given up on the idea of removing the auto-coordination from the code. Why? Wouldn't it be more appropriate to add that rudder control to controls.nas? Nasal runs per graphical frame, FDMs may need to run faster at low framerates. Nasal AP systems tend to become unstable below 15 fps or so (see the F-14b). Then it can be replaced if need be on a per aircraft basis , but not break anything otherwise. You can replace it now on a per aircraft basis at the simple expense of setting a single property to false. If the aircraft is equipped with a better system, then that system can do so. Why is that a problem? And maybe it could be slip/skid-ball driven ... my whole point is NOT to disable it but make it configurable. Yes, them make it configurable on any aircraft you like. But it should not be absent from any aircraft you haven't touched. Cheers, * Thorsten -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] auto-coordination
The counter argument here is that the existing auto coordination system is nothing more than one line of code that forces some rudder deflection in proportion to aileron deflection -- basically implementing some sort of hard linked manual system. I am sure there are very few (if any?) real life aircraft rigged in such a way. Curt. On Fri, Mar 9, 2012 at 1:57 PM, Renk Thorsten wrote: Ok I haven't entirely given up on the idea of removing the auto-coordination from the code. Why? Wouldn't it be more appropriate to add that rudder control to controls.nas? Nasal runs per graphical frame, FDMs may need to run faster at low framerates. Nasal AP systems tend to become unstable below 15 fps or so (see the F-14b). Then it can be replaced if need be on a per aircraft basis , but not break anything otherwise. You can replace it now on a per aircraft basis at the simple expense of setting a single property to false. If the aircraft is equipped with a better system, then that system can do so. Why is that a problem? And maybe it could be slip/skid-ball driven ... my whole point is NOT to disable it but make it configurable. Yes, them make it configurable on any aircraft you like. But it should not be absent from any aircraft you haven't touched. Cheers, * Thorsten -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] auto-coordination
Am 09.03.2012 20:57, schrieb Renk Thorsten: Ok I haven't entirely given up on the idea of removing the auto-coordination from the code. Why? Wouldn't it be more appropriate to add that rudder control to controls.nas? Nasal runs per graphical frame, FDMs may need to run faster at low framerates. Nasal AP systems tend to become unstable below 15 fps or so (see the F-14b). Then it can be replaced if need be on a per aircraft basis , but not break anything otherwise. You can replace it now on a per aircraft basis at the simple expense of setting a single property to false. If the aircraft is equipped with a better system, then that system can do so. Why is that a problem? And maybe it could be slip/skid-ball driven ... my whole point is NOT to disable it but make it configurable. Yes, them make it configurable on any aircraft you like. But it should not be absent from any aircraft you haven't touched. What he probably wants is to set --enable-auto-coordination and _not_ use the hardcoded auto-coordination but his own system. Torsten -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] auto-coordination
Curt wrote: I am sure there are very few (if any?) real life aircraft rigged in such a way. There are also very vew (if any?) real life aircraft flown by mouse :-) Altough I tend to control rudder seperately (also when flying with a mouse!), I do agree that auto-coordination should remain available. Just in case people are unaware of the actual property that was mentioned before: /sim/auto-coordination it is -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] auto-coordination
On Fri, Mar 9, 2012 at 12:57 PM, Renk Thorsten thorsten.i.r...@jyu.fi wrote: Ok I haven't entirely given up on the idea of removing the auto-coordination from the code. Why? because its hard-coded... Wouldn't it be more appropriate to add that rudder control to controls.nas? Nasal runs per graphical frame, FDMs may need to run faster at low framerates. Nasal AP systems tend to become unstable below 15 fps or so (see the F-14b). that i know all too well ... I have been here awhile ;) Then it can be replaced if need be on a per aircraft basis , but not break anything otherwise. You can replace it now on a per aircraft basis at the simple expense of setting a single property to false. If the aircraft is equipped with a better system, then that system can do so. Why is that a problem? no you cant, it's either on or off and overrides rudder control of other systems... And maybe it could be slip/skid-ball driven ... my whole point is NOT to disable it but make it configurable. Yes, them make it configurable on any aircraft you like. But it should not be absent from any aircraft you haven't touched. That's why i suggested adding it to controls.nas, so it wouldn't be absent from any aircraft ... I thought that was fairly clear.It would if it were an autopilot only function... Cheers, * Thorsten -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] auto-coordination
Am 09.03.2012 20:44, schrieb syd adams:
Ok I haven't entirely given up on the idea of removing the
auto-coordination from the code.Wouldn't it be more appropriate to add
that rudder control to controls.nas?
Then it can be replaced if need be on a per aircraft basis , but not
break anything
otherwise.And maybe it could be slip/skid-ball driven ... my whole
point is NOT to disable it but make it configurable.
Currently the rudder is set to 0.5 * aileron if autocoordination is
enabled. The value of 0.5 is hardcoded.
An easy and portable way to implement your request might be to introduce
a new property (e.g. /sim/auto-coordination-factor) with the default
value of 0.5. and change the code
if ( auto_coordination-getBoolValue() ) {
set_rudder( aileron / 2.0 );
}
to
if ( auto_coordination-getBoolValue()
auto_coordination_factor-getDoubleValue() 0.0 ) {
set_rudder( aileron * auto_coordination_factor-getDoubleValue() );
}
so that setting /sim/auto-coordination-factor to a value of zero or less
disables the hardcoded auto-coordination but leaves the command-line
argument and the enable-property usable.
Torsten
--
Virtualization Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] auto-coordination
On Fri, 9 Mar 2012, Torsten Dreyer wrote: Currently the rudder is set to 0.5 * aileron if autocoordination is enabled. The value of 0.5 is hardcoded. Perhaps this could be implemented with a property rule in preferences.xml instead of in C++ code - couldn't such a rule easily be replaced by an aircraft specific rule if needed? Cheers, Anders -- --- Anders Gidenstam WWW: http://gitorious.org/anders-hangar http://www.gidenstam.org/FlightGear/ -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] auto-coordination
Now that sounds like an even better idea.Less chance of breaking
anything , but still adjustable.Thanks Torsten.
On Fri, Mar 9, 2012 at 1:32 PM, Torsten Dreyer tors...@t3r.de wrote:
Am 09.03.2012 20:44, schrieb syd adams:
Ok I haven't entirely given up on the idea of removing the
auto-coordination from the code.Wouldn't it be more appropriate to add
that rudder control to controls.nas?
Then it can be replaced if need be on a per aircraft basis , but not
break anything
otherwise.And maybe it could be slip/skid-ball driven ... my whole
point is NOT to disable it but make it configurable.
Currently the rudder is set to 0.5 * aileron if autocoordination is
enabled. The value of 0.5 is hardcoded.
An easy and portable way to implement your request might be to introduce
a new property (e.g. /sim/auto-coordination-factor) with the default
value of 0.5. and change the code
if ( auto_coordination-getBoolValue() ) {
set_rudder( aileron / 2.0 );
}
to
if ( auto_coordination-getBoolValue()
auto_coordination_factor-getDoubleValue() 0.0 ) {
set_rudder( aileron * auto_coordination_factor-getDoubleValue() );
}
so that setting /sim/auto-coordination-factor to a value of zero or less
disables the hardcoded auto-coordination but leaves the command-line
argument and the enable-property usable.
Torsten
--
Virtualization Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
Virtualization Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] auto-coordination
On Fri, Mar 9, 2012 at 1:19 PM, Gijs de Rooy gijsr...@hotmail.com wrote: Curt wrote: I am sure there are very few (if any?) real life aircraft rigged in such a way. There are also very vew (if any?) real life aircraft flown by mouse :-) or flown looking through a monitor , using a keyboard :P Altough I tend to control rudder seperately (also when flying with a mouse!), I do agree that auto-coordination should remain available. Just in case people are unaware of the actual property that was mentioned before: /sim/auto-coordination it is -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] auto-coordination
Hmmm another thought . Wouldn't setting that value to 0.0 still force the rudder to center , still overriding other systems ? On Fri, Mar 9, 2012 at 1:39 PM, Anders Gidenstam anders-...@gidenstam.org wrote: On Fri, 9 Mar 2012, Torsten Dreyer wrote: Currently the rudder is set to 0.5 * aileron if autocoordination is enabled. The value of 0.5 is hardcoded. Perhaps this could be implemented with a property rule in preferences.xml instead of in C++ code - couldn't such a rule easily be replaced by an aircraft specific rule if needed? Cheers, Anders -- --- Anders Gidenstam WWW: http://gitorious.org/anders-hangar http://www.gidenstam.org/FlightGear/ -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] auto-coordination
Am 09.03.2012 21:46, schrieb syd adams:
Hmmm another thought . Wouldn't setting that value to 0.0 still force
the rudder to center , still overriding other systems ?
No, since Torsten's suggested patch contained a condition
auto_coordination_factor-getDoubleValue() 0.0 ) {
so nothing changes at values = 0 ;-).
cheers,
Thorsten
--
Virtualization Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] auto-coordination
ah overlooked that , thanks
On Fri, Mar 9, 2012 at 2:07 PM, ThorstenB bre...@gmail.com wrote:
Am 09.03.2012 21:46, schrieb syd adams:
Hmmm another thought . Wouldn't setting that value to 0.0 still force
the rudder to center , still overriding other systems ?
No, since Torsten's suggested patch contained a condition
auto_coordination_factor-getDoubleValue() 0.0 ) {
so nothing changes at values = 0 ;-).
cheers,
Thorsten
--
Virtualization Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
Virtualization Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] auto-coordination
Few, but at least one: http://en.wikipedia.org/wiki/ERCO_Ercoupe --Adam On Mar 9, 2012, at 12:05 PM, Curtis Olson wrote: The counter argument here is that the existing auto coordination system is nothing more than one line of code that forces some rudder deflection in proportion to aileron deflection -- basically implementing some sort of hard linked manual system. I am sure there are very few (if any?) real life aircraft rigged in such a way. Curt. On Fri, Mar 9, 2012 at 1:57 PM, Renk Thorsten wrote: Ok I haven't entirely given up on the idea of removing the auto-coordination from the code. Why? Wouldn't it be more appropriate to add that rudder control to controls.nas? Nasal runs per graphical frame, FDMs may need to run faster at low framerates. Nasal AP systems tend to become unstable below 15 fps or so (see the F-14b). Then it can be replaced if need be on a per aircraft basis , but not break anything otherwise. You can replace it now on a per aircraft basis at the simple expense of setting a single property to false. If the aircraft is equipped with a better system, then that system can do so. Why is that a problem? And maybe it could be slip/skid-ball driven ... my whole point is NOT to disable it but make it configurable. Yes, them make it configurable on any aircraft you like. But it should not be absent from any aircraft you haven't touched. Cheers, * Thorsten -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] auto-coordination
Not many aircraft are designed to be flown using a keyboard or a mouse either. ;.) The TSR2 prototype actually had a knob to allow a variable amount positive or negative rudder to be input from the roll taileron command. This auto-co-ordination may well help novice simulator “gamers” and for this reason should be available, but perhaps not set by default. It will negate the efforts of those who have made accurate FDM and AFCS systems. On the subject of novices, would it be a good idea to have an idiot-startup button or menu, which makes everything all systems go and ready to take off? Alan From: Curtis Olson Sent: Friday, March 09, 2012 8:05 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] auto-coordination The counter argument here is that the existing auto coordination system is nothing more than one line of code that forces some rudder deflection in proportion to aileron deflection -- basically implementing some sort of hard linked manual system. I am sure there are very few (if any?) real life aircraft rigged in such a way. Curt. -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] auto-coordination
On the subject of novices, would it be a good idea to have an idiot-startup button or menu, which makes everything all systems go and ready to take off? Alan Mine already have such a button , in the menu called autostart'. -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] auto-coordination
On Fri, Mar 9, 2012 at 5:58 PM, syd adams adams@gmail.com wrote: On the subject of novices, would it be a good idea to have an idiot-startup button or menu, which makes everything all systems go and ready to take off? Alan Mine already have such a button , in the menu called autostart'. I do the same on my models, following Syd's example. I think a number of others also do so. A location for such an item might be standardized, but the functionality would vary considerably, since the properties that must be set may vary widely with each aircraft. I don't mean to get too far off topic though. -Gary -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] auto-coordination
In response to the auto-coordination question, it does need to be there for users that do not have pedals or a twist stick joystick. Ideally, the autopilot should either disable auto-coordination and then restore state afterwards, if enabled by user or fly despite it. I personally think that stating that only gamers use auto-coordination is counter productive and doesn't resolve the issue. Regards George On 10 March 2012 10:11, Gary Neely grne...@gmail.com wrote: On Fri, Mar 9, 2012 at 5:58 PM, syd adams adams@gmail.com wrote: On the subject of novices, would it be a good idea to have an idiot-startup button or menu, which makes everything all systems go and ready to take off? Alan -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] auto-coordination
Hi Curt Well actually there are quite some RL aircraft having a so-called rudder-aileron interconnect. Of course in these aircraft it acts both ways: A spring (so not hard linked 1:1) pulls the rudder at aileron deflection and vice versa. The reason is however a very different one namely a lack of tendency to raise the lower wing which is a FAR requirement. This tendency is directly related to having a low enough Cl_beta (moment around the aircraft x-axis due to sideslip). More Dihedral or more sweep angle on the wing will improve the characteristic. But these things also have a decremental effect on performance, so sometimes it is better to have a bit more complex control system. The point being that in these aircraft the autopilot will have to deal with this spring also. But as it is a spring and no hard linkage, having strong enough autopilot servos will do the trick. For simulation purposes I would agree that the auto-coordination should be switched of with AP engaged. There are some complications though. What if only a HDG or NAV mode (roll servo only) is engaged? Or there is no servo on the rudder at all (which is quite common)? And from the other side what if only the yaw damper or yaw trim is active (common on multi engine aircraft)? In those cases auto coordination should remain active! So auto coordination should be switched off only when both a roll mode and yaw mode are engaged. Also it might be a good idea (for realism) to have the auto-coordination work both ways just as in RL. Cheers Eric On 03/09/2012 09:05 PM, Curtis Olson wrote: The counter argument here is that the existing auto coordination system is nothing more than one line of code that forces some rudder deflection in proportion to aileron deflection -- basically implementing some sort of hard linked manual system. I am sure there are very few (if any?) real life aircraft rigged in such a way. Curt. On Fri, Mar 9, 2012 at 1:57 PM, Renk Thorsten wrote: Ok I haven't entirely given up on the idea of removing the auto-coordination from the code. Why? Wouldn't it be more appropriate to add that rudder control to controls.nas? Nasal runs per graphical frame, FDMs may need to run faster at low framerates. Nasal AP systems tend to become unstable below 15 fps or so (see the F-14b). Then it can be replaced if need be on a per aircraft basis , but not break anything otherwise. You can replace it now on a per aircraft basis at the simple expense of setting a single property to false. If the aircraft is equipped with a better system, then that system can do so. Why is that a problem? And maybe it could be slip/skid-ball driven ... my whole point is NOT to disable it but make it configurable. Yes, them make it configurable on any aircraft you like. But it should not be absent from any aircraft you haven't touched. Cheers, * Thorsten -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net mailto:Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://aem.umn.edu/%7Euav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] auto-coordination
Hi folks, Ran into a little problem just recently. I was informed on IRC that auto-coordination broke autopilot behavior and eventually it went out of control. I admit I never thought about it before , I've never used it , even with a mouse as my only controller . I could add a check every time autopilot is engaged to disable it while autopilot is active , but my real question is , can it be removed from the code ? It consists of three lines in flightgear/src/Aircraft/controls.cxx , but it seems that this should be handled by the autopilot system. Any thoughts ? Cheers -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] auto-coordination
Hi Syd, That was a hack from the very early days of the project, so if it went away, it wouldn't bother me. Fred might have a check box in the window launcher, and there may be a command line option or property value to hunt down and remove. Curt On Thursday, March 8, 2012, syd adams wrote: Hi folks, Ran into a little problem just recently. I was informed on IRC that auto-coordination broke autopilot behavior and eventually it went out of control. I admit I never thought about it before , I've never used it , even with a mouse as my only controller . I could add a check every time autopilot is engaged to disable it while autopilot is active , but my real question is , can it be removed from the code ? It consists of three lines in flightgear/src/Aircraft/controls.cxx , but it seems that this should be handled by the autopilot system. Any thoughts ? Cheers -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] auto-coordination
On Thu, Mar 8, 2012 at 10:19 PM, Curtis Olson curtol...@gmail.com wrote: Hi Syd, That was a hack from the very early days of the project, so if it went away, it wouldn't bother me. Fred might have a check box in the window launcher, and there may be a command line option or property value to hunt down and remove. Curt Thanks , Curt. Actually I'd prefer the auto-coordination property to remain , and the options to enable it too , just that it be handled in an autopilot file rather than hard-coded. I've added a sort of auto coordination to the R22 below a certain airspeed, otherwise I cant get it off the ground no matter how fast I tap those rudder keys , and enabling auto-coordination would be a easier in these situations, i think. At least for those of us without rudder pedals. It would mean more work for aircraft designers , but a simple filter should easily do what the code does. Syd -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] auto-coordination
I could add a check every time autopilot is engaged to disable it while autopilot is active , but my real question is , can it be removed from the code ? It consists of three lines in flightgear/src/Aircraft/controls.cxx , but it seems that this should be handled by the autopilot system. Being a mouse pilot, I'm using auto-coordination... My understanding is that the AP system is quite different from airplane to airplane, and not all planes have a working AP at all, so if you remove auto coordination from the code, then I end up not having it in most of the planes. Sounds like a bad idea to me. auto-coordination is runtime property controlled - if it interferes with you AP, it should be a one-liner to de-activate it whenever AP is engaged and a three liner to reset it to the state it was before when AP is disengaged. What's the problem with that approach? * Thorsten -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
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
[Flightgear-devel] auto-coordination broken
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. 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. This is one of approximately 62 bugs listed at http://www.av8n.com/fly/fgfs/htm/bug-list.htm If anybody knows of anything that should be added, removed, or changed on that list, please let me know. -- 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
