On 21 Dec 2009, at 18:55, Curtis Olson wrote: > What do you think would be a sensible course of action, in the situation you > describe? Even if I choose not to add the departure airport for in-air route > activation, there's no guarantee that the first route waypoint is where you > actually want to be going. > > Conceptually, including the starting point in the route seems like it could > always be problematic. The "airport location" is some random point on the > airport grounds (probably the average of the center points of the runways.) > Even if you haven't taken off yet, it would be possible in some circumstances > to not fly close to the center of the airport on take off. Then you would > get routed back to the starting point before you could continue on to the > next way point. I think we are just getting "lucky" when we fly close enough > to the center of the airport in most situations for most runways to satisfy > the route manager and it clicks on to the next waypoint. The KSFO airport > layout is very friendly in this regards, but other airports like DFW and DEN > are more sprawling.
That's really an orthogonal issue - I only use the airport location if you neglect to specify a runway. For using these features as a flight planning tool, the first waypoint is my departure runway, which sequences when you cross the threshold / midpoint (not perfectly, I have a known bug to fix in that area). Adding the *destination* airport as a waypt seems useful, even if no runway is selected, because it yields a useful trip distance estimate (and hence, ETA), and I assume people can thus navigate to the vicinity of their destination, and conduct whatever kind of approach they like. A few things that will certainly help: - not adding the departure airport if no runway is selected - not adding the departure airport for an in-air route activation I'll do these today (hopefully) - I already fixed the GPS -> autopilot drive, and have been doing some reading and testing with the generic autopilot XML, dialog and code. There's quite a few things behaving strangely (especially in the Alphajet), and I don't think most of them are my fault - famous last words! - but I'm getting to grips with it. Will post back here once I have some more definite conclusions, especially regarding why heading hold is being so strange. Incidentally, the PID parameters in the generic autopilot are pretty bad for the alphajet (and many other aircraft, I guess). It'd be lovely if there was a way to tune the response rates for a particular aircraft, but still inherit the basic controller structure (i.e the control laws) from the generic definition. I don't suppose the Autopilot XML loading code could cope with that? 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
