Moving-Map Navigator: Technical Details

A demonstrator in principle of a flight guidance system whose function is to steer an aircraft from an origin to a destination via a route, where a route is defined as a set of way points joined by 'great circle' arcs using an ellipsoidal model of the earth.

This applet merely illustrates the full system. It needs to work with hardware interfaces and other devices to automatically navigate a physical unmanned air vehicle. The moving map is shown in the style of a 'head-up display' as if you are remotely piloting an aircraft with a forward-view camera. The applet's window and controls, and also the navigational classes which control the flights are described below. Please bear in mind that the flights can take a long time.

The Applet Window

The core of this applet is an Applet class called movmap. movmap, however, does not write to or paint upon the applet window directly. All painting and writing is done indirectly by 5 subsidiary Java AWT Components which are added to the applet's own Panel. These are:

movmap passes all button events straight to the subsidiary panel classes which then handle these events.

Navigational Functions

A flight is set up and run by the following classes. These contain the methods which fly the aircraft from its origin to its destination via the chosen route.

† The forward class is not currently integrated with the applet because aircraft movement is effected by updating its latitude and longitude directly. However, in the absence of GPS lat/long input, this class could calculate the aircraft's current latitude and longitude from distance and bearing information received from a VOR/DME type station that need not necessarily be on the flown route.

Flight is facilitated by movmap's run() method calling a method in route.class every half second which in turn calls appropriate methods in the other classes to move and guide the aircraft. Please note that these classes specifically omit means for integrating with other air traffic. Also absent are software connections to real-world sub-systems such as gyro-compass, Navigational Aids Receiver and GPS.

This applet is a demonstration version of a navigation aid which I had previously developed in 'C'.

Wind Simulation

In this web-version of the applet, the same 100kph south-west wind (bearing 230) is simulated all over the world. It is, however, possible to implement a better simulation of wind. One way is to get the wind speed and direction at any given location from a global database of prevailing winds or from a database containing the real wind situation on a particular day.

The ideal simulation of wind would be to get wind speed and direction at the latitude, longitude and height of the aircraft once per minute from a global weather server such as World Weather Online. This would require the writing of a wind{} class that can access and analyse the XML output presented by the weather server. The aircraft{} class could then get wind speed and direction from the wind{} class through calls such as

double WS = wind.getSpeed(Lat, Lng); //in Earth-radians per second
double WD = wind.getFrom(); //from where wind is blowing in radians

Perhaps I shall do this when the urge strikes me.

Global Height Field

Not implemented in this web-version of the applet is a terrain view generated from a height-field database. This would give a pilot's eye view of the terrain (and perhaps even buildings too) from a given aircraft height, forward viewing angle and map scale. The waypoints map would also be slanted to the same viewing angle and scale. To implement this on the web version would require on-line access to a height-field server that could stand thousands of requests per second from a method such as

int h = heightField.getHeight(Lat, Lng);

in order to get a stream of scanning points for the terrain presentation. At the time of writing this is not really practical. It would also require the adding of a height channel to the aircraft{} class and waypoint data.

A Philosophical Point

You may notice that on the moving map, as the aircraft advances along its track, the various waypoints and features in view tend to move relative to each other. For example, when the aircraft first starts to turn onto track, Brighton, Guildford and Oxford seem to move relative to each other in independent small jerks. This would appear to be absurd. We all know that, in "reality", these cities stay in fixed positions relative to each other.

This is, of course, an effect that is entirely due to the limitations of the pixel raster of the map area. If the pixels were infinitely small then all would move together smoothly with the cities maintaining their fixed geographic relationships as they moved relative to the aircraft. Notwithstanding, even with infinitely small pixels, the stability of the relative positions of the cities would be limited by the precision of the floating point double arithmetic within the program. So, theoretically, they would still appear to suffer the absurdity of relative motion. Consequently, from the point of view of the aircraft (and the sensing devices on board) there will always appear to be at least some degree of relative motion between different supposedly fixed objects.

This gives rise to a universal corollary. An observer can only perceive reality from his own point of view in space and time. So an observer's view of the universe is necessarily limited by the capabilities of his senses and his powers of perception. Where he sees a distant star may therefore not be where it "really" is. This could be due to gravitational lensing or whatever other phenomenon may affect an object's apparent size and position.

Observation and perception is ultimately limited by the speed and trajectory of the light emitted by the object, by which the observer observes it. However, where the object appears to be is also the position from which the object affects the observer gravitationally and in every other possible way. Consequently, within an observer's view of the universe, that is where the object "really" is.

