CA1296412C - Vehicle navigation system - Google Patents

Abstract

VEHICLE NAVIGATION SYSTEM

ABSTRACT OF THE DISCLOSURE
A vehicle navigation system is provided wherein a preselected route is established in terms of a sequence data and processing means computes sequence action data based on lineal distances between landmarks, such as junctions, and movement detective means, such as a turn detection, for detecting movement only around an approached landmark in order to synchronize position with the landmark. In accordance with the invention, it is unnecessary to store all geographic data about a region to be traversed during a journey and further computation can be extremely efficient without reliance at any time or detection of direction with respect to magnetic north or other fixed, remote reference. All needed information is incorporated into data related only to distance travelled by the vehicle between landmarks and movement around (e.g., turns) an approached landmark. The system works on the assumption that the vehicle moves in one dimension between predetermined landmarks so that route information can be reduced to a sequence of indicators.
The movements around landmarks, or more specifically junction or turns where deviations are expected from a straight line constant velocity path are used to synchronize vehicle location relative to the landmark.
The accuracy of map distance between landmarks is assumed within an acceptable error so that synchronization can be obtained within a window distance during which the system seeks synchronization.

Description

VEHICLE NAVIGATION SYSTEM

BACKGROUND OF THE INVENTION

The present invention relates to vehicle navigation systems.
Map reading is a skilled task and may cause particular problems in cities where the large number of road intersections and density of traffic can easily give rise to confusion. The problem is compounded when in the absence of a passenger, the driver is forced to do his own map reading and navigation.
To ove~come these difficulties, in one aspect, this invention provides for a vehicle navigation system comprising:
means for storing map data representing a road netwotk, said data comprising information about landmarks, said information comprising landmark identifiers, landmark location and landmark characteristics of said landmarks in said road network, map distances between said landmarks, and path characteristics between adjacent landmarks;
means for receiving start location data indicating vehicle start location;
means for receiving destination data indicating a desired destination;
means coupled to said map data storing means for establishing a route comprising sequence data, said . :
sequence data indicating a sequence of landmark identifiers;

`~ ~
., ~
.

1a lf~
first processing means coupled to said route establishing means for receiving said se~uence data and for computing sequence action data, said sequence action data comprising computed lineal distances between S landmar~s and status data related to an approached landmark;
distance measuring means for measuring distance travelled by said vehicle to provide measured distance data;
means for detecting vehicle movement in a distance window only around said approached landmark to provide movement data indicative of change in motion of said vehicle;
second processing means coupled at least to said first processing means, to said distance measuring means, and to said vehicle movement detecting means for receiving said movement data, said distance data and said sequence action data, for supplying output data indicative of current location or expected actions in sequence fo20 aiding a driver of the vehicle to adhere to the route; and output means for supplying the output data in a .
form discernible by the driver.

The following patents and publications have been cited in the course of prosecution of patent or analog applications to the present application.

12~ 2 lb UK 2060880A 05/07~81 EP 0110171 06/13/84 (French) PCT 84/01823 05/10/84 (German) US 4,688,176 08/87 Hirata US 4,672,563 06/87 Haramatsu US 4,633,709 01/87 Numata JP 61-17911 01/87 Tamura (Japanese) EP 0080736 06/83 (Japan) UK 2180066A 06/18/87 (Foreign Analog of present application) ~' ~
`':

~ 30 :::
~ 35 ' .:

:

2 12~
of the above patents and publications Hirata is representative of a typical two-dimensional naviga-tion system. Location within an area is determined continuously in two spatial dimensions with reference to an absolute reference such as magnetic north.
The ~amara reference is a still further example of a mechanism requiring continuous detection of orientation. Tamura provides for correction of deviation between a "present position" and a "display position" continually and in at least two dimensions with reference to a coordinate system using a direction sensor, an angle sensor, and an azimuth sensor. Other sensors are also provided.
The UK published application 218~066A pub-lished 3/18/87 is not a reference against the present application as it was published less than one year prior to the effective filing date of the present application. the present application describes en-hancements of the previously-described system.
SUMMARY OF THE INVENTION
According to the present invention, a vehicle navigation system is provided wherein a preselected route is established in terms of a sequence data and processing means computes sequence action data based on lineal distances between landmarks, such as junctions, and movement detective means, such as a turn detection, for detecting movement only around an approached landmark in order to synchronize position with the landmark.
In accordance with the invention, it is unnecessary to store all geographic data about a region to be traversed during a journey and further computa-tion can be extremely efficient without reliance at any time or detection of direction with respect to magnetic north or other fixed, remote reference. All needed information is incorporated into data related only to distance travelled by the vehicle between landmarks and movement around (e.g. turns) an approached landmark.
The system works on the assumption that the vehicle moves in one dimension between predetermined landmarks so that route information can be reduced to a sequence of indicators. The movements around landmarks, or more specifically junction or turns where deviations are expected from a straight line constant velocity path are used to synchronize vehicle location relative to the landmark. The accuracy of map distance between landmarks is assumed within an acceptable error so that synchronization can be obtained within a window dis-tance during which the system seeks synchronization.
The system eliminates need for a compass and actions related to continuous or even interim reference to compass data.
An object of the invention is to provide a vehicle navigation system which can compute a route to a desired destination.
A further object of the invention is to provide a vehicle navigation system which avoids the need for use of a map.
Another object of the invention is to provide a vehicle navigation system which avoids the need continuously to measure position without sacrificing accuracy.
In one embodiment, the storage means stores one or more specific preset routes. the output means may function to provide a visual display, or to provide audible spoken information, or to provide both spoken information and the visual display.
The main purpose of the system is to assist a vehicle driver to navigate from a given starting point to a desired destination along a route selected from data representing a map. The system employs a non-volatile memory device for storing data representing a map for a 12~ 2 region, a city, a village, or a route etc. The memory device may be designed as a plug-in unit and will be prepared in advance for the user.
Data may be entered into the system by the user by means of a portable key board optionally provided inside the vehicle.
Navigation and guiding instructions for the driver may be displayed on a visual display unit.
The vehicle location is determined preferably from the following devices: a distance sensor deriving data from wheel revolution: and a turn sensor, e.g., an angle sensor preferably deriving data from rotation of the steering wheel of the vehicle. If desired, two distance sensors may be provided associated with two road wheels, and such a pair of sensors may function as an turn detector.
The correlation between the vehicle actual location and the current vehicle location assumed (i.e.
computed) by the system is preferably regularly updated.
This ensures that the system remains accurately syn-chronized with the moving vehicle. In a preferred embodiment of the invention, the system can automati-cally reset itself every time the vehicle makes a significant detectable movement, such as a turn at a recognized intersection (junction) or other landmark.
It is possible of course to identify the vehicle position with precision when a turn is made at an intersection since the vehicle is forced to adhere to the public highways and roads whose locations are accurately known and defined by data stored in the system memory. Thus, when the turn is detected, it may be assumed that the vehicle is precisely at a recog-nized street intersection. Other detectable movements may also be employed for system synchronization or - 35 accurate positioning, such as a deceleration movement or a stopping movement.

.

s 1~6~i2 A window enable distance is defined corre-sponding to a period during which the system is enabled to await the automatic synchronizing action, preferably a turn, (which will be marked in the data base format as a synchronizing turn), and during the enable period at the location when the integration over a time interval of the measured speed multiplied by the measured angle detected by the turn detector is a maximum, the system will be synchronized. This point may be regarded as the point on the road where the rate of turn is the greatest, because the actual angle of the turn in a given time interval is proportional to the integration of the measured speed multiplied by the measured angle over that time interval.
If desired, the system may be adapted to receive data from three different memory units. These three units may be:
a. A country memory unit which would normally be an integral part of the system;
b. A city unit which may be a plug-in unit to allow for road map data of various cities: and c. A plug-in memory unit for various special applications such as location of favorite hotels, restaurants or sports arenas or for playing games.
The country memory unit would normally store data representing all the main roads such as motorways or main cross- country highways and all main roads leading to city centers. The city plug-in unit would store all the roads within a certain city. The third plug-in unit can be adapted to various purposes in dependence upon the wishes of the user. It is possible to employ the system only with the country memory unit in place. It would be possible however to use the system with the country memory unit and the city memory unit. It is also of course possible to employ the system with the country memory unit and the special applications unit and it i8 even possible to om~t the 6 129~ z country memory unit and rely only on one or both of the other units although, as stated above, the country memory unit will normally be an integral part of the system.
Usually, the special applications memory unit will be used with the city memory unit or with both the city memory unit and the country memory unit. This is because, in a preferred embodiment, the special applications memory unit will contain names of places referred to an intersection number in one of the other memory units, and normally to an intersection number which is defined in the city memory unit.
Of course any combination of units may be plugged into the system, but when only the special applications memory unit is employed (if the country memory unit is not an integral part of the system) it is possible to use the system for playing games etc, and not for navigation. When the country memory unit is an integral part of the system (which it preferably will be) and the special applications memory unit is employed, the potential of the system for naYigation through the special applications memory unit will be quite limited, since the country memory unit will naturally not include many special places, because it will contain mostly highways.
It would be recommended to implement the various kinds of the memory units as follows:
The special applications memory unit may be implemented in ROM or EPROM, and the system will access it directly. The country memory unit and the city memory units may also be implemented by providing a magnetic tape cassette containing the data about the various countries or cites. The system may also include dynamic RAM with capacity of around 5MB-lOMB.
The country tape cassette would be loaded into the system just once, or when the vehicle travels to a different country. The city memory uni~t would be 7 1~4~2 loaded into the dynamic RAM before "data verification and fixing" (only if changing zone). If the journey were between two different zones stored in two differ-ent tape cassettes, the data about the zones will be loaded into the dynamic RAM from each tape cassette separately for "data verification and fixing: and "path outline" stages.
For a better understanding of the invention, and to show how the same may be carried into effect, reference will now be made by way of example to the accompanying drawings which show preferred embodiments of the invention:
BRIEF DESCRIPTION OF THE DRAWINGS
FIGURE 1 is a schematic diagram of a vehicle naviqation system in accordance with one embodiment of the invention;
FIGURE 2 is a schematic block circuit diagram of apparatus for use in a vehicle navigation system according to Figure 1, the Figure comprising Figures 2a, 2b, 2c, 2d, 2e, 2f, 2g, 2h, 2i, and 2j, the various Figures being combined together as shown in Figure 3;
FIGURE 3 is a diagram showing how the Figures of Figure 2 are assembled together;
FIGURE 4 is a main program for operating a microprocessor forming part of the system illustrated in Figures 1 and 2;
FIGURE 5 is a flow chart illustrating steps to determine start and destination:
FIGURE 6 is a flow chart illustrating start junction determination;
FIGURE 7 is a flow chart illustrating desti-~ nation junction determination without receiving cross : street information from the user:
FIGURE 8 is a flow chart illustrating a : 35 process for a general path outline ~route establishing means);

:

,~

