9/18/2023 0 Comments Flightgear route managerThe route-manager maintains a flight-plan, consisting of departure, destination, alternate airport and cruise information, as well as a list of waypoints. In general core features exist in whichever place seems the most natural, and it's up to instruments to aggregate the core modules as they require. It's important to realize that the route-manager (and GPS) are pieces that a panel instrument might present as a single real world device - the mapping between C++ modules, generic user interface and in-panel instruments is very fluid, by design. The route-manager is also how a flight plan is made available to FlightGear - in the future this will hopefully permit better ATC and multi-player interactions, since ATC logic or controllers will be able to observe the filed plan associated with a pilot. Some panel instruments may provide access to the route manager via their own UI, but the route-manager is always available through a generic dialog box. The route-manager models part of the functionality found in real-world GPS and FMS devices, but is usable in any aircraft. (in the following sections, familiarity with basic IFR concepts, Autopilot usage and radio navigation is assumed) command interface /autopilot/route-manager/input: This control interface is implemented beginning in flightgear/flightgear/next/src/Autopilot/route_mgr.cxx#l688: Once some FlightGear system writes to such a listened-to property, the registered callbacks of the route manager system are automatically invoked by the listener to process, validate and handle the "command" properly. This is very much similar to Qt's signals/slot mechanism. This means that C++ code can be easily invoked by setting a bunch of "control properties", to which the route manager subsystem holds registered listeners. In addition, the route manager system also implements the interface of the SGPropert圜hangeListener SimGear class to create a property-tree based control interface on top of the property tree. finally, the pointer to the route manager system is used to directly invoke the required C++ method.turning the argument into an argument usable by the method that will be called. next, they start parameter validation and processing, i.e.first, they acquire a temporary pointer to the global route manager system.SGPath path(arg->getStringValue("path")) Īs can be seen here, all commands follow a fairly similar pattern: Static bool commandLoadFlightPlan(const SGPropertyNode* arg)įGRouteMgr* self = (FGRouteMgr*) globals->get_subsystem("route-manager") So, if you haven't already, it's a good idea to first read Howto: Add new fgcommands to FlightGear. These "commands" are pretty much standard fgcommands, so they have the standard fgcommand signature. the commands plain text name) to a C++ callback function. The addCommand() method merely maps an ASCII string (i.e. SGCommandMgr::instance()->addCommand("delete-waypt", commandDeleteWaypt) SGCommandMgr::instance()->addCommand("insert-waypt", commandInsertWaypt) SGCommandMgr::instance()->addCommand("set-active-waypt", commandSetActiveWaypt) SGCommandMgr::instance()->addCommand("clear-flightplan", commandClearFlightPlan) SGCommandMgr::instance()->addCommand("activate-flightplan", commandActivateFlightPlan) SGCommandMgr::instance()->addCommand("save-flightplan", commandSaveFlightPlan) SGCommandMgr::instance()->addCommand("load-flightplan", commandLoadFlightPlan) Implementing VNAV support in FlightGear (RFC).Howto:Add procedures to the route manager.Howto:Add new features to the route manager system.Autopilot PID controller tuning resources. If in doubt, please get in touch via the mailing list or the forum first. įor details on exposing these C++ systems to Nasal, please refer to Nasal/CppBind. Technically, this is also the correct approach, as it allows us to easily reuse existing code that is known to be stable and working correctly. For example, this would enable Scripted AI Objects to use full FDM implementations and/or built-in route manager systems. The FlightGear/ SimGear code base already contains fairly generic and efficient systems and helpers, implemented in C++, that merely need to be better generalized and exposed to Nasal so that they can be used elsewhere. It will also help to unify duplicated code. This is primarily to help reduce Nasal overhead (especially GC overhead). Note Whenever possible, please refrain from modeling complex systems, like an FDM, autopilot or Route Manager with Nasal.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |