Robert John Morton
The Navigator
Introduction
The Applet
Instructions
Technical
Full C-version
WARNING
Development
Waypoint Encounter
Moving Map Project
Navigation Functions
Mobile Network
Nomad Project
Technical Outline
Commercial Outline
Project Outline
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 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.
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'.
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.
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.
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 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 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.
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.
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).
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.
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.
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 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.
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 is 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.
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.
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!
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.
For the aircraft's passage between each pair of waypoints of the route, the waypoint encounter class creates 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 monopolar sigmoid function shown on the right and then rescaling the height difference between the two waypoints and the distance between them. As shown, the function is for when the waypoint 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 waypoints. 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 advertising 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.