8 12~641'Z
FIGURE 9 is a flow chart illustrating the process for generating a path outline within a single region;
FIGURE 10 is a flow chart illustrating the process for generating a path outline between any two regions;
FIGURE 11 is a flow chart illustrating the path outline procedure for any level including individual process steps for determining an entire route using a path outline;
FIGURE 12 is a flow chart illustrating the sequence of progress between adjacent junctions;
FIGURE 13 is a flow chart illustrating the relationship between a path outline (route establishing lS means) and sequence action data processing (first processing means);
FIGURE 14 is a flow chart illustrating the first process of the flow chart of Figure 13 whereby relevant route outline data is fetched;
FIGURE 15 is a flow chart illustrating the FINDBLK (find block for route information between two junctions) subroutine of Figure 14;
FIGURE 16 is a flow chart illustrating the 2JNCFIND (two junction/find) subroutine of Figure 15;
FIGURE 17 is a flow chart illustrating the LGLCHK (legality check) subroutine of Figure 12:
FIGURE 18 is a flow chart illustrating the CALCD/KL (calculate D/KL) subroutine of Figure 17.
FIGURE 19 is a flow chart illustrating the ROADBLK (the data related to the functions of Figure 15) subroutine of Figure 15;
FIGURE 20 is a flow chart illustrating the PRCSS 2 (sequence action data processing of the first processing means) subroutine of Figure 13;
FIGURE 21 i8 a flow chart illustrating the NXTACTBLK (next action block) subroutine of Figure 20;

g lZ96412 FIGURE 22 is a flow chart illustrating the MSTKSNC (mistake calculation for synchronization) subroutine of Figure 21;
FIGU~E 23 is a ~low chart illustrating the SNK~LR (user synchronization block) subroutine of Figure 22;
FIGURE 24 is a flow chart illustrating the SNCMSGPRC (synchronization message processing) subrou-tine of Figure 23;
FIGURE 25 is a flow chart illustrating general control over a route under the routine named PTHIMP (path implementation);
FIGURE 26 is a flow chart illustrating the interrupt handling of the distance measuring means in connection with the routine of Figure 25:
FIGURE 27 is a diagram illustrating the synchronization possibilities according to the inven-tion, including status flags (status of action data);
FIGURE 28 is a diagram illustrating momentary speed flags as referred to in Figure 34, including an update. Action road counter enable ~lag to indicate when the previous action involved automatic synchroni-zation;
FIGURE 29 is a timing diagram illustrating a cycle between two landmarks in the absence o~ automatic synchronization and assuming no errors;
FIGURE 30 is a timing diagram illustrating a cycle between two landmarks when automatic synchroniza-tion is needed but not employed;
FIGURE 31 is a timing diagram illustrating a cycle between two landmarks when automatic synchroniza-: tion is employed;
FIGURE 32 is a timing diagram illustrating a cycle between two landmarks illustrating manual syn-chronization:

i2 FIGURE 33 is a table illustrating counter requirements in accordance with one embodiment of the invention;
FIGURE 34 is a flow chart illustrating the interrupt handling processes of Figure 26 and the routine for checking momentary speed;
FIGURE 35 is a flow chart illustrating a specific embodiment of a PTHIMP (path implementation) routine for figure 4;
FIGURE 36 is a flow chart illustrating the lACTN (one action block) subroutine of Figure 35:
FIGU~E 37 is a flow chart illustrating the SLFTST (self test) subroutine of Figure 36;
FIGURE 38 is a flow chart illustrating the lS SYNC (synchronization) subroutine for manual synchroni-zation in accordance with Figure 32;
FIGURE 39 is a flow chart illustrating the INACNTR (instruction of action control) subroutine of Figure 36:
FIGURE 40 is a flow chart illustrating the SPDST (speed and distance) subroutine of Figure 36 used in accordance with the vehicle speed and distance to a junction;
FIGURE 41 is a flow chart illustrating the speed (vehicle speed checking) subroutine of Figure 40 to work in Connection with Figure 34;
FIGURE 42 is a flow chart illustrating the CNTJNC (control distance to junction) subroutine of Figure 39;
: 30 FIGURE 43 is a flow chart illustrating the CNTRL ~control distance) subroutine of Figure 42;
FIGURE 44 is a flow chart illustrating interrupt for exchanging display in conjunction with Figure 43 and Figure 45;
: 35 FIGURE 45 is a flow chart illustrating the AUTSYNC (automatic synchronization around a junction) subroutine of Figure 42;

:;

2~ 2 FIGURE 46 is a flow chart illustrating the UNENSNC (distance control until synchronization is enabled) subroutine of Figure 45:
FI&URE 47 is a flow chart illustrating the ENSNCNT subroutine of Figure 45 specifying how data generated by an angle sensor or a turn detecting means is employed to synchronize vehicle position with a junction using an action round counter:
FIGURE 48 is a flow chart illustrating the PRPNXAC (preparation for the next action subroutine of Figure 35 wherein the process update action road counter is employed;
FIGU~E 49 shows various types of left turns;
FIGURE 50 illustrates steering wheel opera-tion during a left turn;
FIGURE 51 is a graph of the product of steering angle and vehicle speed against time to illustrate the integration process for the three different turns illustrated in Figure 50a;
FIGURE S2 is a flow chart illustrating the SNCUSRPRC (synchronize user procedure) subroutine for checking mistake processing;
FIGURE 53 is a flow chart illustrating the CRCLWEEL (distance to circulation for wheel transforma-tion) subroutine of Figure 21;
FIGURE 54 is a flow chart illustrating the : INSTJNC (initial instruction from user) subroutine of : Figure 4 illustrating operations from the point of view of a vehicle operator;
FIGURE 55 is a flow chart illustrating the FRINST (first instruction) subroutine of Figure 54;
FIGURE 57 is a flow chart illustrating the :~ ~ IEREA (one area) subroutine of Figure 56;
FIGURE 58 is a flow chart illustrating the TRYAGN (try again) subroutine of Figure 57;
FIGURE 59 is a flow chart illustrating the ; OTHINST (other instruction) subroutine of Figure 54;

~2~&4 12 FIGURE 60 is a flow chart illustrating the STRTJNC (start ~unction) subroutine of Figure 59;
FIGURE 61 is a flow chart illustrating the PRPSJNC (proposed destination junction) of Figure 59;
FIGURE 62 is a flow chart illustrating the PTHECP (path data exception) subroutine of Figure 61;
FIGURE 63 is a flow chart illustrating the RFCPNT (reference point coordinate verification and determination) subroutine of Figure 54;
FIGURE 64 is a flow chart illustrating the RITCST (read in title of cassette/plug-in unit) routine for verifyinq that the proper map data has been sup-plied;
FIGURE 65 is a flow chart illustrating a first DSKBST (display keyboard status) routine to determine whether there are more instructions to accept and to ensure proper display of information to and operator; and FIGURE 66 is a flow chart illustrating a second DSPKBST (display keyboard status) routine showing greater detail than in Figure 65.
FIGURE 67 is a block schematic diagram illustrating the part of the system performing control over the route;
FIGURE 68 is a functional block schematic diagram of an embodiment of the system according to the invention; and FIGURE 69 illustrates path implementation schematically.
~: : 30 FIGURE 70 is a flow chart illustrating the -; ~ CHKDN (checX if done) routine of Figure 38.

DESCRIPTION OF SP~CIFIC EMBODIMENTS
GENERAL DESCRIPTION
~: 35 Before embarking on a detailed description of the system, it will be useful to give a generalized description of the system operation.

: ~

:
:~ ' ' :~

13 3~2~4 12 Geo~ 5~ gy ~ 4~
Reference will first of all ~e made to figure 1 which is a diagrammatic representation of apparatus used in the navigation system according to one embodi-ment of the invention. Figure 1 illustrates a central processing and control unit 1 having an input slot for receiving a memory unit la which will contain data representing streets, roads, junctions and other landmarks, etc. The unit 1 is connected to a display unit 2 and a portable keyboard 3 for input of data.
Furthermore, the system comprises a distance sensor 4 operably associated with the wheels of the vehicle, and an angle sensor 5 provided in the steering mechanism of the vehicle indicating front wheel angle. Unit 1 receives data from the sensors 4 and 5 to determine the distance travelled by the vehicle, and the angle turned through by the vehicle. Optionally a compass may be provided to determine absolute orientation of the vehicles with respect to magnetic north at selected positions such as at the starting landmark.
In the preferred embodiment the compass 6 is used only to preset the vehicle orientation relative to the starting landmark before commencement of a journey.
During the journey, the unit 1 then operates solely on data continuously received from the distance sensor 4.
However, in a window distance around a landmarX, the unit 1 operates both as data continuously received from the distance sensors and on continuously received data from the angle sensor 5. This is sufficiently accurate since the unit 1 operates on the assumption that the vehicle is travelling only on recognized highways and roads. This enables the unit 1 to compensate for minor errors in positioning as will be explained in detail ; hereinafter.
As far as the user i5 concerned, he drives the vehicle in the normal manner but follows instruc-tions which appear on the display unit 2 and further ~2~;4~;~

instructions which may be supplied to him by spoken commands reproduced from magnetic tape or from a speech synthesizer. once the system is set up, and is provided with data defining the initial vehicle position and orientation, the first instruction appears on the display unit and is preferably arranged to flash and generate an audible bleeping sound before the instruc-tion has been carried out. After the instruction has been executed, the second instruction is displayed and this process is continued until the vehicle reaches the desired preset destination.
Each instruction will include guidance information and the name of the current street in which the vehicle is located. At every passage of the vehicle through a main intersection or junction, the user is notified of the intersecting street name and guidance information is presented both on the display and by means of an audible command of "left" or "right" or "forward", (although the "forward" command may be omitted). Independence upon the vehicle speed, the guidance instruction will be supplied to the driver at a greater or lesser distance from the intersection.
Preferably, at 30 kilometers per hour the instruction will be supplied to the driver at 50 meters from the junction, in the range from 30 to 60 kilometers per hour, an additional 10 meters will be added t the warning distance for every 5 kilometers per hour and in the range from 60 kilometers per hour upwards larger additions will be made so that, for example, at 90 kilometers per hour the warning distance will be 750 meters.
In the same way, the system may be utilized to provide a warning to check other items which vary as a function of the distance travelled by the vehicle.
For example, a warning to change oil or to regularly check the oil each several thousands of miles. the system can also be given an indication for calibration or other checks ~or the navigation system (e.g., for calibration of the angle sensor).
As an additional feature, in addition to the navigation function, the system may be utilized to provide a warning to check the vehicle tires for wear.
In other words, the system may provide the user with an indication of the total distance through which the individual tires have travelled and upon reaching a preset distance, such as 30,000 kilometers, the system may remind the user to chec~ the tires.
Before the driver sets out on his journey, the system may be placed in a self-test mode which indicates that the system functioning is normal. The self-test mode provides testing of the memory, the display, the key board and the input output facilities.
During travelling, normality of the system may be tested by making a comparison between the output of two sensors installed respectively to measure the speedome-ter reading ~perhaps not the normal vehicle speedome-ter) and to count wheel revolutions.
If during the course of his journey, the userbecomes aware of unusual traffic situations or blocked roads, or decides to choose a particular road for part of his journey, he may insert information through the keyboard to inform the system that a particular road either should or should not be used as part of the route. The system will then operate to select a new route taking account of the inserted information.
As will be apparent, distance travelled by the vehicle is determined basically in accordance with the number of wheel revolutions. In order for this measure to be accurate, it is clearly necessary to know the circumference of the wheel fairly accurately. A
scaling factor between the distance and number of wheel revolutions may be preset into the system memory by the manufacturer or assembler of the system. Preferably, the scaling factor will be sufficiently accurate that 16 1 Z ~ 2 the distance will be determined to an accuracy repre-senting one wheel revolution in SOO kilometers. For this purpose, it is necessary to have three different scale factors in dependence upon the type of tires employed, which may be summer tires, winter tires or tires provided with chains for use in icy conditions.
The system may also provide means to enable the user to correct the scaling factor. This may be achieved by measuring the number of wheel revolutions counted by the system as the vehicle drives over a predetermined measured map distance. This allows the system to take account of any mechanical changes in the vehicle or any errors caused by a particular idiosyn-cratic manner of driving. For recalibration of the lS scaling factor, a distance of at least 20 kilometers should be employed. It may be recommendable to check the scaling factor every 5,000 kilometers. In order to achieve an error factor of one wheel revolution per 500 kilometers, it is necessary to employ a scaling dis-tance of at least 20 kilometers if the distance sensor(for instance a shaft encoder), is counting 2S pulses per wheel revolution.
In order to achieve this accuracy, it is very important to start and finish the scaling from exactly defined points. It would also be recommendable to employ a longer distance than the minimum required (i.e. longer than 20 km). This error factor has a direct effect on the total error of the system of one wheel revolution per 500 kilometers and, this effect is rather minor. Other factors will have more effect.
It would however be possible to carry out automatic scaling as follows:
This scaling would be done over a "scaling distance", which would not be less than a "minimum distance" determined in advance. The scaling shall be ~ done between two junctiong, where the system will ; synchronize itself as hereinafter described. These two ~C~12 synchronization points would be the start and the finish points of the scaling. There will be some tolerance as a result of the way these two points are defined ~since the angle sensor is quite limited, it would not be possible to start and finish the automatic scaling function from exactly defined points). These tolerances will be added to the error of the scaling factor for the distance that was employed by the scaling function. Because of this, it would of course be preferred to employ a long distance, such as 500 kilometers, for this function (so that the total error will be no more than one wheel revolution plus the tolerances for a distance of 500 kilometers). Since most journeys are not very long, and the automatic scaling would be done over one journey, it would be appropriate to employ a shorter distance for this function (e.g. 50 km). After one automatic scaling function has been completed, the scaling factor result will be stored in the system as an updated scale factor. The system will start searching for a new scaling factor automatically, and when a new scaling factor has been found, it will again be stored into the system as an updated one, etc. It would be possible to compute more than one scaling factor during one jour-ney. It would also be possible to compute no scalingfactors during some of the journeys. However, the last scaling factor that is computed will be stored in the system and will be considered as the updated one. In addition to the scaling function, the automatic scaling will continually compensate for systematic errors. All of the systematic errors will have determined effects on the total accuracy of the system, and they can be much smaller as a result of this function. Systematic errors would be caused, for example, by a style of driving (e.g. frequent overtaking), or by changes in the mechanical condition of the vehicle (e.g. air pressure of the tires).

