Route Design Library will be available with the AGI Components 2010 r5 release (also available in Java)! Go to the ADN Download Center for more information and to view the Route Design Library Documentation Overview. Now, users have a new way to specify trajectories for aircraft, ground vehicles, and ships for use with our other libraries. Route Design Library provides various pieces such as waypoints, holding patterns, and raster search procedures to use in order to define routes.
We've received a number of questions and comments on how to represent aircraft and ground vehicle trajectories for use with mission analysis. Route Design Library makes it a lot easier to create and analyze these kinds of trajectories. Now, users will be able to specify waypoints, heights, and speeds to define a route and generate a trajectory over the surface of the Earth or other Central Body. Previously, the WaypointPropagator (still available in DGL) provided a way of specifying waypoints and creating a Point. However, many users have found it difficult to use in certain cases since it requires careful handling to make sure the properties on each waypoint are consistent with the surrounding waypoints in order to avoid exceptions during propagation. With Route Design Library, that process has been simplified, allowing for a looser definition of waypoints to make it easier to specify a valid route. I will discuss a few of the key features and paradigms here.
Procedures and Profiles
The key features of Route Design Library are its "procedures" and "profiles". "Procedures" define the behavior of the route around certain locations or areas of interest. In general, most users will only need to use the different waypoint types to specify how to execute a turn at a given waypoint. However, we also provide other procedures such as takeoff, landing, circular and racetrack holding patterns, and a raster search pattern useful for covering a search area. Likewise, there are three different "profiles" provided to specify the vertical and temporal behavior along the surface route. Some procedures include their profiles implicitly, as is the case with takeoff and landing. Often, the procedures will require using a profile such as a ConstantHeightProfile or TerrainAvoidanceProfile which I will talk about in the section below. The other profile StandardTransitionProfile is primarily intended for the connection segments which glue the user's procedures together.
Geometry: Points, Axes, and Scalars
Of course, the primary output of the library is a DGL Point object which can be used with Platforms in the rest of the library. However, we also provide a number of Scalar objects for various analysis properties along the route such as ground or total speed and height with respect to a reference surface like MeanSeaLevel. Lastly, there are two Axes types: AxesAlongTerrain and AxesFromBankAngle. The former provides a simple way of representing the orientation of a ground vehicle as it traverses over a terrain with its z axis aligned with the local terrain normal. The latter provides a simple way of representing an aircraft as it 'banks' around turns, balancing gravity and centripetal forces.
Overdefined Hassle vs. Underdefined Configuration
One of the things we looked at when creating Route Design Library was the problem of creating "overdefined" design spaces. When a system is overdefined, it is often unclear to users how to specify all of the parameters in a way that won't cause problems. An overdefined system places the burden on the user to ensure that all of the inputs are consistent and valid, often creating a lot of hassle early in the design process as users keep running into exceptions as they try to determine how to create valid inputs. In Route Design Library, the user's input can be underdefined, meaning that there are a number of heuristics in place which allow the system to create a valid route based on just a few user inputs. Primarily, the system revolves around the users specifying behavior at the "procedures" and then allowing the propagator to create "connections" to combine the procedures together into a complete route. This allows users to focus on those parameters which they want and let the system connect the rest in order to create a valid route, instead of having to fuss in order to finally create the valid route.
Since the specific performance characteristics of aircraft are often not available during the initial mission design, it doesn't make a lot of sense to create a highly detailed route which is inevitably inaccurate compared to the real-life flight path. Instead, the goal is to allow users to simply create a reference trajectory from which they can analyze the wireless communications, asset coverage, and scheduling feasibility of a given route before working on developing the final flight path. If some of the flight characteristics are available, users should be able to use them to determine the inputs needed to create a fair approximation of the final route.
Route Design Library also has the ability to include analytical terrain for use with profiles. By specifying a terrain surface, the TerrainAvoidanceHeightProfile can aid in designing a route by providing a simple way for users to specify aircraft routes which maintain a given height above mountainous or rapidly changing terrain. The system will reconfigure the user's input to attempt to avoid the terrain by reconfiguring the surrounding procedures until the system either creates a valid route or encounters an error which prevents the route from avoiding the terrain (e.g. If the user has fixed the surrounding heights below the terrain and the system can't update them). However, if there is an error, it will not throw an exception! (except of course in cases where there are NaNs in the user's input). Instead, the propagator will return the invalid or discontinuous route with meta-data in the form of ProcedureConfigurationResult objects indicating what the error was and where it occurred in the route. This way, the user has the chance to visualize the discontinuity in order to see what went wrong, rather than throwing an unrecoverable exception.
Non-Euclidean Geometry Hidden from the User
Anything that moves over the ground (or water) requires some special handling. When dealing with satellites, the dynamics for Newtonian gravity are well defined and the only use for the 'ground' is as a projection surface onto which to plot the "ground track" for the satellite. When thinking in terms of aircraft or even ground vehicles on cross country shipping routes, most people don't tend to think of the 'ground' as being curved and may overlook the relationship between the 'flat' map projections used in navigation and the three dimensional reference frames used by satellites. Aircraft manuals and documentation will often refer to "ground speed" and "true speed", but what do these really mean in terms of the Fixed Frame of the Earth? One of the things we decided was that, when defining a 'route', users do not want to have to calculate the coriolis accelerations and other effects of moving over a rotating curved surface. As such, users specify the speeds at waypoints as if they were the 'local' or 'flat' dynamics and Route Design Library takes care of accounting for the additional dynamics observed by satellites communicating with vehicles along the route.
As mentioned before, the Route Design Library makes use of analytical terrain surfaces for the TerrainAvoidanceProfile. In addition, the library uses terrain surfaces to specify the reference from which the "height" is measured for a given profile. So, instead of just dealing with Cartographic values which are by default referenced to the WorldGeodeticSystem1984 Ellipsoid, Route Design Library can create routes which have their heights referenced to MeanSeaLevel or in the case of ground vehicles referenced to the mountainous terrain over which they are driving. It is also possible to transition from one to the other. So, in the case of an aircraft taxiing on a runway before takeoff, it is possible to transition from having the height referenced to the runway surface to an Ellipsoid height or height above MeanSeaLevel. The library takes care of any additional dynamics needed to transition between the local dynamics and the dynamics in the Fixed Frame as seen by a satellite.
Remarks and Future Development
In the end, we hope Route Design Library is easy to use programmatically so that users can design their own systems which can iterate when designing scheduling and mission analysis programs. It also makes it much easier to use with Insight3D, since it is much simpler to visualize the route itself and identify the location of any errors in the route. For now, the library focuses mainly on heuristic and approximate routes intended for creating simple routes quickly and easily. In the future, new procedures and connections may be added to allow trajectories based on performance characteristics and numerical flight mechanics. As always, it is also possible for users to extend our types to create their own as well. If you or someone else on your team has any questions about Route Design Library, how to extend it to implement custom functionality, or if you have a feature request, please feel free to post on our ADN discussion forums.