On Monday, June 10, 2002, at 05:35 am, John Wojnaroski wrote:
> Well, I've been working on a Multi-function Control Display Unit (MCDU) > which connects to the FMC and > provides manual control of the nav receivers and other aircraft systems. > Next major effort is adding ability to > insert and edit waypoints and do some flight testing of the LNAV and > VNAV. Hmm, this is going to get fiddly. I've got a generic route/flight-plan backend sort of working (no flight traversal or waypoint sequencing as of yet), which I am planning to extend with airways, SIDs, STARs and so on (with editing of course). The long term plan was to build an FMC / MCDU / GPS on top of this, but it seems like you're a good way ahead of me. And of course this is built into flightGear so that it can access the exiting Navaids, fixes and runway data. > The not-so-good-news --- it runs as a single opengl app (I've got my > copy > running on a laptop) and uses the SimGear library socket functions. (You > need 3 networked machines, but you do get the *whole enchilada*) > A full complement of flight deck displays (OpenGC), a multi-function > control > unit (MCDU), a flight dynamics model > and scenery(FlightGear). I was assuming long-term I'd setup an /fms node in the property tree, with a flightplan [fp?] child containing the waypoints of the active route (with a few other fp slots for secondary and temporary routes, of course), and that would be enough data to generate a reasonably complete and accurate Boeing / Airbus style NAV display, or the list / visual display of any smaller GPS unit (KLN-89b, for example). However, this is some way off (I want to get the flight-plans hooked up to the existing auto-pilot code, which isn't really designed to look like a 'big jet' model of course, though it seems you already have code *somewhere* that handles LNAv and VNAV functions... hmm. I'm not sure the best way to proceed. I really think the auto-pilot code belongs in flight-gear, but the goal of having the FMC / MCDU run separately is valuable. There's a lot of navigation data the FMC/MCDU needs that is simulator specific though : does your code have it's own copy or what? Also, people who just want an in-cockpit GPS unit definitely don't want a separate machine to run it on. One solution I've contemplated (but which I suspect is unworkable) is something like an NFS-mount for the property tree: i.e run the FMC/MCDU as a property 'server', and have every node it exports be located under /fms in the global tree. This would probably get inefficient and / or too complicated in short order though. Anyway, I'd like to work out a plan of attack to avoid too much duplication. I suspect some might be inevitable, since there's slight different goals. (and, alas, I only have one computer, so I'm kind of anti the whole 3 computers thing :-) H&H James -- Anyone who considers arithmetical methods of producing random digits is, of course, in a state of sin. -- John Von Neumann, 1951 _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