4i2 Implementation of this function will be done by employing two counters: the first will keep track of the distance travelled by the vehicle, as it appears in the memory, and the other counter will count the number of wheel revolutions (or a certain number per wheel revolution) over this distance. The counters will stop counting after the first has reached at least the minimum distance (determined in advance for this purpose). The scaling factor will be the distance which was counted by the first counter, divided by the result in the other counter.
The counters will start counting again at the same synchronization point. If by the end of the journey the first counter has reached at least the minimum distance (e.g. 50 km), and then the system has synchronized itself, a new scaling factor has been computed. If not, the counters will be zeroed and will start counting on the next journey, at the first automatic synchronization point.
It is also necessary to preset into the system a scaling factor representative of the ratio of the angle of the front wheels relative to the vehicle axis and the angle through which the steering wheel has been turned. This scaling factor is also preferably preset into the system memory during manufacture or assembly of the system. Again, the scaling factor may be preset by the user. This may be necessary if the steering wheel system i8 changed or if changes occur in the mechanical properties of the vehicle. The scale factor is selected in dependence upon the maximum steering angle. The angle through which the steering wheel is turned from one side to the other gives an indication of the wheel angle relative to the steering wheel angle. It may be recommendable to calibrate the angle scaling factor every S,000 kilometers.
During operation of the syste~, preferable a data processing operation and test operation is executed once every travelling period between two landmarks.

~2~ 2 Distance data is added to road counter for forward and reverse driving and during this process the outputs of two sensors are compared for improved reliability. For a map of scale 1:1250, and with a measuring accuracy of + 12.5 centimeters will occur for any distance between two landmarks. Although in a city like London, which has relatively flat terrain, height deviations give rise to no significant errors, in a city like San Francisco the height deviations must always be take into account. In practice, a measured distance accuracy of 0.02% may be achieved.
As the vehicle travels along a predetermined route, the measured vehicle location is regularly synchronized with the actual vehicle location so that errors are never allowed to accumulate excessively.
This may be achieved by automatic synchronization whenever the vehicle turns through a predetermined angle as measured by the turn sensor at a recognized intersection or junction. Every time calculation indicates the actual vehicle location error to be possibly more than 40 meters, the user may in addition be required to synchronize the system manually at a predetermined landmark. By this means, the deviation calculation may be zeroed. If the user does not synchronize the system when required to do so, the system would nevertheless maintain its normal activity and would ask the user to effect synchronization at the next available opportunity. such manual synchroniza-tion would normally be unnecessary, because the regular automatic synchronization should be sufficient.
Man-machine interface The interface between the driver and the system will now be described in more detail.
; Data entry is effected by the user under system guidance and control. The data entry stages are as follows:

2 0 ~_R~
A. The user presses a "reset" Xey and the system displays the request "name of present loca-tion?". Preferably, the user will be able to choose any one of three preset positions which may represent home, place of work etc and may simply insert "start"
and then enters a digit 1,2 or 3 and then the "enter"
key. The system then advances to stage G described below. As an alternative, the user may enter a name code for a particular area and press the enter key.
The system will then verify the existence of the area and will then advance to stage B.
B. It is necessary to begin the route at a recognized junction. Therefore, the system displays a message such as "drive to the first right hand junction on this road". When the user reaches this unction, he depresses the "enter" key and then the system advances to state C.
C. The system displays a message request "name of present road?"
The user then inserts the name of the road or street and presses the enter key and the system then requests:
"name of right intersection road?".
The user inserts the street name of the riqht hand intersecting road and presses the enter key. The system then checks the possibility of setting the current position as the junction defined by data entered in stages A and B and then advances to stage E
if this is possible. If it is not possible with the data received the system advances to stage D.
D. If the junction setting is impossible on the data received in stages A and 8, the system dis-; plays the message:
"drive to the next right hand road junction".
When the user has reached the next j ~ ction, he presses the enter key and the system then re ~ rns to stage C
and the sequence is repeated.

~l2~ 2 E~ The system displays the message request:
"are you behind the junction? -enter yes or no"
The user inserts the appropriate response and then depresses the enter key.
The system will then display the message:
"how large is the distance from the junc-tion?".
After the distance has been entered in appropriate units, which may be adjusted in accordance with user requirements, the user will again depress the enter key.
F. In this section of the program the system will set the starting junction. This is de-scribed in more detail under "data verification and fixing".
G. The system displays the message:
"name of intended destination area?".
After the desired destination area has been entered, the user will again depress the entry key.
H. The system displays the message:
"choose route or place"
The user chooses whether he is to enter information selecting a route or a specific place. Following this selection, he presses the entry key. If the user has selected "route", the system advances to section I. If he has selected "place", the system advances to section J.
I. The system displays the message:
"name of intended destination street".
The user enters the name of the street and depresses the entry key. The system verifies the existence of the street (as described under data verification and fixing) and moves to stage K.
J. The system displays the message:
"type of placen.
The user enters data such as "restaurant" or "hotel" and depresses the entry key. The system i2 verifies the existence of the place as described under data verification and fixing.
The system then displays the message:
"name of intended destination place".
The user enters the name of the place and again de-presses the entry key. The system verifies the exis-tence of the place and sets the relevant "final junc-tion". This again is described under the section "data verification and fixing".
K. The system displays the message:
"is there any road you wish to use? -answer yes or no".
The user enters the appropriate response and depresses the entry key. If the user response is negative, the system advances to stage M.
L. If the user response is positive, the system displays the message:
"insert road:
from to: "
The user inserts the appropriate data and depresses the entry key.
The system then displays the message:
"others? -answer yes or no".
If the user response is positive, the system returns to step L. If the answer is negative, the system advances to step M.
M. The system displays the message:
"any road you wish to avoid?"
If the user response is positive, the system advances to step N. If the answer is negative, the system advances to step O.

N. The system displays the message:
"insert road:
from:

23 ~ 2 9 6 4 12 to: ~I
The user inserts the required data and depresses the entry key. The system then displays the message:
"others? answer yes or no".
If the user response is positive, the system returns to step N. If the answer is negative, the system advances to step o.
O. The system advances to the route marking out stage referred to hereinafter as the path outline stage.
Data verification and fixing Data verification is carried out in parallel to entry of data by the following steps:
A. Verification of the zone name. In the case of a place, the place name and type will be verified as soon as they are entered.
B. Setting of the start junction and its data verification will be carried out after entry of all the data defining the start junction.
C. Setting of the end junction and its data verification will be carried out after setting of the start junction and entry of the end junction data.
D. During the data verification stage:
1. The system will check if the inserted names are correct. In the event of a wrong data entry, the system will display a suitable message with the remark:
"try again"
2. The system will guide the user with a request for insertion of an appropriate cassette by displaying the message:
"put in cassetts number xn.

3. The system will check that the correct cassette was entered. In the event of a mistake, it will display the suitable announcement ; again, adding the remark:
"try againn.
:

As soon as data verification and fixing has ended, the system will display the messa~e:
"wait"
Route determination and data processing As soon as the verification and data fixing stages have been concluded, the system will process and determine the route and will display the message:
"Journey time at average speed X miles per hour will be Y minutes 10start now"
The user will depress the "enter" key or begin driving.
The system will then advance to the route completion stage.

Route completion During the drive, the system will monitor the vehicle location and, accordingly, will guide the user.
In the event of a deviation from the preselected route, such as overrun of a turn due to a driving error or desire to take a different route, a warning signal may be given by means of a buzzer and/or a warning lamp.
If desired, the system can determine a new route, taking account of the route deviation.
During the route guidance process, the next instruction will always be displayed on the display screen. When the instruction has been completed, the user will depress the "enter" key or, the system itself may assume that the instruction has been completed in response to determination that a particular distance has been driven. After each instruction has been completed, the instruction will vanish from the screen and the next will be displayed, until the desired destination has been reached.

