Saturday, 01 September 2012 12:08

Adaptive LNAV Routing

We have almost completed our lnav route planning and during this process, we have encountered some interesting situations that we though some might find interesting.  The source data we used to construct our lnav routes comes from the database provider, Navigraph.   There are well over 300,000 waypoints in the database and thousands upon thousands of routes.  The challenge is to draw lnav routing successfully, taking into account aircraft performance and  given any potential combination of waypoint proximity and types.

There are 9 different types of waypoints in the database:  Normal, DME Intercept, Interception (INTC), Constant Heading to Altitude, VOR Radial Intercept, Vectors, PBD (Place/Bearing/Distance), Runway and Hold.   These types can appear in any order and the relative angles between waypoints can vary from zero degrees (instant reversal) to 180 degrees (no direction change).  Of course zero and 180 degree changes are special cases and not really encountered in practice, but from a theoretical point of view they exist.   In addition, the distances between waypoints can vary greatly from being very close together to very far apart.  Each case brings up unique situations that do not always demand the same results.   The figure below illustrates some of these situations.

CASE 1 shows a route whereby we takeoff and then at a VOR radial intersection we proceed along a fixed course  (097) to a DME intersection and then proceed to a normal waypoint.  The Navigraph data specifies whether a waypoint is to be flown over directly or if can be flown "by", which is in effect, "cutting the corner".    In this particular example, waypoint 3 is categorized as a "Fly-over" waypoint in the Navigraph database. This means we need to pass over the waypoint and then turn to intercept the next leg.  The normal intercept angle is 30 degrees and if waypoint is sufficiently far away, then you can indeed fly over the point and make the turn and intercept the leg between waypoints 3 and 4.   CASE 2 illustrates this.

In CASE 3 however, suppose that waypoint 4 is too close to waypoint 3 to make the turn and intercept the subsequent leg at 30 degrees (shown by the dashed line).  In this case, we must continue turning until we are flying towards waypoint 4.  If waypoint 4, which is a "flyby" waypoint is too close to our path after completing our turn from waypoint 3, then we would be forced to overfly  point 4 and then re-intercept the path away from point 4 along the route.

CASE 4 shows the same route except with waypoint 4 being a gentle turn from waypoint 3.  CASE 5 shows how if we flew the route exactly as stated in the Navigraph data, we would overfly waypoint 3 (the dashed path) and re-intercept the leg from 3 to 4.  In this case, though, because the angle is a gentle one, we can make the decision to turn a bit early and save a bit of fuel.    CASE 6 shows waypoint 4 being a bit sharper angle turn from waypoint 3 and if waypoint 3 was sufficiently close to waypoint 2, which is common in SIDs, then we would be unable to flyby waypoint 3 and would have to fly over it and re-intercept the leg to waypoint 4.

 We have written our lnav routing to be adaptive in these situations.  We look at the navigraph data, the relative geometry of nearby waypoints and in certain cases, we will change a flyover situation to a flyby and/or alter the intercept angle.  In this way we can construct the route in a more natural way as it was intended and not be completely locked in to the explicit specifications in the navigraph data, which in many cases is a "best approximation" of the procedure.  The result has been more reliable route building that better follows the published procedures and intentions of the procedure.

lnav blo


  • Comment Link Wednesday, 03 October 2012 20:43 posted by Levin Strausser

    Hi guys! I am so in love with your project but please be more generous and share more info regarding progress, screenshots, videos etc. I tend to go here quite often as I am highly interested of buying the final product, so it would be real nice to see some of the progress and to have some video to watch as we all wait. Thanks again guys.

  • Comment Link Thursday, 20 September 2012 18:13 posted by

    Emmanuel: Hi! I asked this question too on forum and this was the answer from Jan: "That is not planned but I will not rule it out for later on, either."
    Hope it helps.

  • Comment Link Wednesday, 12 September 2012 11:33 posted by emmanuel

    Hi I'm very looking forward for this plane !
    I have a suggestion for the FMC, that would be to be able to use it on an ipad or android tablet that would be awesome !!!

  • Comment Link Wednesday, 05 September 2012 02:46 posted by Fabo

    Does this mean IXEG 737 will not support other path/terminators like radius to fix? Is this an issue of a pre-existing database you are planning to use?

  • Comment Link Tuesday, 04 September 2012 18:07 posted by Tom

    It is probably better described that proper LNAV by its very nature is adaptive rather than we are implementing a "special form of LNAV". FMS calculations have to take into account several parameters and then "adapt" the route to fit those parameters. The biggest variables are wind, groundspeed and bank angle. Variations to any of those will change the turn radius and therefore the intercept conditions of route legs. Some FMS simulations only draw "point to point" routes and do not take into account leg transitions and turn performance and we have endeavored to write our lnav to be a bit more like the real thing in these cases.

  • Comment Link Tuesday, 04 September 2012 14:43 posted by Flo

    Very interesting as always. Is this (adaptive LNAV) the way it is done by a real 737FMS? Let me guess: Yes, it is.


Leave a comment

Latest User Comments