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 ellips­oidal model of the earth.

This applet merely illustrates the full system. It needs to work with hardware inter­faces 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 'Swing' 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 dir­ectly. However, in the absence of GPS lat/long input, this class could cal­culate 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 simu­lation 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 lati­tude, 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 per­haps 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 meth­od 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.

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 posi­tions 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 sele­cted 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 dist­ance 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 re­quired 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 consequently 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 compens­ating 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 re­cei­ves from the waypoint encounter class. The steering software then steers the air­craft 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 prev­ious 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 routes 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 way­point.


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 app­let'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.

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 out­bound 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 refer­ence 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 cur­rent 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, navi­ga­tional 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 air­craft is significantly different from the direction North seen by an observer at the way­point. 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 air­craft's position could also be acquired from an inertial platform which uses gyros and accelerometers. Perhaps one day a global positioning system may be devel­oped 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 malfun­ction 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 its designated approach course. For this reason, in this class, 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 reduce 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!

Aircraft Height

The waypoint encounter class creates a height command for the aircraft. For this demonstration, the height command is fixed at 100 metres above the profile of the terrain beneath the flight path. It is assumed for simplicity here that the vertical profile of the track terrain is determined solely by the heights of the waypoints of the route being flown.

Sigmoid function for aircraft height control. For the aircraft's passage between each pair of way­points of the route, the waypoint encounter class cre­ates a sigmoidal path in the vertical plane beginning and ending respectively at points 100 metres above each of the two waypoints. This it does by referring to the standard bipolar sigmoid function shown on the right and then rescaling the height difference be­t­ween the two waypoints and the distance between them. As shown, the function is for when the way­point from which the aircraft is receding is lower than the waypoint it is approaching. For the converse case the sign of 'y' is simply reversed.

The aircraft class then attempts to move the aircraft, in the vertical plane, from its actual height, to merge asymptotically onto the height command sigmoid. This it does according to a simple iterative difference function. The aircraft height shown on the applet panel is the actual aircraft height, not the command height.

This height control method lends itself well to stealth flight. Stealth flying, however, would require many more waypoints. In fact, every significant bump and pimple of the flight-track's terrain would have to be included in a route's sequence of way­points. How low you can fly would be determined solely by how finely the route is waypointed. For covert stealth flights, the flight track's terrain profile would have to be carefully surveyed [probably from satellite photographs and radar imagery] and finely waypointed for every anticipated route in whatever part of the world.

The advantage of a finely graded waypoint route is that it can be flown silently. That is, it can be flown blind without having to use any active sensing devices such as ultrasonic or electromagnetic radar. Thus it can be flown in the dark without ad­vert­ising the aircraft's presence to its surroundings.

Of course, obstacles to low flight may come and go. They can be temporary. In an adversarial situation, obstacles could be such things as strong nets spanning a valley. On-board sensory capability is therefore ultimately necessary. The first and most passive kind could be pitot pressure change sensors. Next could be visual or night-vision devices where the ambient conditions supply adequate illumination. But passive devices may have to trigger short bursts of active sensor operation where necessary. To minimise the risk of detection, these bursts would have to be kept as short as possible.

Source Listing NOTE: this listing does not include the height command channel.

© Jan 2008 (revamped Apr 2010, Mar 2012, Sep 2019) Robert John Morton