; 35HARDWARE DESCRIPTION
The system whose operation and functioning has been described in general terms in the foregoing 11 2~64`~2 may be implemented by means of the hardware illustrated in Figures 2a ~o 2J and 3. As will be noted, the hardware basically consists of a plurality of inteqrated circuit and other modules which include, in addition to a 10 Neqahertz clock generator 201, timing and control logic 202, an address decoder 203, and various memory chips, the primary component of the system being an 8085-A2 microprocessor unit of the system. Interface logic 206, 207, 208a, 208b is provided for decoding signals received from the steering transducer ~os, and from the compass transducer 210, and the wheel revolution counter 211, 212, 213. Electrical socket connectors 214, 215, 216, 217, 218 are provided for receiving electrically programmable read only memory chips (EPROMS) 219, 220, 221, 222, 223 each of which contains data representing a road or street map. The data is stored in these EPROMS in the manner indicated in this specification.
Referring to Figure 2B, there is shown a memory paging subsystem for the extended memory of the plug-in units 219, 220, 221, 222 and 223, comprising end block control 224 and a read cycle enable machine 22S receivinq input signals regarding the status of the cycle from the CPU control bus. This is a unique feature of small microcomputers. This subsystem allows ~ expansion of the available memory beyond the 64k limit.
- Referring to Figure 2C, a processing ram 226 is connected to the CPU bus, specifically address data and control. This is the non-volatile memory supporting the CPU functions.
There may be optionally included an indexes and tables EPROM 227. The indexes and tables EPROM 227 provide the global indexing of the EPROMs 219, 220, 221, 222 and 223 containing localized map information with reference to the cassette numbers or places wherein the information is stored. If the system does ;

12~6~i2 not required global indexing, this memory unit is not needed.
RAM 228, herein the landmark and actions ram 228, is provided for storing the landmark information and action information, typically in table form, for use in issuing instructions when a landmark is approached.
RAM 228 contains all information related to a cycle, that is a trip segment between landmarks, including the seguence data generated by the route esta~lishing means.
A program timer 229 operates in response to timing and control logic 202 (Fig. 2A) to issue programmed time signals (TRLL) five seconds delay time for display exchange, 10 milliseconds for general interrupt, and lS 100 milliseconds for a distance sampling. The program time 229 also receives gate signals indicating a junction or landmark enable controlled by the software (Figs. 43, 44 and 45, for example) and illustrated in Figures 29 through 3 2.
Referring to Figure 2D, elements are provided to provide the external bus in connection with the paging system.
Figure 2E illustrates the I0 ports 231 for the keyboard 3. Cassette number is provided from the memory units 222 and 223 to port 232 of the I0 port unit 231. As previously explained, units 222 and 223 are insertable units as, for example, memory unit lA of Figure 1. The shaft encoder 209 receives its input from the steering mechanism of S (Fig. 1). The compass interface 210 receives its input from an electronic compass 6 (Fig. 1). As previously noted, the compass is not necessary for operation in accordance with the invention.
Figures 2I and 2J illustrate the display inter$ace for a specific embodiment of the invention, including light and character generator as well as ~Z~64i2 audio alarms. The details of this are not essential to the understanding of the invention.
Figure 3 shows the interrelationship of Figures 2~ through 2J.
Stored in non-volatile memory 204 is a control program for operating the microprocessor. the main program for carrying out this control is illus-trated in Figure 4 and various sub- routines which form part of the main program and supplement its functioning together with timing diagrams and tables are illustrated in Figures 4 to 66, as described herein below.
For ease of understanding, Figure 67 provides a bloc~ schematic diagram which illustrates the basic functional blocks of the system employed during a journey including hardware components and functional blocks defined in the system software. A distance measuring means 671 receives inputs from a forward road counter 4a and a reverse road counter 4b (Figure 29), referred to hereinafter, and from an automatic scaling computing means 672 la software processor). It pro-vides a first output to a window enable means 673 and a second output to the automatic scaling computing means 672. A route action random access memory 674 (corresponding to RAM 228 of Figure 2c) provides data to the window 2S enable means 673 and the automatic scaling computing means 672 in response to a signal received on a sync line 675 from a turn detecting means 676. The turn detecting means receives data defining a distance window from window enabling means 673 and receives further signals representing the turning angle from an angle sensor and the instantaneous speed from a speed computing means 677. on detecting a turn which is unexpected, the turn detecting meanæ 676 produces a signal output on line 678 to cause the system to calculate a new route ta~ing into account deviation from the previously calculated route.

4i~

Referring now to Figure 68, there is shown a functional block diagram illustrating the basic func-tional blocks employe~ prior to any journey or in preparation of any new route. The signal on line 678 is supplied to a route establishing means 681 which also receives inputs from the data receiving means 682, a plug-in unit 683, if provided separately, and a compass 684, if provided at all. In response to these data and signals, the route establishing means 681 provides a data input to a first processing means 685 which generates action data blocks and supplies them to a route action RAM 686. The software enabling these various functional operations to occur will be de-scribed in detail hereinafter.
Figures 27 to 33, and Figure 49 illustrate techniques which may be employed in synchronizing or correlating the system memory with the actual location of the vehicle. Various system flags and counters are also defied and illustrated in these Figures.
Figures 34 to 48 illustrate further sub-routines which are concerned, inter alia, with synchronization or correlation of the actual vehicle location with the internally stored location of the vehicle, which the system utilizes to produce its prompt and warning messages.
Figures 50 to 51 illustrate further data and information relating to timing functions and parameters relating to the turn detecting.
Figures 54 to 66 illustrate further flow charts concerned particularly with the various routines for controlling the man-machine interface for the interactive part of the main system program.
The flow charts give explicit instructions for programming a small dedicated computer system such as illustrated in Figures 2a to 2; and 3 to implement a vehicle navigation system in accordance with the present invention. It should be noted that each :L2~412 sub-routine has a reference code such as "INSTJNC"
herein indicating "instruction acceptance for start and destination functions". This sub-routine forms the first main part of the main program illustrated in Figure 4 and is set forth in more detail in Figure 5.
This sub-routine in turn is sub- divided into further sub-routines each having its own reference code. By use of these reference codes, the inter-relationship between the sub-routines may be readily discerned.
The above described system may be simplified for special purposes, e.g., for use as a tourist guiding system for guiding tourists along a preselected route. Then of course no route computation is re-quired. It is only necessary to plug n a cassette having the predetermined route data therein. When the vehicle reaches predetermined landmarks of the route as determined by the distance sensor and the movement detection around landmarks, a message player will be enabled to cause output of a message giving information or instructions of local interest.

DATA BASE
Before discussing the operation of the system in more detail with reference to the flow charts, it is necessary to define the way in which data relating to landmarks, such as road intersections, and road names is defined in memory. For a given area, data is stored relating to each landmark such as a road intersection within that area. To indicate the location of each intersection or other landmark, sometimes also referred to herein as a junction, use is made of longitude and latitude lines present on a map from which the data is derived. The intersection of each longitude line with latitude line defines one reference point, and each landmark location on the map i8 represented by a single unique reference point. Naturally, as the scale o~ the map is increase, there is less chance that more than 129~2 one landmark wi}l be associated with one reference point. For example, in a map of London having scale 1:1250, in general there is only one landmark associate-d with each reference point. On such a map, the dis-tance between two longitude lines or two latitude linesis 125 meters. It will be appreciated that these reference points do not define the location of the landmark absolutely, but they do indicate with suffi-cient precision the location of the landmarks with reference to the map.
The use of reference points is necessary for two main reasons:
1. Where a map is divided into sub-regions, the relative location of one landmark in one region to another landmark in another region will be determined in accordance with the reference points.
2. The reference points are used to derive the direction of a destination landmark from the initial landmark of a route and to obtain a regular indication of location during the path outline proce-dure which will be described hereinafter.
Two independent data fields are defined in memory: a data field in respect of specified landmarks and a data field defining the names of the roads. The path outline procedure makes use of these two data fields.

1. Landmark ("Junction") data field The storage of the map in memory is based on one absolute identifier for each landmark such as illustrated in Table A forming part of this specifica-tion and showing a data- base format for a junction of four roads.

TA~E_a Example: Data Base Fo~mat fo~ Four Roads Junction ~yt~p Gene~L Data: Junctio~
1 (2) Number of Longitude - ~8~n~ence 2 (2) Number of Latitude (3) North Junction Number 5 (4) Distance to North Junction - _n 32 m Units _North 6 (5) Distance to North Junction - In 12.5 Cm Units - . .
7 (6) North Junction's Leading Road Definition _Speclfled 9 (7) Number of the North Junction's Leadina Road 1~1 f3) South Junction Numbçr 12 (4) Distance to South Junction - In 32 m Units 13 (5) Distance to South Junction - In 12.5 Cm Units =ROaUdh 14 (6) South Junction's Leadina Road Definition -Specified 16 (7) Number of the South Junction's Leadina Road ~8 (3) East Junction Number 1 9 f4) Distance to East Junction - In 32 m Units =East 20 (5~ Distance to East Junction - In 12.5 cm Units =Road 21 (6) East Junction's Leadina Road Definition =Specified 23 (7) Number of the East Junction Leadina Road 225 (3) West Junction Number -West 2~6 (4) Distance to West Junction - In 32 m Units _Road 27 (5) Distance to West Junction - In 12.5 Cm Units -Specified 28 (6) West Junction's Leadina Road Definition 29 (7) Number of the East Junction ~eadina Road For each junction, general data will be specified 2~nd the roads leading into the junction will be specified.
In addition, the junctions at the remote ends of the roads leading to the junction under consideration will be defined.
The definition of any junction will be according to the data base format relating to that section. The general data of 38ach junction will be defined by indexing each junction with one number (block number), by defining the level of the junction (main, central, internal etc.), and by defining any nearby central junction, which may be employed as an inter-mediate destination in the path outline procedure defined 3~ereinafter.
Roads leading into the junction will be specified by the distance between the junction under consideration and an adjacent junction, by the direction of the road, and by the type of road.
Each road junction is thus indexed in memory by a particular number, referred to hereinafter as a block ~umber. Associated with the block number for each junction, data is included which defines the level (hierarchy) of the junction together with data specifying roads entering the junction and further data defining junctions which terminate the other ends of those roads entering the junction in ~uestion. By "level of the junction", is meant whether it is a main junction, or a central junction or an internal junction etc.
The roads entering the junction are thus defined in terms of the following parameters:
a: The distance between the junction in question and the next (adjacent) junction along that road:

b: The direction of the road (optional);

c: The type of road ~motorway, A-road, 8-road etc);
5 d: Any other important factors such as no entry, bridges, roundabouts, etc.

It will be appreciated that the size of the data block for each specific junction will depend upon the number of roads 3~hich branch out from that junction. Thus, storage of the map in memory (the plug-in unit) is based on indexing each junction with one unique number. The data related to each junction is stored in one block in which the junction number is related to a CPU address line value. In other words, the 3~PU can access the data of a specific junction by setting its address lines to the junction number. The plug-in unit memory stores all the ~unction blocks which together specify one or more areas of a map (such as a city map).
Referring to Table A, the data for each junction is specified in the relevant block from the point of view of ~ person standing in the counter of the junction., For each junction, general data will be sorted including (1) general junction information and (2) longitude and latitude line numbers which together specify a reference point. In addition, for each road leading from the junction four ~urther types of information will be sorted as follows: (3) the adjacent intersection number, (4) distance to the adjacent junction in large units (most significant bits), (5) where the distance is not exactly a large unit, the distance from the closest large unit to the next adjacent unction in small units (least significant bits), (6) qeneral data concerning the road, (7) and road number.
The general junction data (1) may include informa-tion concerning the number of roads connected to the junc-tion, and whether it is a junction forming part of a closed 2~P of road.
The "large units" referred to above may for example be units of 32 meters and the "small units" may be units in terms of the measurement accuracy available when the data base is constructed, e.g., for a map of scale 2S:1250 where the measurement accuracy available is plus or minus 0.05 mm, the possible error in terms of distance between two intersections on the road is plus or minus 12.5 cm. In this case, the units will be units of 12.5 cm. Data (4) and (5) together give the distance between the intersec-3Qions.
The data (6) may include the level of the road interms of a coefficient which when multiplied by actual road distance between two landmarks linked by the road gives an equivalent straight-line distance. For example, for a main 3~oad defined as a level 1 road, the coefficient may be 0.7.
The equivalent straight-line distance for each kilometer would then be 0.7 kilometers. The use of such coefficients is necessary for the path outline stage to be described hereinafter, In addition, the qeneral data will include an indication of whether the intersecting road has a dead end, is a no entry road, permits no U-turns, or leads into a sircle. In addition, data concerning "significant turns"
wi]Ll be included for automatic synchronization. Furthermore, a road index number indicating the name of the road would be included.
The data for each intersecting road also indicates ~he direction of the road with reference to magnetic north.
This information is useful in the path outline stage to assist in determining the desired change of vehicle orienta-tion with reference to the road approaching the intersection.
As already mentioned, the actual vehicle orientation can be ~etected by the compass before the journey begins. Alternative-ly, the relative angles (or proportional numbers to the turns) between the branching roads, will be defined and included for example in the general junction data. In this connection, the possible turns for auto sync should also be 2~arked. In the preferred embodiment the resolution of the angle is only as great as needed to distinguish between various turns at a landmark.

2. Road name data The road names are defined in a data field (not shown) by providing each road with a single reference number from field 7. The association between the road number and the name is specified by a name index for the road.

SYSTEM FLAGS COUNTERS AND ACTIONS

The term "action" is used in this specification to mean the sequence of operations performed by the system during the path implementation stage between two landmarks, 3Ssually junctions. The process to perform one action is referred to as a "cycle" and corresponds the travel time of the vehicle between the two landmarks.

~2~
In order to understand the system software, it is necessary to be aware of ~he fact that various system flags are set and reset for each action during operation. These flags are defined in Figures 27 and 28. In addition, the ~ystem maXes use of various counters which are defined in the Table presented in Figure 33. Two counters are hardware counters provided respectively to count wheel revolutions during forward motion of the vehicle (Hl) and wheel revolu-tions during reverse motion of the vehicle (H2). Four ~urther counters are provided in software (i.e. storage locations of ~AM are defined by the software as counters) including a path road counter (Sl), a one action road counter (S2), a sync road counter (S3) and a speed road counter (S4). The path road counter (Sl) stores the result gf subtracting the contents of the reverse road counter (H2) from the forward road counter (Hl) and is updated at regular internals by an interrupt.
The one action road counter (S2) Xeeps tracX of the number of wheel revolutions in each action and is 2enabled at or around the first landmark (junction) of the action and reset at or around the approached landmark. The sync road counter (S3) counts the number of wheel revolutions during a window enable distance which will be discussed in detail hereinafter. The sync road counter (S3) begins to 2~ount when the distance measured by the action road counter (S2) indicates that the vehicle is within an accumulated error distance of the approached landmark (junction).
Counting is stopped when the maximum accumulated error distance is reached or before this if a sync signal is 3~eceived following a turn during this distance.
The speed road counter (S4) gives an indication of the vehicle speed by counting the number of wheel revolu-tions over a known time interval.
Referring now to Figure 27 the flags include: a 3~ync action flag 271 indicating whether a warning time is being displayed for the driver, an EN sync flaq 272 indicating whether a warning æhould be displayed for the driver, an 1;~9~4~

AUTO SYNC flag 273 to indicate whether automatic synchroniza-tion is to occur, and a SYNC flag 274 indicating whether provision for manual synchronization is to be made.
Referring to Figure 28, further flags include the ~peed request flag (speed req) 283 indicating whether a speed measurement should be effected, a "next" flag 282 indicating whether a speed measuring period is current, a speed acknowledge flag (speed ack) 281 indicating that the speed requested was measured, and an "update action road ~ounter enable" flag 284 indicating whether the one action road counter (S2 Figure 33) should be updated, following automatic synchronization.
As will be explained, in the initial stages of preparing a route, the route is divided into action sections.
~he one action road counter S2 counts the number of wheel revolutions occurring during one cycle, i.e. during one action period. It will be appreciated that the first landmark of one action is in fact the approached landmark of the previous action.
In the absence of nay synchronization method, the one action road counter S2 would in general not necessarily begin counting at the precise start of each action. By means of the synchronization process, described in more detail hereinafter, it is possible to ensure that the one 2~ction road counter S2 is reset automatically each time the vehicle passes through a junction or other landmark at which a significant movement, e.g. a turn, is made by the vehicle.

SOFTWARE EXPLAINED
The main system software is defined in Figures 4 to 25, whereas Figure 26 defines an interrupt routine.
Figure 25 defines a sub-routine PTHIMP for path implementa-tion which refers to system synchronization. However, the 3~ystem synchronization is defined in more detail with reference to Figures 34 to 48. In this connection, Figure 35 illustrates a more specific version of Figure 25. Figure ~2964 l2 34 is an interrupt routine to which reference will be made hereinafter. Figure 44 is a further interrupt routine.

Start routine Referring now to Figure 4, it will be noted that the! first main sub-routine INSTJNC (A~ is defined in more detail in Figure S which in turn includes sub-routines set forth in Figuras 6 and 7. The routine INSTJNC enables the system to receive data relating to start position and ~esired destination and accordingly to determine the vehicle start location and the desired destination. This operation is performed only once for each journey, before the journey commences. As indicated in Figure 5, after the initial landmark (junction) and destination landmark (junction) have een defined (B, C,) provision is also made to take account of any abnormal traffic density D in certain areas and to process the one-time output from the compass E. This outpost is employed only to enable the system to determine the vehicle orientation with reference to the start landmark 2before the journey begins.

Path outline The program then proceeds to the path outline processing stage, sub-routine PTHLINE F (Figure 4). This is 28et forth in more detail in Figure 8 which in turn refers to sub-routines defined in more detail in Figures 9 and 10.
Sub-routine PTIAR (G) includes two sub-routines PTLVL2 (H) and prLVL3 (I) relating to the process. These sub-routines are carried out in accordance with Figures 11, 12, 17, and 3Q8. The path outline procedure is performed in order to select a sequence of junction data blocks defining a single route from the vehicle start location to the desired destina-tion, and is illustrated schematically in Figure 69.

3~ata processing Following the path outline process (F), the data processing stage sub-routine PRCSS (J) is entered to prepare action block data and to assemble the blocks in a part of RAM called action memory. This iq defined in more detail in Figure 13. Figure 13 in turn refers to sub-routines PRCSSl (K) and PRCSS2 (L) defined in Figures 14 and 20 respectively.
~he sub-routine illustrated in Figure 14 includes the sub-routine FINDBLK (M) of Figure 15 which in turn involves the sub-routines of Figures 16 (N) and 19 (P). The sub-routine PRCSS2 (L) of Figure 20 includes the sub-routine NXTACTBLK (Q) of Fiqure 21 which in turn includes the ~ub-routines of Figures 22 (R) 23 (S) and 53 (J). In addition, the routine of Figure 22 (R) includes the sub-routine CRCLWEEL (S) defined in Figure 23. Figure 23 in turn refers to sub-routines defined in Figures 24 (U) and 52 (V).
The data processing stage P~CSS (J Figures 4, 13) gs performed in order to process the sequence data generated from the path outline stage, to prepare correct action block data for the "path implement" stage (W) which follows and to store this data in the action memory, forming part of RAM.
The path implement stage of sub-routine PTHIMP (W) 2~s defined in Figure 25. A more specific embodiment of PTHIMP (W) is found in Figure 35. It will be appreciated that this stage is performed during the vehicle journey in order to control the vehicle location over the outlined route. To enable the driver to follow the route, instruction 2~ata are fetched from the data in action memory and supplied to the driver, and errors which may be accumulated are periodically corrected. In addition, on detection of a driving deviation, a new route may be computed. Thus, the sequence "path outline, data processing, path implement" may 3~e performed more than once during a single journey.
This repetition may occur not only in the event of a driving mistake, but also if, for a long journey, the route is divided into a plurality of sections.
Finally, Figure 4 indicates a sub-routine TIRFRCTN
3~X) which takes account of tire wear by adding the total distance travelled to the precious distance to enable a ~ z~4i2 warning to be provided to the driver when the tires need replacement.

PATH OUTLIN~_EXPLAINE~

Reference will now be made to Figure 8 to define the path outline processing sub-routine PTHLINE (F) in more detail.
For full comprehension of the sub-routine of ~igure 8, it is necessary to understand that if the start location and desired destination are in different regions (i.e. different plug-in units required), the path outline stage will be performed in three sections together with computation of a path outline between respective regions, as ~ndicated in sub-routine PTMRARY, shown in more detail in Figure 10.
The path outline between the two regions (Figure 10) will normally be carried out using high level roads (level one roads), such as motorways and main roads leading 2~ cities. The path outline in the initial and final regions will normally be performed with level two and level three roads, using the routine of Figure 9. Level two roads will perhaps be main roads within a city and level three roads would be internal narrow roads within a region. All 2Sevel one roads will be specified in the country memory unit. The level two and three roads will be specified in the various plug-in units. Three possible routes 691, 692 and 693, comprising various sub-paths are illustrated in Figure 69 which represents a country amp showing three areas 3~f thxee plug-in units.
In case 1, route 691 is established after employing the path outline procedure for plug-in units 1 and 3, 698 and 695 in the context of country memory unit 696. For example, the database of the first plug-in unit 698 is used 3~o calculate a first path 699. The database for the third plug-in unit is used to calculate the third path 692, and the country memory unit 696 database is used to calculate .~

~;~964 i2 t~e second path 6910 between a landmark within the database of the first plug-in unit 698 and a landmark in the database of the second plug-in unit 695 designated point ZZ and ZY, respectively.
In case 2, the database of plug-in unit 3 contains all information necessary to compute a route. Therefore, the computation is based solely on the content of the database of plug-in unit 3. This route is between point ZY
and point ZX and, coincidentally, corresponds to the third lE~ath 692 .
In case 3, the contents of the database of plug-in unit 2697 and the country memory unit 696 are used to determine the third route 693. Information for path 4, 6911 is contained solely within the contents of the da~abase ~lug-in unit 2697. The information in the country database 696 contains sufficient information to determine routing between points within the databases to separated plug-in units, namely plug-in unit 1698 and plug-in unit 2697 along a level 1 road, herein represented by path 56912. Reduced 2~ a minimum, all paths are either computed between points within the country memory unit or between points within a database of a plug-in unit, such as a city or metropolitan area.
Following the path outline stage, instructions for 2~ short path (Z) from the start location to the start landmark (junction) will be prepared, as indicated in Figure 8. This is necessary because the path outline algorithm is operative to define a route between two landmarks which are defined in the memory unit, and initially the vehicle will 3probably not be at a defined landmark. The short path routine brings the vehicle to the start landmark to await the first route instruction.
In Figure 8, the decision block "Is path complete?"
(AA) is indicated. This is to take account of the possibility 3~hat the route may be constructed of more landmark blocks (and thus of more data) than the action memory can contain.
To allow for this, in the event that the path is not yet 12~12 complete, an "end path flag" is reset (AB), as indicated, to indicate the route is still incomplete. After the first outlined route section has been performed, the main program in Figure 4 includes the decision block "End path flag set?"
gAC) and if the flag is not set, the program will again perform the path outline (F), data processing (J) and path implement stages (W). This successions of operations is continued until the entire path has been outlined.
The sub-routine (G) of Figure 9 defining the path ~utline procedure within one region will now be discussed in more detail. It will be observed from Figure 9 that the path outline stage is divided into two main sub-stages, sub-routine PTLVL2 H2 (for path outline in the main road network) and sub-routine PTLVL3 H3 (for path outline in the ~nternal road network) which relate to the path outline procedure employing level 2 and level 3 roads, respectively.
In each case, the sub-routine is performed in accordance with Fiqures 11 and 12. The path outline process H, also called PTLVL or PTLVLl, PTLVL2 or PYLVL3, is the same 2~rocedure, differing only based on the road network level.
The main functional stages of these routines are the following (Figures 11 and 12):

A. calculation of relative distance KL (AD); (the distance 2 is calculated between two reference points).

B. determination of junction direction relative to objective junction, finding existing junction (landmark) and storing (AE, AF);

C. legality checking (AG);
.

D. takinq account of any central junction (landmark) or backward step.

~3 12~6~ ~2 The path outline process (Figure 11) involves selection of a sequence of landmarks leading from the start location to the final destination. The sequence of landmarks is selected according to the following rule:
At each landmark, the total road distance (Dl) from the start location to the landmark added to the straight line or great circle distance (Ll) from the current landmark to the destination multiplied by a coefficient K should be less than or equal to the straight line or great circle ~istance (L) of the whole journey multiplied by the coefficient K. The coefficient K is chosen to provide an estimate of the road distance to be expected between any two landmarks.
Thus, the algorithm is based on the assumption that the road distance between any two landmarks is always proportional to ~he shortest distance there between, "as the crow flies".
In Figure 12, the above-defined legality condition is expressed as "D/KL less than or equal to one", where D =
Dl + KLl. This is described as sub-routine LGLCHK (legality check) AG in Figures 17 (AG) and 18 (AH).
It will be appreciated that step AD of Figure 11 calculates the relative distance which is the maximum route length permitted and is equal to the straight line or great circle distance between the start location and desired destination multiplied by the constant coefficient.
Steps AE, AF and AG find all landmarks which satisfy the legality condition (if any) which make progress towards the desired destination and then determine the best landmark for the next step. Preference will be given to higher level intersections if there is more than one, 3~rovided that they meet the legality criterion.
If there is no legal intersection, step AH is entered so that either the route reverses by one landmark and seeks another landmark or alternatively determines the closest central landmark as an intermediate desired destina-3~ion. As already mentioned, the data block for each landmarkdefines the landmark or junction number of the closes central landmark (Table A).

43 ~ ~ ~ 6 4 12 DAT~ PROCESSING EXPLAIN~

The data processing step (J) will now be considered in more detail.
During the path outline step (F), the numbers of the landmark blocks which define the outlined route have been stored into particular locations of RAM according to the sequence of the route. In addition, a landmark junction or counter 141 (Figure 14) has been set to the number of ~andmarks or junctions which constitute the route. The junction counter 141 is a software counter associated with steps AE and AH of Figure 11.
These date, i.e., the contents of the junction counter 141 and the number of the landmarks, form the input ~ata for the data processing step J (Figure 13). The data processing step (J) is divided into two main sub steps K and L. During the first substep K (illustrated in Figure 14), the relevant junction block data is fetched from a p~ug-in unit, processed and stored according to the order in which 2~he landmarks are to be visited during a journey. The data block for the first road interconnecting the first two landmarks will be processed and stored. The junction counter 141 will be decremented, and the data block for the next intersecting road interconnecting the next two land-2~arks will be fetched, processed and stored, the junctioncounter 141 will again be decremented, and this process will be continued until the junction counter 141 will again be decremented, and this process will be continued until the junction counter 141 reaches zero. At this point, a "end of 3~ourney" data block is prepared (AM Figure 14).
The data generated from the stages or step indicated in Figure 14 is temporarily stored in the locations of RAM
referred to as "action memory" 228 (Figure 2C). Each data block represents a road linking two landmarks. After the 3~econd sub step L of data processing the action data is stored in the action RAM 228 ready for path implementation.
Each action block contains status flags (Bl), the accumulated :~29~12 error (in wheel revolution units) B2, the distance of the action (cycle) in wheel revolution units B3, and data for display B4, as illustrated in Table B.

TABLE B
An example of an action block specifying an action.

Status Flags Bl Error Accumulated in 82 Wheel Revolut~on Units Wheel Revolutions B3 in the Cycle Data for Display B4 The status flags Bl include a turn action flag, indi-cating whether the previous action is terminated by a significant turn, which implies that the error accumu-lated may be set to zero for the current action block.Other flags important for the synchronization process are the sync, auto sync, en sync, and sync action flags. The accumulated error is referred to herein as the mistake distance. An example of the interrelation-ships between the accumulated error, the mistakedistance, and the computed distance is illustrated in Figure 70. According to Figure 70, the distance of the cycle between two landmarks is formed from the number of wheel revolutions calculated from the distance measured from the map (and therefore sub~ect to a degree of mapping error). If a synchronization operation is defined for the action, a number of wheel revolutions corresponding to the d+ of the mistake distance i8 added to the number representing the distance of the cycle, and the window enable distance is determined to be equal to the mistake distance (d+ + d-). When no synchronization is defined for the action, the computed .

. -, .

.

45 ~2~
distance of the cycle is formed only from the number of wheel revolutions indicating the distance measured from the map.
There are four computed distances: the error accumulated, the mistake byte and window enable distance length, the computed action distance, and the window start point for synchronization enabling.
The error accumulated is a distance computed as a function of map distances measurements and the assumed systematic errors during the journeys. It may be expressed, for example, by the following equations:

1. d+ = 12.5x10-2xN + (0.025/lOO)xS
expressed in meters d- = l2.5xl0-2xN expressed in meters Where d+ defines the allowable error distance before the approached landmark, assuming the vehicle could arrive at the landmark with no errors, and d- defines the allowable error distance for a vehicle after the approached landmark.
; 0.125 meters represents an error distance on a road for each landmark, where N represents the number of landmarks since the last synchronization, 0.025/lO0 represents the assumed systematic error, and S represents the distance travelled by the vehicle since the last synchronization was effected.
2. The mistake byte and window enable distance length comprises the mistake byte ~l2~3~412 and the window enable distance length separately.
The mistake byte consists of two portions: a first portion comprising the distance d+ and a second portion comprising the distance d-.
The mistake byte allows access to both distances for subsequent calculation.

The window enable distance length (WEN) may be expressed as the sum of the distances d+ and d-.
The computed action distance is provided in one of two ways, action which does not involve synchro-nization and action which involves synchronization.
For action which does not involve synchronization the computed distance is equal to the measured distance, or Dc = Dm.
For action which involves synchronization, the computed distance is equal to the sum of the measured distance plus the error distance before the approached landmark, or Dc z Dm + D+. The computed distance dc is as stored in the action ram, dm is the distance between the two landmarks of the action as indicated by map measurement without taking into account any accumulated distance or errors in travel along the map path. The value dc is paired with the value obtained from the one action road counter during one cycle.
The window start point for synchronization enabling is the value at which the one action road counter enables the window. This value corresponds to the distance dm as previously defined. Thus, the window enable synchronization should occur at the distance before the approached landmark d+ assuming no errors in distance measurement by the one action road counter.
The second sub step L of data processing will now be described with reference to the drawings.

, Referring first to Figure 20, this flow chart indicates that for each action block of data the sequence of steps Q illustrated in Figure 21 is carried out in turn. The first main block of the sub-routine Q
of Figure 21 is sub-routine MSTKSNX R. The individual steps of this sub-routine R are illustrated in detail in Figure 22. As will be seen, the first major step of this sub-routine R is a decision box AJ to determine the status of the mistake b~te for this action by checking whether the previous action involves an automatic synchronization (when the turn action flag is set). If the flag is set the routine proceeds to "set mistake byte to 5 meters AL". Thus, if the previous action involves automatic synchronization, the mistake distance (i.e. the accumulated error) is set to an initial constant value, in this example 5 meters. This constant rapresents the possible distance of the vehicle from the center of the landmark from the point on the road where the turn is to be detected.
If on the other hand no synchronization is to take place at the previous landmark, the accumulated error is updated and added to the number stored as the mistake distance. The error is updated in two re-spects: in respect of error derived from the map measurement (AM) and in respect of error dependent on the distance travelled over the action (AN). It is then checked whether the accumulated error has reached a predetermined value AO, in this example 50 meters.
If it has, the status flags are updated to indicate that manual synchronization is to be effected, as set forth in sub-routine SNCBLX illustrated in Figure 23.
Figure 23 in turn refers to sub-routines defined in Figures 24 (AQ) and 52 (AR).
As will be seen from Figure 24, the first few operations have the effect of checking whether a turn is to be carried out within a range of 500 meters from the current junction. If no turn is to be expected, ~ z~

the closest junction in the forward direction having a distance from the current ~unction of at least 500 meters is determined. The status flags are updated to cause the driver to be warned to carry out manual synchronization, i.e. the "ENSYNC" flag is set (45).
If a turn is expected within a range of 500 meters from the current junction, a manual sync will not be required. The sub-routine illustrated in Figure 52 then processes the data generated from the sub-routine illustrated in Figure 24. Having completed the su~-routine MSTKSNC (R), as illustrated in Figure 21 the program then proceeds to sub-routine CRCLWEEL (S), illustrated in more detail in Figure 53. As indicated, both the distance of the action and the accumulated error are transformed into a number of wheel revolu-tions indicated by the variable "WHEELS" and the variable d+ is defined in Figure 70. The data is then prepared for display and then the data is organized in appropriate format for the path implement stage (PTHIMP) (W) of Figure 4.
The variable "WHEELS" mentioned in Figure 53 when the action involves synchronization is formed from the number of wheel revolutions extracted from the distance as measured from the map plus the number of wheel revolutions extracted from the positive accumu-lated error distance (d+).
The window enable distance is determined to be equal to the accumulated error distance (d+ + d-), and the synchronization signal is able to be accepted when the vehicle is traversing this window distance.
When the distance measured by the distance sensor indicates that the vehicle is within the accumulated error distance from a synchronizing turn, the window is opened and remains open during the period that the vehicle traverses through the window distance or until a sync signal is received.

~2~12 PATH ROAD COUNTE~ ~PDATF

Before describing the path implementation process and synchronization operations during the journey, reference should be made to Figure 34. This Figure illustrates an interrupt routine (BA) which interrupts the path implementation sub-routine PTHIMP
(W) at regular constant time intervals during system operation. A hardware timer (shown in Figure 2a as "timing and control logic" 202 Int RST 7.5) interrupts the CPU 205 in order to permit reading of the forward road counter 211 (Hl) reverse road counter 212 (H2) (Figure 2g and 33) connected directly to the road sensors 4a and 4b. The path road counter (BB Figure 34 and Sl Figure 33) is then updated according to the contents of the hardware road counters 211, 212. The hardware road counters 211, 212 begin counting at the beginning of the journey and are reset at the end of the journey. If the "speed request" flag is set (BC), the interrupt routine also computes the vehicle speed proportional value as indicated by the speed road counter (BD).
In summary, the purpose of the interrupt routine (BA) illustrated in Figure 34 is to regularly update the path road counter (BB, 51) in respect of the wheel revolutions travelled by the vehicle during the journey, and to update the speed road counter (S4) when requested.

SYSTEM SYNCHRONIZATION

The synchronization method according to the invention is illustrated schematically in Figure 27 and 29 to 32. In each if Figures 29 to 32, the first line Z91, 301, 311, 321 represents assumed location and the second and third lines 292, 293; 302, 303; 312, 313;
322, 323 represent measured location. In Figure 32 the ~2~36~2 fourth and fifth lines 324, 325 also represent measured location.
The upper part of Figure 27 illustrates first of all a typical example of the manual synchronization method performed over a series of four landmarks. The enable sync flag is set for 500 meters from the land-mark where synchronization is to be effected. The sync action flag is set for the last two a landmarks. The related software is illustrated in Figure 38 (BD) (which illustrates the "sync control" sub-routine ~BD) of Figure 36 and in Figure 70 which is a "check if done" CHKDN (BE) sub-routine of Figure 38 and the relevant timing appears in Figure 32.
Figure 27 part B also illustrates diagram-matically the automatic synchronization mode in which the system waits for a synchronization signal during the estimated turning period, referred to as the window enable distance. Figure 38 and the relevant timing appears in Figure 32.
Figure 29 illustrates a cycle without auto-matic synchronization, assuming no errors. Landmark 1 thus occurs precisely at the end of the distance monitoring period.
Reference will now be made to Figures 30 and 31 which illustrate automatic synchronization. At landmark zero, at the tie T1, the action road counter begins coun~ing the number of wheel revolutions. In parallel to this, the vehicle speed is checked. This process continues until the time T2 when the vehicle is close enough to the approached landmark (landmark 1).
At that time, the action instruction (usually a turn instruction) is emphasized for the driver. This display continues until T4. From the time T2, the vehicle location is monitored by counting the wheel revolutions and comparing to the distance as computed during the data processing stage, and illustrated in Figure 53. In Figure 30, where no synchronization 5~ 4i2 takes place (perhaps because the driver missed the turn), this process continues until the time T4 when the measured distance indicated by the action road counter equals the total computed distance of this action as stored in the action memory. In Figure 31, automatic synchronization takes place at time T3 before T4 is reached. If an automatic synchronization is to take place, the process continues until the instant when the measured distance as indicated by the action road counter added to the distance indicated by the accumulated error (d+) equals the computed distance stored in the action memory. The distance window (d~ + d-) is opened to await a turn after the vehicle has traveled the distance DM as measured from map. If a sync signal is received, the process stops, as indicated at T3 of Figure 31. At the time T3 (if sync is performed) or thereafter (if no synchronization is performed) the next action block is fetched from the action memory for the next action. The action road counter is reset to zero and begins counting the wheel revolut ons for the forthcoming action. A trigger signal is provided to a hardware timer (indicated in the figures as "time control") for a ~onstant time in order to provide a further period for the display before it is exchanged by dat2 for the next cycle.
Figure 32 similarly illustrates manual synchronization. Landmarks zero and one are two landmarks between which the action of manual synchroni-zation is performed. At landmark zero, the action road counter begins counting the number of wheel revolut-ions. At the time T2 when the distance measured by the vehicle indicates that the vehicle is now at a distance away from the approached landmark equal to the mistake distance, the system enters the waiting enable mode for a period corresponding to the computed distance dl ~ d-.
This is the only time when the system is enabled to accept the synchronization signal caused by the user.

When the synchronization signal is accepted, the action road counter is set to zero (or a constant number representing the distance of the vehicle from the center of the intersection, e.g., 5 meters), and the vehicle is considered to be at the approached landmark.
T4 represents the point where the vehicle would be if manual synchronization was not effected.
T3 represents the time when the vehicle reaches the approached landmark. As shown in Figure 32, when synchronization has been executed the distance control stops exactly at the time T3. Also, as shown in the Figure 32, if synchronization is not executed, the distance control will stop only after the mistake distance period has lapsed, at the time T4.
When the time control period has lapsed, the CPU is interrupted to exchanqe the display. Below is a Table C illustrating the main operations during an action cycle, with reference to the timing T2, T3, and T4 of Figures 29-32.
TABLE C

T2- Emphasis "User Output" for coming action (instruction) for execution.
T4- Output updating for user.

: T3- 1. Preparation for next action.
~ 2. Fetch block of next action.
; 3 0 3 . Next action cycle taXing care of.
4. Giving trigger to timer which counts the "user output's" emphasis time, before display exchange.

:

12964~2 PATN IMPLEMENTATION

Reference will now be made to the path implementation process in more detail with reference to Figures 34 to 48. It has already been mentioned that Figure 35 corresponds generally to the sub-routine already described with reference to Figure 25. However, Figure 35 is illustrated as comprising various sub-routines including "one action take care of" illustrated in more detail in Figure 36, "preparation for next action" (BF) illustrated in more detail in Figure 4~.
Referring now to Fiqure 36, which is a sub-routine (BG) called from the routine of Figure 35, following enabling of the interrupt of Figure 34 and completion of the self-test routine (BH) (see Fig-ure 37), a check is made to see whether the sync flag is set (Br). If the sync flag is set, the routine SYNC
BD of Figure 38 is performed. A user warning is displayed if the EN sync flag is set, and then a check is made on the status of the sync action flag. If it is set, the distance is monitored until T2 (of Figure 31), the sync road counter is enabled to start counting, and a manual synchronization signal is expected during the traveling period along the window enable distance (e.g, 50 meters).
The "sync road counter" is enabled (BH) to begin counting when the window ena~le distance is reached and the message for manual sync is displayed.
These steps are illustrated in more detail in Figure 38.
If the sync road counter reaches the value equivalent to the accumulated error (d+ + d-) and no sync signal has been received, the procedure is ended. On the other hand, if a sync signal is received before the window enable distance is covered, the procedure is completed when the sync signal is received. The progra~ then checks of the sync signal was received, and takes into account the case when it is not received.
This is illustrated in the sub-routine (BE) of Figure 70 4~2 (check if done). The program then returns to the end (BI) of the sub-routine (BG) illustrated in Figure 36 from where it returns to the program illustrated in Figure 35 at the "preparation for the next action" step (BF). This is illustrated in more detail in Figure 48.
The sub-routine concludes the current action and prepares for the next action by updating the action memory pointer and updating the flags.
Reference will now be made to Figure 39 which indicates the su~-routine INACNTR (BJ) ~instruction of action control" which is followed if no sync flag is set at the decision block illustrated in Figure 36. If the enable sync flag is set (BK), a warning of forth-coming manual synchronization is displayèd to the user.
The speed and distance from the first landmark (landmark zero) are continually monitored until the time T2. At time T2, a message is highlighted for the user and from this point on until or around the approached landmark only the distance travelled by the vehicle is moni-tored.
The sub-routine SPDST (BL) mentioned in Figure 39 is illustrated in more detail in Figure 40.
This procedure searches for the time T2 at a distance in the range of 50 to 750 meters from the approached landmark.
The sub-routine SPEED of Figure 41 operates in conjunction with the interrupt illustrated in Figure 34, in order to measure the vehicle speed.
Figure 42 illustrates sub-routine CNTJNC BN
called from the routine of Figure 39. It illustrates the sequence form the time T2 until the cycle is completed.
Figure 43 illustrates the sub-routine CNTRL
(BO) entered if no auto sync flag is set in the routine of Figure 42. It illustrates the sequence from T2 until the tie when the vehicle is near landmark 1 when the action invo~ves no synchronization, i.e., when the vehicle should pass straight through a junction without ~2~?~4l2 turning. When the distance indicated by contents of the one action r~ad counter is equal to the distance indicated by the number of wheel revolutions expected in the cycle stored in the action memory, a hardware timer is enabled (time control of Figures 29 to 32).
When the timer has lapsed, the procedure BP illustrated in Figure 44 is initiated as a result of an interrupt signal following the enabling of the interrupt BQ by a CPU command, at the end of the sub-routine of Figure 43.
Reference will now be made to Figure 45 which illustrates the automatic synchronization process, sub-routine AUTSYNC BR. This sub-routine is entered following a positive result to the "auto sync flag set"
decision of the sub-routine illustrated in Figure 42.
As illustrated, the first step is a sub-routine UNENSNC
(BS) illustrated in Figure 46 which repeatedly compares the mistake distance byte (the d+ distance) with the distance of the vehicle from the approached landmark computed from the distance indicated by the action road counter and the distance indicated by the estimated number of wheel revolutions in the cycle as stored in action memory. When equality is detected, the proce-dure is ended.
In the second major step of the auto synchron-ization process, the sub-routine ENSNCNT (BT) is entered, which is illustrated in more detail in Figure 47.
Referring to this figure, it will now be shown how the data generated from the turn detector enables accurate synchronization of the vehicle location indicated by the sequence action data with actual vehicle location detected by the turn detector in the distance window around an ~pproached landmark.
In this connection, reference should be made to Figure 49 illustrating three possibilities A, B and C for a left turn, and Figure 50 illustrating the steering wheel direction turning with reference to the vehicle location on a road during a turning period 56 ~ 4`12 within the window enable distance 501 around an approached landmark 502. During the window enable distance 501, the location of the actual turn is detected. A continual check is made to determine whether the vehicle is within the window enable distance (within the window?) (BU), so that the turn will only be detected during this distance. Detection of the turn is based on the principle that the actual angle through which the vehicle turns in a given time interval is proportional to the integration of the measured speed (v) multiplied by the measured angle over that time interval (50 ms in this example). Thus, the turn is detected according to the following steps:
1. An integration over 50 milliseconds is repeatedly carried out and the value of the integration and the associated location are stored (BV).
2. It is repeatedly checked whether the vehicle is within the window enable distance (BU).
3. If the vehicle is no longer within the window enable distance, the sync road counter is stopped (BW).
The turn location is then calculated in the "integration function checking" step (BX).
Figure 51 illustrates the integration results during the window period for each of the possibilities A, B and C illustrated in Figure 49. The point where the integration is the greatest (i.e., a maximum) may be regarded the closest point to the center of the intersection. The angle is the measured angle which may be the angle of the front wheels of the vehicle or the angle of the steering wheel relative to the center line of the vehicle.
The turn location is determined according to the data stored in step BV by determining the location at which the integration result is a maximum. For this location, a value is then calculated to indicate the difference between the measured distance (action road counter) and the distance stored in action memory for compensation purposes in the following action.
Having calculated the compensation distance (BY) (Figure 47) for the next action and set the update action road counter enable flag (BZ), the program concludes the process of Figure 36 (BG) and advances to the next block of Figure 35 "preparation for next action" (BF), which is set forth in more detail in Figure 48.
First of all, the program checks whether an automatic synchronization has been performed, indicated in the figure as "update action road counter enable flag is set?" (CA). If the road counter enable flag is set, appropriate compensation is made (CB) to the action road counter and various other flags are checked and reset (CC, CD, CE) where necessary. The pragram then returns to the path implementation procedure of Figure 35, and the data for the next action are taken from action memory (CF).
The sub-routine INSTJNC (A) of Figure 54, with its associated sub-routine of Figures 55 to 63, illustrate the routine INSTJNC (A) of Figure 4 from the point of view of the vehicle operator. Figure 64, 65 and 66 are routines for verifying map data and displaying keyboard status. No detailed description will be given of these figures, which are largely self-explanatory.
The invention has now been explained in detail with reference to specific embodiments. Other embodiments will be apparent to those of ordinary skill in this art upon reference to the specification within undue consideration or experimentation. It is therefore not intended that this invention be limited except as indicated by the appended claims.

