[Flightgear-devel] Re: GPS/Autopilot
On Wed, 30 Nov 2005 21:27:15 -0600, you wrote: aircraft (like GPS in MSFS). Given that the wiring can be potentially different with each aircraft, the autopilot code may need customizing each time it is placed on a panel. Ideally the instruments will be as multi-usable as possible, and nasal is probably ideal to do the plumbing. But the more complex the systems we are modelling, inevitably the more complex the sim integration will become. Let me know what you need exported from the GPS and I'll try to oblige (but bear in mind I sometimes can't get online for a few days at a time). BTW, can you remind me again where I can download your autopilot from. http://www.city-gallery.com/vpilot/flightgear/ I've stopped work on it until I learn the new electrical system. I do not need any code from the GPS. I need to know the properties it uses. The digitrak can accept a GPS data signal. It can even work off a Garmin 35, which is a GPS built in to an antenna that just provides ground track and speed. I do not pretend to know how they communicate, but there is no equivalent to a data connection in FlightGear GPS, I have to watch properties in the GPS. If you look at digitrak.nas, it uses properties from /instrumentation/gps/ to maintain GPS track. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: GPS
On Wed, 30 Nov 2005 00:49:14 -0600, you wrote: I've added a KLN89 GPS unit hardcoded in C++ (OK'd by Curt). Briefly, since it's late, it's only included on the c172p 2D panel (--aircraft=c172p-2dpanel). It looks best at --geometry=1024x768 since the fonts are at 1:1 pixellation at that resolution. Now that we are seeing a choice of GPS units, it beings to raise a similar question to the autopilot. There will be confusion over the waypoint and gps dialogs on the FG toolbar. It may be necessary to do something similar as I proposed with autopilot. The approach I took to integrating GPS into my autopilot was to rely on the existing built-in GPS. I assume this is a C coded model of a generic GPS unit. It raises the issue of should instrument autopilots (that ones that appear in the cockpit) all use the same model and put a different face on them or should there be any number of gps units available? If there are many gps units coded in C, it might be wise to remove the generic one. However, then those who might want to build a GPS model based on the generic gps using NASAL might be out of luck (I'm not sure if it is possible or reasonable to implement a moving map GPS display in NASAL and instrument XML, however, a simple text display might be feasible). The autopilot I modeled is tightly integrated with a GPS unit. It needs to access GPS properties. However, this means that if there are more than one gps unit available in FG, the autopilot code must be changed to use the properties of the particular autopilot. That may not be too great an issue if instruments are supplied with particular aircraft as opposed to something generic that can be placed in any aircraft (like GPS in MSFS). Given that the wiring can be potentially different with each aircraft, the autopilot code may need customizing each time it is placed on a panel. It is nice to have a true gps unit and I have intended all along to wire my autopilot into the first good model that came along. The built-in gps is fairly primitive with no panel representation. This is just to air these issues, I do not have any conclusions. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: GPS
Steve Knoblock wrote: I'm not sure if it is possible or reasonable to implement a moving map GPS display in NASAL and instrument XML, however, a simple text display might be feasible. Probably not, but you might still want to script some of the functionality -- especially for complicated avionics that interact with other aircraft systems. You'll want to stay away from actual graphics/rendering in Nasal, obviously, but everything else is fair game. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: GPS
Steve Knoblock writes: Now that we are seeing a choice of GPS units, it beings to raise a similar question to the autopilot. There will be confusion over the waypoint and gps dialogs on the FG toolbar. It may be necessary to do something similar as I proposed with autopilot. Yes, I agree absolutely. The currently situation of a totally non-functioning menu entry simply confuses users. I guess that in the short term we should grey them out if non-functional, and in the longer term they should be an alternative interface to the instrument than the panel representation, since we work within the constraints of simulating the real world on a small screen, and sometimes real-world-style instrument use is simply hard to do during simulation. In this case, the dialogs might need customising slightly for each unit, although for the GPS that might be simply a case of the maximum number of flightplans allowed, or the maximum number of waypoints per flightplan, since fundamentally their operation is probably more similar between units than autopilots. The approach I took to integrating GPS into my autopilot was to rely on the existing built-in GPS. I assume this is a C coded model of a generic GPS unit. It raises the issue of should instrument autopilots (that ones that appear in the cockpit) all use the same model and put a different face on them or should there be any number of gps units available? If there are many gps units coded in C, it might be wise to remove the generic one. However, then those who might want to build a GPS model based on the generic gps using NASAL might be out of luck (I'm not sure if it is possible or reasonable to implement a moving map GPS display in NASAL and instrument XML, however, a simple text display might be feasible). There's absolutely no reason to remove the generic one. Indeed, the KLN89 unit uses the output from the generic unit. Fundamentally, everything in src/Instrumentation/KLN89 is only a simulation of an avionics user interface (albeit an extremely complex one). Src/Instrumentation/gps.[ch]xx (should I capitalise lower-case directory names when they start a sentence?) as it currently stands (unaltered by me) is simply an export to the property tree of position, to/from flag between 2 waypoints, and various other positional/speed/track related quantities. In the middle I have added src/Instrumentation/dclgps.[ch]xx, which adds more advanced capabilities than gps.[ch]xx, such as waypoint sequencing during flightplan operation, cdi needle deflection calculation, approach mode sequencing during non-precision approaches, great circle distance calculations, stuff like that. Currently none of this is exported to the property tree. However, this is not how it is intended to remain. All the complex GPS stuff in dclgps.[ch]xx should move to gps.[ch]xx and be exported to the property tree, for the benifit of non C UI implementations. By 'should', I mean that it's on my TODO list. The autopilot I modeled is tightly integrated with a GPS unit. It needs to access GPS properties. However, this means that if there are more than one gps unit available in FG, the autopilot code must be changed to use the properties of the particular autopilot. That may not be too great an issue if instruments are supplied with particular aircraft as opposed to something generic that can be placed in any aircraft (like GPS in MSFS). Given that the wiring can be potentially different with each aircraft, the autopilot code may need customizing each time it is placed on a panel. Ideally the instruments will be as multi-usable as possible, and nasal is probably ideal to do the plumbing. But the more complex the systems we are modelling, inevitably the more complex the sim integration will become. Let me know what you need exported from the GPS and I'll try to oblige (but bear in mind I sometimes can't get online for a few days at a time). BTW, can you remind me again where I can download your autopilot from. Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