On the universal scale, therefore, the relative motion of supposedly fixed objects from the observer's point of view that we see on the navigation map is not quite so absurd as it would at first appear.

Descriptions of the Classes

1) The Aircraft Class

The main function of this class is to advance() the aircraft along the currently selected route. It does this every second, every 200 milliseconds (5 frames per second) or every 40 milliseconds (25 frames per second) according to which of the Refresh Rate radio buttons is selected.


The aircraft is advanced along its route by an amount equal to the distance it would travel at its current air speed within the length of time specified by TF. This distance is then resolved into its south-north and west-east increments. The aircraft's latitude and longitude are then updated by these increments. The speed which the aircraft is required to attain is provided by the waypoint encounter class WpEnc. This will invariably be somewhat different from its actual current speed. This is because the aircraft is imbued with an unnaturally large amount of linear inertia. This causes the aircraft only ever to manage to accelerate or decelerate part of the way towards the speed at which it is required to travel.


The aircraft is also at the same time rotated as necessary. At each time frame, the waypoint encounter class WpEnc provides the heading rh which the aircraft is required to take in order to follow the route. However, the aircraft is also imbued with an unnatural amount of rotational inertia. The heading it achieves is therefore somewhere in between its current heading h and the required heading rh. The aircraft's acquisition of the true required heading can be further delayed by the fact that an upper limit is imposed upon the aircraft's rate of turn.


The reason for the unnaturally large amounts of both linear and rotational inertia is to exercise - and thereby demonstrate - the guidance method's ability to bring the aircraft back on course when perturbed.


To exercise of the guidance methods, a 100kph south-west wind (actually from bearing 230) is simulated. The wind speed is resolved into northings and eastings which are added to those of the aircraft's air speed when its latitude and longitude are updated.

If the aircraft steers directly towards the next waypoint, it will be gradually pushed off the prescribed route by the wind and have to alter its heading all the time to maintain a heading towards the waypoint. It would, in effect be following a spiral path, although since the aircraft's air speed is much greater than the wind speed, it would only ever be a small segment of a complete turn of the spiral.

To avoid this effect, the steering software has built within it a means of compensating for the effect of the wind without actually having to be informed of the wind's speed and direction.

It does this by comparing where is has ended up with where it intended to end up during each iteration of the program. From this it works out the error in its ground track heading. It then adds this error to the commanded required heading it receives from the waypoint encounter class. The steering software then steers the aircraft onto the wind-corrected required heading. This causes the aircraft to orient itself to a heading that is slightly off the direction to the next waypoint so that part of its engine thrust compensates for the cross-wind component.

The effect of this automatic wind-correction capability can be seen on the moving map as an aircraft is approaching or receding from a waypoint. The aircraft's thrust heading is always exactly towards the top of the map. However, the outbound radial or inbound corridor it is following appears slightly slanted, showing that the aircraft is being blown somewhat sideways onto the slanting path.

This class's other function is to reset the aircraft's position to the first, next or previous waypoint along the currently selected route.

Source Listing

2) The Route Management Class

This class creates and manages flights along predetermined routes. These routes have been chosen to exercise the flight guidance software's ability to fly the aircraft in different directions along both short-legged circuitous and long-legged great-circle routes.

Route Creation

This class facilitates the creation of, and holds, an ordered list of the waypoints for each route. Necessarily, it also holds a list of routes. There are only 6 routes in this demonstration applet, all of which are pre-determined. They cannot be altered by the user. However, the class has been designed to provide a future external client class with the means to enable users to build their own routes.


Whenever a new route is selected by the user, the init() method steps along the route - waypoint-by-waypoint - placing in each one's object data the distances and bearings of its next and previous neighbours in the route. This information is used by WpEnc.class during its management of the aircraft's encounter with each waypoint.


A flight along a route is managed by the advance() method. A flight starts with the aircraft leaving (receding from) its airport of origin. This is regarded as the first waypoint. The aircraft therefore starts off in an encounter with its point of origin. When the aircraft has travelled half way to the next waypoint, the advance() method steps to the next waypoint along the route. This next waypoint thus now becomes the current waypoint being encountered. This stepping process continues until the aircraft reaches its destination (which is also regarded as a waypoint).

Source Listing

3) The Waypoint Class

This class creates an object for each waypoint and geographic feature on the applet's 'Earth'. All of these objects represent cities. In reality, all the waypoints making up an air route would normally be some form of navigational aid such as a VOR station or ILS localiser. However, to make routes look more familiar to most people, city names and positions are used. It should be borne in mind that the 6 routes in this applet are fictitious. Aircraft do not really fly from city-centre to city-centre like this.