Claims (36)

1. A vehicle navigation system comprising:
means for storing map data representing a road network, said data comprising information about landmarks, said information comprising landmark identifiers, landmark location and landmark characteristics of said landmarks in said road network, map distances between said landmarks, and path characteristics between adjacent landmarks;
means for receiving start location data indicating vehicle start location;
means for receiving destination data indicating a desired destination;
means coupled to said map data storing means for establishing a route comprising sequence data, said sequence data indicating a sequence of landmark identifiers;
first processing means coupled to said route establishing means for receiving said sequence data and for computing sequence action data, said sequence action data comprising computed lineal distances between landmarks and status data related to an approached landmark;

distance measuring means for measuring distance travelled by said vehicle to provide measured distance data;
means for detecting vehicle movement in a distance window only around said approached landmark to provide movement data indicative of change in motion of said vehicle;
second processing means coupled at least to said first processing means, to said distance measuring means, and to said vehicle movement detecting means for receiving said movement data, said distance data and said sequence action data, for supplying output data indicative of current location or expected actions in sequence for aiding a driver of the vehicle to adhere to the route; and output means for supplying the output data in a form discernible by the driver.

2. A system according to claim 1 wherein said second processing means is operable to synchronize said sequence action data with actual vehicle location based on said vehicle movement data in said distance window around said approached landmark.

