Re: [Flightgear-devel] Autopilot planning [was RE: progress]
On Friday, June 14, 2002, at 04:19 am, Jim Wilson wrote: Armed vs. Active modes: Active modes are the only ones that affect control surfaces. Armed modes select an impending active mode that may or may not get triggered, depending on if the condition for that mode is satisfied. Note that if you have armed for a higher altitude but have the aircraft set maintain pitch down, you will continue to descend and never trigger the armed altitude hold mode. Note that often a flight computer can ensure that an armed mode is reachable by coordinating multiple settings, but the autopilot by itself does not guarantee this. Okay, this sounds fine. c. Heading Select (HDG-SEL) uses ailerons to turn toward heading bug (or setting from FMC). Switches to active Heading Hold when target reached. Changing heading bug after Heading Hold is active requires initiating HDG-SEL again (won't automatically go there like it does now). This needs to be configurable, most HDG modes I've 'used' on big jets remain live, i.e if you spin the heading bug, they track immediately. It's possible there is a ALT mode out there that does the same thing (though that would be pretty crazy, I admit) d. Heading NAV Arm (HDG-NAV1-ARM, HDG-NAV2-ARM) Maintain HDG (Heading Hold) or Wing Leveler (WL) until radial is intercepted. Upon interception, automatically switch to active HDG-NAV1 or HDG-NAV2. Note that on ILS this will be synonymous with APR ARM and APR mode which will also arm for GS. The intercept conditions need to be programmable. Also, the mode may not engage at all based on criteria in some systems. Example: the 777's NAV mode will not engage if the CDI is greater than some value (2nm?) *and* the current heading it not an intercept. (at least, according to the simulation I have used) AXIS 2) Vertical control modes: look fine AXIS 3) Yaw damper: I am anxious that this be a totally separate system from the autopilot, it's a very independent system apart from the fact it drives control surfaces and the switch is usually on the MCP :-) If we ever go as far as systems modeling at the block level, that's especially the case (yaw dampers usually have separate gyros, and sometimes separate inputs to the control surface actuator servos) Engage: Upon engagement the autopilot will begin processing any preselected modes (limited to one Arm and one Active mode per axis at a time). If no mode is preselected then vertical will default to PITCH and lateral will default to HDG-HLD. It may be desirable to have these defaults configurable, since some autopilots may default to either ALT HLD for vertical or WL for lateral. Definitely. Also note that we're going to need some ability to reject engagement of modes altogether, so there is really a multi-stage set of the conditions for each mode: - conditions to arm the mode - conditions to activate the mode - conditions to transition to another mode (largely an FMC problem, but it does interact I suspect) The autopilot will be able to disengage. Certain conditions will require it. Suggestions on how to specify conditions would be welcome. Note that the current autopilot will reduce pitch to prevent a stall (as min climb is approached). I believe that the more correct behavior would be to disengage once airspeed reaches a certain minimum. Some aircraft have other automated stall prevention measures (e.g. automatic nose dropping on aircraft that are incapable of stall recovery), but those involve separate systems that go beyond the scope of typical autopilot functionality. Actually, I believe some auto-pilots will just 'kill you' in this situation :-) So it needs to be configurable for certain. Notes: The current autopilot supports some degree of throttle control...not sure if this should be included or if it belongs in a separate class. In any case thrust control gets involved with some aircraft. I would prefer a separate class, as you say, this can get quite involved. A variety of flight management modes should be configurable with these basic autopilot functions. For example if the Boeing FL CH mode is selected on an FMC then the FMC can command the autopilot for ALT ARM and SPD, and until a thrust computer class is developed, set the throttle controls with an approximation for throttle in climb or descent mode. Yup, all sounds rather plausible., This is the second time I've outlined autopilot functions, but what I'm striving for here is to actually outline how the class methods will be constructed, and the way that the modes will interact. Now is the time to set me straight if something doesn't look right, or looks too inflexible :-) This looks like 90% of what we need (i.e, I can't see anything missing, but we haven't built it yet :-) HH James -- What I like about deadlines is the lovely whooshing sound they make as they rush past. -- Douglas Adams
RE: [Flightgear-devel] Autopilot planning [was RE: progress]
AXIS 3) Yaw damper: I am anxious that this be a totally separate system from the autopilot, it's a very independent system apart from the fact it drives control surfaces and the switch is usually on the MCP :-) If we ever go as far as systems modeling at the block level, that's especially the case (yaw dampers usually have separate gyros, and sometimes separate inputs to the control surface actuator servos) Modeling at the block level is something I am very interested in. Eventually, I'll be modeling the autopilot of a military jet as a test. JSBSim has building blocks for flight control system elements such as filters, summers, etc. I need to finish up the switch component, first, and then we ought to be all set. We fully model the X-15 S.A.S. and it works. We can model any filter up to second order, now (washout, integrator, structural, lag, lead-lag, etc.) using the Tustin substitution. We have scheduled gains, too. We'll need to figure a way to let the autopilot present in JSBSim be used instead of one inherent in FlightGear, if we have one for our aircraft model. One might say that it's pointless to build one in JSBSim if there is already one in FlightGear - which I might agree with except that JSBSim is used by several other projects that do or might have use for such a feature, and we also want JSBSim to have an autopilot capability for standalone test. Eventually, I'd like to be able to script certain guidance features to test ascent guidance principles. But, the ability to model an autopilot in a config file as a block diagram representation is definitely good - and one that interests some in NASA, as well. Using this approach we can specify an autopilot in the config file for JSBSim. For more information, see: http://jsbsim.sourceforge.net/JSBSimCUJ.PDF API Documentation (preliminary): http://jsbsim.sourceforge.net/JSBSim/FGFCS.html http://jsbsim.sourceforge.net/JSBSim/FGFCSComponent.html http://jsbsim.sourceforge.net/JSBSim/FGFilter.html http://jsbsim.sourceforge.net/JSBSim/FGSummer.html Jon Jon S. Berndt Coordinator, JSBSim Project http://jsbsim.sf.net smime.p7s Description: application/pkcs7-signature
Re: [Flightgear-devel] Autopilot planning [was RE: progress]
James Turner [EMAIL PROTECTED] said: c. Heading Select (HDG-SEL) uses ailerons to turn toward heading bug (or setting from FMC). Switches to active Heading Hold when target reached. Changing heading bug after Heading Hold is active requires initiating HDG-SEL again (won't automatically go there like it does now). This needs to be configurable, most HDG modes I've 'used' on big jets remain live, i.e if you spin the heading bug, they track immediately. It's possible there is a ALT mode out there that does the same thing (though that would be pretty crazy, I admit) Ok I'll probably do that with HDG for now. d. Heading NAV Arm (HDG-NAV1-ARM, HDG-NAV2-ARM) Maintain HDG (Heading Hold) or Wing Leveler (WL) until radial is intercepted. Upon interception, automatically switch to active HDG-NAV1 or HDG-NAV2. Note that on ILS this will be synonymous with APR ARM and APR mode which will also arm for GS. The intercept conditions need to be programmable. Also, the mode may not engage at all based on criteria in some systems. Example: the 777's NAV mode will not engage if the CDI is greater than some value (2nm?) *and* the current heading it not an intercept. (at least, according to the simulation I have used) We can tweak for that. My goal at this point is to change the way the current autopilot blindly switches to 30degrees off the radial in order to create an interception. AXIS 2) Vertical control modes: look fine AXIS 3) Yaw damper: I am anxious that this be a totally separate system from the autopilot, it's a very independent system apart from the fact it drives control surfaces and the switch is usually on the MCP :-) If we ever go as far as systems modeling at the block level, that's especially the case (yaw dampers usually have separate gyros, and sometimes separate inputs to the control surface actuator servos) It is and it isn't a seperate system. If I'm not mistaken it is controlled by the autopilot on most aircraft. But probably doesn't have anything to do with the flight computer. It is engaged seperately and runs without any of the ap modes engaged. As I said, for now it'll just be simplistic using the current method of coordinating with aileron movements (and therefore only active when autopilot is engaged). Engage: Upon engagement the autopilot will begin processing any preselected modes (limited to one Arm and one Active mode per axis at a time). If no mode is preselected then vertical will default to PITCH and lateral will default to HDG-HLD. It may be desirable to have these defaults configurable, since some autopilots may default to either ALT HLD for vertical or WL for lateral. Definitely. Also note that we're going to need some ability to reject engagement of modes altogether, so there is really a multi-stage set of the conditions for each mode: Well the only condition that I'm aware of is some ga autopilots won't engage during flight if TEST mode was not run on the ground :-). I believe it is up to the flight computer to calculate more complex conditions. Of course if there are disengage conditions then the effect would be the same. Also, implictly there can only be one Active and one Arm mode for each axis (doesn't need to be configurable). - conditions to transition to another mode (largely an FMC problem, but it does interact I suspect) Arm modes implicitly have a transition which will be defined. The FMC would handle more complex transitions such as those run during LAND modes. The autopilot will be able to disengage. Certain conditions will require it. Suggestions on how to specify conditions would be welcome. Note that the current autopilot will reduce pitch to prevent a stall (as min climb is approached). I believe that the more correct behavior would be to disengage once airspeed reaches a certain minimum. Some aircraft have other automated stall prevention measures (e.g. automatic nose dropping on aircraft that are incapable of stall recovery), but those involve separate systems that go beyond the scope of typical autopilot functionality. Actually, I believe some auto-pilots will just 'kill you' in this situation :-) So it needs to be configurable for certain. That's right. First pass on this, that's probably what'll happen. But it is something to keep in mind. On the aircraft with some sort of automatic stall prevention, it is separate from the autopilot (could even be a mechanical device on the wings...that makes the nose drop before stall is achieved). Point is it works regardless of who or what is at the controls. This looks like 90% of what we need (i.e, I can't see anything missing, but we haven't built it yet :-) Yeah but it looks good :-D I've started layout out the class definition and hope to have at least the lateral working next week. Shouldn't take all that long to finish. Best, Jim
[Flightgear-devel] failed to untie property w. --aircraft-id=a4-yasim +CVS question
Hi, am trying to use the new a4-sound.xml file, but when I start fsgs with --aircraft-id=a4-yasim, I get the following errors: CG: -6.1, -0.0, 0.5 Failed to untie property /consumables/fuel/tank[0]/level-gal_us Failed to untie property /consumables/fuel/tank[1]/level-gal_us Failed to untie property /engines/engine[0]/fuel-flow-gph Failed to untie property /engines/engine[0]/rpm Failed to untie property /engines/engine[0]/mp-osi Failed to untie property /engines/engine[0]/egt-degf This hangs my CLI (until I kill fsgs process). Didn't save the orginal XML file so I don't know if this problem is related to the new on. FG question: did I not install something necessary for the a4? Can I extract just the original a4-sound.xml file using cvs? what is the command syntax to do this pls? thanks! CVS question: can I extract all flightgear files (cvs -z3 checkout flightgear) and then tell cvs to extract specific files or directories so that any modifications previously made are overwritten/ignored? I don't want to blast makefiles or such I might have modified but might want to overwrite just src/flightgear/src/main for example. thanks! I know that I could delete the changed files (the cvs log shows M by them), but I'm hoping that there's an easier way. Ima ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] failed to untie property w. --aircraft-id=a4-yasim +CVS question
ima sudonim writes: Hi, am trying to use the new a4-sound.xml file, but when I start fsgs with --aircraft-id=a4-yasim, I get the following errors: CG: -6.1, -0.0, 0.5 Failed to untie property /consumables/fuel/tank[0]/level-gal_us Failed to untie property /consumables/fuel/tank[1]/level-gal_us Failed to untie property /engines/engine[0]/fuel-flow-gph Failed to untie property /engines/engine[0]/rpm Failed to untie property /engines/engine[0]/mp-osi Failed to untie property /engines/engine[0]/egt-degf This hangs my CLI (until I kill fsgs process). Didn't save the orginal XML file so I don't know if this problem is related to the new on. Hmmm, at the moment I can't get any of the yasim models to work. They all come up at lon=0, lat=0 and refuse to run. FG question: did I not install something necessary for the a4? Can I extract just the original a4-sound.xml file using cvs? what is the command syntax to do this pls? thanks! I don't think this is a problem with a4-sound.xml ... CVS question: can I extract all flightgear files (cvs -z3 checkout flightgear) and then tell cvs to extract specific files or directories so that any modifications previously made are overwritten/ignored? I don't want to blast makefiles or such I might have modified but might want to overwrite just src/flightgear/src/main for example. thanks! I know that I could delete the changed files (the cvs log shows M by them), but I'm hoping that there's an easier way. I believe you can check out a version from the repository as of a specific date (or all the versions with a specific tag, we tag releases.) YASim has had code changes in the last 2,3,4 days so perhaps something broke? (Hopefully it's not me that's doing something stupid.) :-) Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: failed to untie property w. --aircraft-id=a4-yasim +CVS question
* Curtis L. Olson -- Friday 14 June 2002 17:22: YASim has had code changes in the last 2,3,4 days so perhaps something broke? (Hopefully it's not me that's doing something stupid.) :-) 'Bad' news: Yasim works for me with CVS HEAD from one or two hours ago. I just flew the dc3 from LOXL to LOXT (and crashed there ;-). I tried the a4 before and it worked, too. m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: failed to untie property w. --aircraft-id=a4-yasim +CVS question
Melchior FRANZ writes: * Curtis L. Olson -- Friday 14 June 2002 17:22: YASim has had code changes in the last 2,3,4 days so perhaps something broke? (Hopefully it's not me that's doing something stupid.) :-) 'Bad' news: Yasim works for me with CVS HEAD from one or two hours ago. I just flew the dc3 from LOXL to LOXT (and crashed there ;-). I tried the a4 before and it worked, too. I wonder if the recent change preferences.xml has broken everything? Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: failed to untie property w. --aircraft-id=a4-yasim +CVS question
* Curtis L. Olson -- Friday 14 June 2002 17:36: I wonder if the recent change preferences.xml has broken everything? Yes, indeed. I updated preferences.xml and now fgfs starts but it hangs high up in the air at lon=lat=0.0. I'll downgrade again ... :-) m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] preferences.xml
David, Jim, I think we need to back out (or fix) the recent change to preferences.xml. You come up with a view at lat=0, lon=0 and the fdm isn't able to initialize because the tiles for the aircraft starting position are never loaded (we need theses can seed the fdm init with starting terrain height.) Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: failed to untie property w. --aircraft-id=a4-yasim +CVS question
Failed to untie property /consumables/fuel/tank[0]/level-gal_us Failed to untie property /consumables/fuel/tank[1]/level-gal_us [...] haven't seen these FG question: did I not install something necessary for the a4? Can I extract just the original a4-sound.xml file using cvs? what is the command syntax to do this pls? thanks! If you have the base package from CVS (which I assume) you can easily check out whatever version you like without touching existing files: $ cvs co -r1.50 -p preferences.xml-1.50 You can, of course, also update to the latest version (cvs up) and later go back to any particular version (cvs up -r1.50) or a particular date (cvs up -D 1 week ago) etc. If you don't have the base package yet, you can check out the outmost level only and then work through the directories level for level, so that you don't have to check out the whole package at once: $ cvs -d:pserver:[EMAIL PROTECTED]:/home/cvsroot login $ cvs -d:pserver:[EMAIL PROTECTED]:/home/cvsroot co -l ... CVS question: can I extract all flightgear files (cvs -z3 checkout flightgear) and then tell cvs to extract specific files or directories so that any modifications previously made are overwritten/ignored? Don't know what exactly you want, but yes. You can do almost everything with cvs. :-) I don't want to blast makefiles or such I might have modified but might want to overwrite just src/flightgear/src/main for example. thanks! Makefiles aren't in CVS anyway. If I want anything like that, I simply duplicate the whole cvs directory, and then I only keep one up-to-date and leave the other one alone. I can still update specific files or simply copy them between the working dir and the local 'mirror'. m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: failed to untie property w. --aircraft-id=a4-yasim+CVS question
Curtis L. Olson wrote: Melchior FRANZ writes: Curtis L. Olson wrote: YASim has had code changes in the last 2,3,4 days so perhaps something broke? (Hopefully it's not me that's doing something stupid.) :-) 'Bad' news: Yasim works for me with CVS HEAD from one or two hours ago. I just flew the dc3 from LOXL to LOXT (and crashed there ;-). I tried the a4 before and it worked, too. I wonder if the recent change preferences.xml has broken everything? Phew. Not my fault this time. :) To address the original subject, those failed to untie messages are just benign warnings. What used to happen is that a lot of the FDM output was tied to properties outside the FDM. In particular, the first and second engines would automatically result in property output; but the third and higher ones wouldn't. Rather than write two code paths to deal with the issue, I just threw up my hands, untied the things, and did it all manually. Since then, I believe most of these limitations have gone away, but the fgUntie() calls are still there. When called on untied properties, they generate a warning. I need to take a look and verify that this code can be snipped, and eliminate it. Not a lot of work, just tedious. The relevent unties are in YASim::bind(), if someone wants to, heh, do it for me. :) Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] joystick not seen on macos x
I am using macos 10.1.5 and a saitek x45 usb joystick. The joystick is getting power (lights up), but neither fgfs joystick tool (fgjs or js_demo) sees it nor does fgfs when it starts up. How does one set up a joystick on macos to work with flightgear? I've read the faq and the joystick support page but they don't mention mac os x Barring that, how can I use a mouse to climb, etc. Under macos 9, there was a delay problem with this joystick of two seconds or more, but it doesn't look like os x or flightgear are seeing it at all. Anyone familiar with human interface device setup on mac os x or BSD that can advice? TIA Ima ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] joystick not seen on macos x
I'm a pseudonym wrote: I am using macos 10.1.5 and a saitek x45 usb joystick. The joystick is getting power (lights up), but neither fgfs joystick tool (fgjs or js_demo) sees it nor does fgfs when it starts up. How does one set up a joystick on macos to work with flightgear? Have you verified that the joystick actually works with Mac OS X? I have one of these controllers (which are otherwise fantastic gadgets), and under Linux it requires a special parameter to be set when the kernel module is compiled. Apparently, they respond too slowly to be considered compliant USB devices; the tweak increases the driver timeout delay. Saitek ships a custom windows driver that presumably does the same thing. They actually have a big yellow sticker on the plug warning you not to plug it in without installing the driver first. If you do, windows will (apparently) detect it incorrectly as a normal HID device and never be able to recover to the correct driver without a reinstall long tirade elided Can you use the joystick correctly in other Mac applications? Beyond that, I know squat about the Mac or BSD USB subsystems; sorry. :) Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: failed to untie property w. --aircraft-id=a4-yasim +CVS question
* Melchior FRANZ -- Friday 14 June 2002 18:10: If you have the base package from CVS (which I assume) you can easily check out whatever version you like without touching existing files: $ cvs co -r1.50 -p preferences.xml-1.50 ^^ Should be cvs up ... m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: failed to untie property w. --aircraft-id=a4-yasim +CVS question
I wonder if the recent change preferences.xml has broken everything? Yes it did. I'll take a look at it. I suspect that David has some other customizations in there, besides the view change. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: failed to untie property w. --aircraft-id=a4-yasim +CVS question
Jim Wilson [EMAIL PROTECTED] writes: I wonder if the recent change preferences.xml has broken everything? Yes it did. I'll take a look at it. I suspect that David has some other customizations in there, besides the view change. i downgraded to version 1.58 of preferences.xml and fgfs is working again. the only difference _is_ the view change: diff -u -r1.59 -r1.58 --- preferences.xml 2002/06/14 14:51:27 1.59 +++ preferences.xml 2002/06/05 22:23:03 1.58 @@ -32,27 +32,6 @@ current-view field-of-view type=double55.0/field-of-view /current-view - view n=1 -nameChase View/name -typelookat/type -config - from-model type=boolfalse/from-model - from-model-idx type=int0/from-model-idx - eye-lat-deg-path/position/latitude-deg/eye-lat-deg-path - eye-lon-deg-path/position/longitude-deg/eye-lon-deg-path - eye-alt-ft-path/position/altitude-ft/eye-alt-ft-path - eye-heading-deg-path/orientation/heading-deg/eye-heading-deg-path - - at-model type=booltrue/at-model - at-model-idx type=int0/at-model-idx - - ground-level-nearplane-m type=double0.5f/ground-level-nearplane-m - - x-offset-m type=double0/x-offset-m - y-offset-m type=double0/y-offset-m - z-offset-m type=double-25/z-offset-m -/config - /view panel pathAircraft/c172/Panels/c172-vfr-panel.xml/path visibility type=boolfalse/visibility --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] joystick not seen on macos x
Andy Ross [EMAIL PROTECTED] said: long tirade elided Would have been aimed at Saitek I presume for selling a USB device that ummm... isn't? ;-) Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] joystick not seen on mac os X
I'm a pseudonym wrote: I am using macos 10.1.5 and a saitek x45 usb joystick. The joystick is getting power (lights up), but neither fgfs joystick tool (fgjs or js_demo) sees it nor does fgfs when it starts up. How does one set up a joystick on macos to work with flightgear? Have you verified that the joystick actually works with Mac OS X? I have one of these controllers (which are otherwise fantastic gadgets), and under Linux it requires a special parameter to be set when the kernel module is compiled. Apparently, they respond too slowly to be considered compliant USB devices; the tweak increases the driver timeout delay. Saitek ships a custom windows driver that presumably does the same thing. They actually have a big yellow sticker on the plug warning you not to plug it in without installing the driver first. If you do, windows will (apparently) detect it incorrectly as a normal HID device and never be able to recover to the correct driver without a reinstall long tirade elided Yeah, saitek claims mac compatibility on the box, but doesn't give any drivers. They say it's apple's problem. The apple support reps just think that Saitek's nuts. I'll see if I can get 10.2 if and when it's out to see if that helps. Can you use the joystick correctly in other Mac applications? Beyond that, I know squat about the Mac or BSD USB subsystems; sorry. :) No, doesn't work at all. Not even in XPlane under X, where at least under macos 9 it was recognized. I'm not sure if os X's usb support is working nor how to test it. Tia, Ima Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] preferences.xml
Curtis L. Olson [EMAIL PROTECTED] said: David, Jim, I think we need to back out (or fix) the recent change to preferences.xml. You come up with a view at lat=0, lon=0 and the fdm isn't able to initialize because the tiles for the aircraft starting position are never loaded (we need theses can seed the fdm init with starting terrain height.) Regards, Curt. This has been fixed. It was a weird effect considering the change. And for some reason the dc3 would initialize, but the time was way off (night when it should have been day). Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] My First Solo
embarassing Uggh...I give up :-) Just use the spanish version of the word which is much easier to spell, that would be what, probably embarasada, right? No, embarasada means pregnant... You probably want to say embarazoso. []'s Marcio Shimoda ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] YASim flaps finally working (?)
I believe I've (finally) nailed the flap drag bug in YASim. A good amount of thought, some work with pencil and paper, and a (IMNSHO) damn clever application of the small angle approximation worked quite well. The code changes were actually very modest and well-contained; no machetes necessary. I think I also found what might have been causing the weird divergence bug that some people reported (although I haven't succeeded in reproducing it myself). For flaps with very high lift numbers and at very high negative AoA's, it was possible to get the wing to essentially have a negative drag. The aircraft would then get free acceleration, although this should still have been a plausibly small number, and not an explosion. Anyway, it's fixed. If someone sees the divergence happen again, please tell me right away. I test-flew the planes for at least one approach each, but clearly more trials are needed. Grab new code from CVS and new planes from fgfsbase and give your favorite YASim plane a whirl. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
