On Tue, Dec 22, 2009 at 8:10 AM, James Turner 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. >
With the old route manager, the first way point is where I want to go for my first destination, because I just put it in there with that specific goal in mind. The 2nd waypoint is also where I want my second destination to be, again, because I just put it there. Same for all the other way points. Another nice feature we used to have in the original route manager was the ability to insert and delete waypoints from the middle of the route, allow us to update and change the route in mid-flight if we changed or mind (or something like weather changed it for us.) What I liked about the old route manager is I could decide I want to fly to A then B then C then D, I added those waypoints and off I go. I feel like I have to fight the new system to get it to do something like that, and then every time I open up the dialog box, I'm never sure if it's going to change the route on me or add the original airport back in again (even if it might already be there.) I haven't tried using the route manager in a few weeks now, so perhaps some of these things were bugs that are now resolved. I think there was a simplicity and a determinism in the original system (as unrealistic as that was) and I struggle with the new system trying to understand how to get it to work and not make unexpected changes or additions to the route. > That's really an orthogonal issue - I only use the airport location if you > neglect to specify a runway. Ok, for the original route manager when you specified an airport as a waypoint, you got this computed center point (average or runway center points.) > 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. > Right ... I've always flown with the mindset of the route manager getting me to the airport and then at some point I'll break off the route and setup the approach to my own chosen runway and land manually. > 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? > The alphajet has it's own autopilot configuration. I wouldn't characterize it as "generic" since it is specific for this aircraft. Perhaps some of the gains could be tweaked, but it behaves pretty well for me. One thing to note is that many YASim jet aircraft can be over speeded at lower altitudes and if you do that, you can get really weird negative stall type effects ... especially if you have flaps deployed. This has always been a gripe of mine with the YAsim flight dynamics engine. Generic autopilots are difficult. Different aircraft have wildly different systems and capabilities. Different types of sensors, actuators, etc. A generic autopilot would be about as realistic as our original route manager. :-) And then stuffing in about 50-60 tunable parameters into a generic structure also sounds pretty messy. I've always preferred the autopilot to be defined on a per-aircraft basis, and if the aircraft author wants to copy a config file from another similar aircraft as a starting point, that's fine. 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