3. A system according to claim 1 wherein said output means provides at least one of a visual display and an audible spoken output.

4. A system according to claim 1 wherein said map data storing means further includes means for receiving a non-volatile memory device storing data representing a street map.

5. A system according to claim 4 wherein the non-volatile memory device is a plug-in unit.

6. A system according to claim 1 wherein said distance measuring means comprises a transducer device for providing an electrical signal representing vehicle wheel revolution.

7. A system according to claim 1 wherein said movement detecting means comprises a transducer device for providing an electrical signal representing angular position of a steering wheel of the vehicle.

8. A system according to claim 1 wherein said first processing means and said second processing means comprise a plurality of program sequences for a microprocessor unit and a read only memory storing said programming sequences for said microprocessor unit.

9. A system according to claim 1 wherein said movement detecting means is for indicating a change in direction of travel relative to current direction of travel toward said approached landmark.

10. A system according to claim 9 wherein said movement detecting means includes an angle sensor for sensing angle of steering relative to a tangent to direction of travel of said vehicle.

11. A system according to claim 10 wherein said movement detecting means further includes a momentary speed detection means for detecting instantaneous speed of said vehicle.

12. A system according to claim 11 wherein said momentary speed detection means is for measuring speed of the vehicle within a distance around said approached landmark, and wherein said second processing means employs outputs of said angle sensor and of said momentary speed detection means to compute degree of change of orientation.