Perhaps the most important method in this waypoint class computes the aircraft's distance from the waypoint upon whose reference the method DandB() is invoked. It also computes the bearing of the waypoint from the aircraft and also the bearing of the aircraft from the waypoint. Note that on the ellipsoidal surface of the Earth, one bearing is not simply the other with 180° added as it would be on a flat plane. The actual distance and bearings are obtained by calls to methods in dandb.class, which uses the Vincenty Method for computing distance and bearings.

Source Listing

4) The Waypoint Encounter Class

This class steers the aircraft from one waypoint to the next. There are 3 phases to this process: the outbound radial phase, the great circle phase and the approach and turn phase.

The Outbound Radial Phase

The aircraft begins its journey from its airport of origin. This is deemed to be the first waypoint of the route. The aircraft therefore begins its journey by flying outbound from this first waypoint. It flies along the particular outbound radial from this first waypoint which points to the second waypoint in the route. The steering in this phase of the leg [the journey between two waypoints] is normally done by reference to a radio aid such as a VOR station. Hence the name of the method getRadioHeading() which expedites this phase. The outbound radial steering is done by the second clause of the method's main if statement.

If the next waypoint is less than 300km away, the outbound radial which is used is not the one which points directly at the next waypoint. Instead, the radial used is the one which is the tangent to the next waypoint's appropriate turning guide circle. Turning guide circles are explained later. The outbound radial from the current waypoint is displayed on the applet's map canvas as a short white line.

The Great Circle Phase

This phase takes place only for legs (inter-waypoint distances) which are greater than 300km. When the aircraft is more than 150km from its nearest waypoint, navigational references with respect to that waypoint become affected significantly by the curvature of the Earth. The direction North from the point of view of the aircraft is significantly different from the direction North seen by an observer at the waypoint. It is therefore necessary in this phase of the inter-waypoint transit to refer all bearings to the aircraft's notion of where North is.

The objective in this phase is to keep the aircraft flying as closely as possible to the great circle which passes through the two waypoints which mark the beginning and end of the leg. To do this, both waypoints are used for navigation: not just one as in the case of the other two phases. If the bearing of the receding waypoint as seen from the aircraft is 180° from the bearing of the approaching waypoint as seen from the aircraft, then the aircraft is on the said great circle.

The great circle phase steering method getGPSheading() measures the difference between these two bearings and if that difference is not 180° it applies a steering correction to reduce the shortfall at a rate which is a positive function of the size of the error. This error can be seen on the applet's map. During a great circle phase, a magenta-coloured line points towards the approaching waypoint and a yellow one towards the receding waypoint. If together they do not exactly form a straight line, then the aircraft of not quite on the great circle joining the two waypoints.

The most direct way to do this computation requires knowledge of the aircraft's current position (its latitude and longitude). The topical way to get this is from a GPS receiver which uses the satellite-based Global Positioning System. However, the aircraft's position could also be acquired from an inertial platform which uses gyros and accelerometers. Perhaps one day a global positioning system may be developed which is based on natural radio sources such as quasars. If this were to prove feasible, it would certainly be cheaper, long-lasting and safe from technical malfunction and sabotage.

The Approach & Turn Phase

Once the aircraft gets within 150km of the approaching waypoint, or over half way from the previous one, whichever occurs sooner, the guidance software switches into the approach and turn phase. The geometry of this phase is discussed in detail in the section on the waypoint encounter applet. It is expedited in this class by the getStrOff() method below.

The little waypoint encounter demonstration applet does not deal with strong winds in a way acceptable to circumstances of controlled airspace. During an approach, the aircraft will be guided faithfully on a course which is tangential to the turning guide circle as it should - even under conditions of strong cross winds. However, it will get blown progressively round the circle thereby not adhering to a designated approach course. In this class, therefore, an additional steering method called getWndOff() confines the aircraft to a narrow approach corridor. Whenever the wind attempts to blow the aircraft outside this corridor, the getWndOff() method kicks in to steer it back into the corridor.

Aircraft Speed

The aircraft's speed is determined by the getReqSpd() method. This makes the speed a function of the aircraft's distance from the nearest waypoint. The reason is quite arbitrary. Although, this helps to cut down the time taken to cross long oceanic legs, it results in speeds which would be more credibly associated with a cruise missile or a flying saucer!

Source Listing

© January 2008 (revamped April 2010, March 2012) Robert John Morton