Route manager: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
m (added internal links)
Line 3: Line 3:
==Introduction==
==Introduction==


(in the following sections, familiarity with basic IFR concepts, autopilot usage and radio navigation is assumed)
(in the following sections, familiarity with basic IFR concepts, [[Autopilot]] usage and radio navigation is assumed)


The route-manager models part of the functionality found in real-world GPS and FMS devices, but is usable in any aircraft. 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 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.
The route-manager models part of the functionality found in real-world [[GPS]] and FMS devices, but is usable in any aircraft. 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 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.


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. 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. 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.

Revision as of 21:00, 13 October 2009

A real route-manager page!

Introduction

(in the following sections, familiarity with basic IFR concepts, Autopilot usage and radio navigation is assumed)

The route-manager models part of the functionality found in real-world GPS and FMS devices, but is usable in any aircraft. 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 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.

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. 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.

Concepts

The route-manager maintains a flight-plan, consisting of departure, destination, alternate airport and cruise information, as well as a list of waypoints (technically, route segments, or legs). A flight plan must have a departure airport and destination airport specified; all other information is currently optional, which is highly unrealistic, but convenient.

Route manager waypoints are entered as a navaid ident, an explicit latitude/longitude pair, or as an offset (bearing and distance) from another navaid. Each waypoint may also have an altitude associated with it, for vertical navigation modes (VNAV). In the future, other data, especially speed restrictions, may also be associated with waypoints.

Defining a Route

The simplest way to define a route is to add waypoints one at a time by identifier. Since navaid identifiers are not unique, the route-manager uses your departure airport or the previously defined waypoint to 'locate' the identifier search. In practice, navaids with conflicting names are located far enough apart that this works automatically in practice.

Until departure and arrival procedures are supported, you can often define them yourself, by creating offset waypoints. The syntax is ident/radial/distance, for example TLA/347/13 defines a waypoint (which will be named 'TLA13') which is 13nm away from the TLA VOR on magnetic radial 347.

Routes can be loaded (and soon, saved) to a simple XML format, so you may prefer to create the routes in a text editor, and load them instead of entering them by hand. Support for flight-planning tools is also planned, contact the developer list if you are interested on working on such a feature.

In the future, auto-routing using airways or VOR-VOR routing will also be added.

Activating a Route

Activating a route performs certain checks, and creates start and end waypoints based on the selected departure and arrival info. For the moment, that consists of adding the departure runway as waypoint zero, but in the future (when departure procedures are supported) this will create the appropriate procedure waypoints.

This will also be the hook point for calculating cruise information, such as top-of-climb and top-of-descent points in the future.

Other devices (especially a GPS/FMS) may trigger other changes based on activating a route, such as sequencing the first leg of the route, resetting internal counters / timers, and so on.

Flying a Route

Flying a route depends partly on whether the aircraft includes a navigation computer system (for example, an INS or GPS), or not.

Aircraft without a navigation system

The route-manager is in 'auto-sequencing' mode; it will compute some basic route data (such as the total route distance remaining), and automatically switch to the next waypoint (sequencing) when passing the current waypoint. This will never drive the aircraft's autopilot (generic or aircraft-specific) - there is no connection between the route-manager and autopilot systems in this situation.

This mode lets you use the route-manger in aircraft that would never have featured a navigation computer (eg, a WW1-era fighter), but only to the extent that the pilot reads the route-manager information and flies accordingly.

Aircraft with a GPS, INS, FMS

It is assumed the navigation system disables route-manager auto-sequencing (and some other automatic behaviours), and handles all navigation itself. In this case, the route manager is simply providing a library of waypoints; it's up to a specific navigation / autopilot system to follow courses, establish vertical navigation, and so on. Depending on the real-world system being modelled, fully automatic flight may be possible, controlling lateral and vertical navigation as well as speed - but equally, some real world GPS and INS units may not even be connected to the autopilot, and require manual intervention to command the aircraft.

Properties

When a route is active, the route-manage provides various pieces of information based upon current aircraft position / speed, and the route progress. These values would be calculated by the navigation computer in a real system, but are handled by route-manage in FG for convenience. Values logged include the takeoff time, estimated time enroute (ETE), distance remaining enroute, and so on - browse the property tree to see what's available.