13. A system according to claim 1 further including computing means coupled to said first processing means for establishing size of said distance window at least as a function of computed distance to said approached landmark in order to improve resolution of movement around said approached landmark.

14. A system according to claim 1, wherein said route establishing means comprises third processing means coupled to said data storing means, to said start location receiving means and to said destination data receiving means for computing a route through said road network prior to a journey, said route comprising sequence data indicating a sequence of said identifiers of landmarks.

15. A system according to claim 2 wherein said movement detecting means is for indicating a change in direction of travel relative to current direction of travel toward said approached landmark.

16. A vehicle navigation system according to claim 1 wherein said second processing means further includes means for comparing expected movement data with actual movement data to generate run error data for aiding the driver of the vehicle to adhere to the route.

17. A vehicle navigation system according to claim 1 wherein said start location receiving means includes means for receiving an indication of vehicle location relative to magnetic North.

18. A vehicle navigation system comprising:
means for storing distance data between landmarks;
distance measuring means for measuring distance travelled by said vehicle from a known location to provide distance data;
window enable means for defining a distance window around an approached landmark to provide window data indicative of vehicle location relative to said approached landmark;
means for detecting vehicle movement only in a distance window around said approached landmark to obtain movement data indicative of change in motion of said vehicle; and processing means coupled to said distance measuring means, to said window enable means and to said vehicle movement detecting means for receiving from said vehicle movement detecting means said movement data, and from said window enable means said window data for synchronizing said stored distance data with actual vehicle location based on said vehicle movement data in said distance window around said approached landmark.

19. A system according to claim 18 wherein said movement detecting means is for indicating a change in direction of travel relative to direction of travel toward said approached landmark.

20. A system according to claim 19 wherein said movement detecting means includes an angle sensor for sensing angle of steering relative to a tangent to direction of travel of said vehicle.

21. A system according to claim 20 wherein said movement detecting means further includes a momentary speed detection means for detecting instantaneous speed of said vehicle.

22. A system according to claim 21 wherein said momentary speed detection means is for measuring speed of the vehicle only in a distance window around said approached landmark, and wherein said processing means employs output of said angle sensor and of said momentary speed detection means to compute degree of change of orientation.

23. A system according to claim 18 further including computing means coupled to said window enable means for establishing size of said distance window as a function of at least computed distance to said approached landmark in order to improve resolution of movement around said approached landmark.

24. A vehicle navigation system according to claim 18 further including means for automatically scaling between two preselected landmarks, said scaling means comprising:
means for comparing a value representative of said stored distance with a value representative of said measured distance between said two preselected landmarks to obtain a scaling factor; and means for storing said scaling factor.

25. A vehicle navigation system according to claim 24 wherein said measured distance is directly proportional to the number of wheel revolutions of a vehicle axle.

26. A method for navigating a vehicle comprising:
storing map data representing a road network, said map data comprising information about landmarks, said information comprising landmark identifiers, landmark location and landmark characteristics of said landmarks in said road network, map distances between said landmarks and path characteristics between adjacent landmarks;
receiving start location data indicating vehicle start location;
receiving destination data indicating a desired destination;
establishing a route comprising sequence data indicating a sequence of landmark identifiers;
computing sequence action data from said sequence data, said sequence action data comprising computed lineal distances between landmarks and status data related to an approached landmark;
measuring distance travelled by said vehicle to provide measured distance data;
detecting vehicle movement in a distance window only around said approached landmark to provide movement data indicative of change in motion of said vehicle;
comparing said movement data with said status data of said sequence action data and said measuring distance data with said computed lineal distances of said sequence action data and supplying output data indicative of expected actions in sequence for aiding a driver of the vehicle to adhere to the route; and supplying the output data in a form discernible by the driver.

27. A navigation system for a vehicle comprising means for receiving data indicating an actual vehicle location means for storing data representing a road network; means for measuring distance travelled by said vehicle; turn detecting means for detecting a turn by the vehicle and providing a turn signal in response thereto;
means for receiving destination data indicating a desired destination; computing means for computing a route through said road network from the actual vehicle location to the desired destination; processing means for receiving data from the distance measuring means, for computing the actual vehicle location therefrom and for preparing instruction data for aiding a driver of the vehicle to adhere to said route; output means for supplying the instruction data in a form discernible by the driver;
window enable means for defining a distance window in which a significant turn will be made by the vehicle when following said route; and synchronizing means operative to synchronize the computed route with actual vehicle location based on said turn detecting means producing a signal indicating a significant turn within said distance window.

28. A system according to claim 27 wherein the turn detecting means is operative to provide data representing an angle through which the vehicle has turned.

29. A system according to claim 27 wherein the output means provides at least one of a visual display and an audible spoken output.

30. A system according to claim 27 further including means for receiving a non-volatile memory device storing data representing a street map.

31. A system according to claim 30 wherein the memory device is a plug-in-unit.

32. A system according to claim 27 further comprising a compass located externally of the vehicle and operative to provide an electrical output representing the vehicle orientation before a journey begins.

33. A system according to claim 27 wherein said means for measuring distance comprises a transducer device arranged to provide an electrical signal representing vehicle wheel revolutions.

34. A system according to claim 33 wherein on detection of said turn signal within any distance window said processing means is operative to calibrate the scale factor relating distance travelled to the number of wheel revolutions.

35. A system according to claim 27 wherein said turn detecting means comprises a transducer device operative to provide an electrical signal representing angular position of a steering wheel of the vehicle.

36. A system according to claim 27 wherein said processing means comprises a microprocessor unit and a read only memory storing a program for said microprocessor unit.