Bezier curves for advanced driver assistance system applications

[0001] This application claims the benefit of U.S. Provisional Patent Application No. 61/101,758 filed Oct. 1, 2008 and entitled “BEZIER CURVES FOR ADVANCED DRIVER ASSISTANCE SYSTEM APPLICATIONS.” The full disclosure of U.S. Provisional Patent Application Ser. No. 61/101,758 is incorporated herein by reference.

[0002] The present patent application is related to the copending patent application filed on the same date, Ser. No. 12/540,704, entitled “CREATING GEOMETRY FOR ADVANCED DRIVER ASSISTANCE SYSTEMS,” which is incorporated herein by reference.

[0003] The present invention relates generally to advanced driver assistance systems (ADAS), and more particularly, relates to using Bezier curves to provide vehicle positioning, curvature, slope, and heading information to ADAS applications.

[0004] ADAS was developed to improve the comfort, efficiency, safety, and overall satisfaction of driving. Examples of these advanced driver assistance systems include adaptive headlight aiming, adaptive cruise control, lane departure warning and control, curve warning, speed limit notification, hazard warning, predictive cruise control, adaptive shift control, as well as others. Some of these advanced driver assistance systems use a variety of sensor mechanisms in the vehicle to determine the current state of the vehicle and the current state of the roadway in front of the vehicle. These sensor mechanisms may include radar, infrared, ultrasonic, and vision-oriented sensors, such as digital video cameras and LIDAR.

[0005] Some advanced driver assistance systems also use digital map data. These systems are sometimes referred to as map-enhanced ADAS. The digital map data can be used in advanced driver assistance systems to provide information about the road network, road geometry, road conditions, and other items associated with the road and terrain around the vehicle. Unlike some sensors, the digital map data is not affected by environmental conditions, such as fog, rain, or snow. In addition, the digital map data can provide useful information that cannot reliably be provided by sensors, such as curvature, grade, bank, speed limits that are not indicated by signage, lane restrictions, and so on. Further, digital map data can provide a predictive capability well beyond the range of sensors or even beyond the driver's vision to determine the road ahead of the vehicle, around corners, over hills, or beyond obstructions. Accordingly, the digital map data can be a useful addition for some advanced driver assistance systems.

[0006] The map-enhanced advanced driver assistance systems commonly use data from a geographic database associated with a navigation system in a vehicle. The navigation system database contains data that represents the road network in the region, such as the locations (geographic coordinates, including altitude) of roads and intersections, road names, speed limits along roads, turn restrictions at intersections, addresses or address ranges along roads, the number of lanes for each road, lane width, lane markings, functional classes of roads, the locations of medians, and so on. The navigation system database may also contain information about other geographic features, such as bodies of water, parks, administrative areas (including municipal, state, and country boundaries), and locations of points of interest, such as businesses, hospitals, police stations, and so on.

[0007] The navigation system database has much more data than an advanced driver assistance system needs. Additionally, a geographic database designed for navigation may not have all the data and/or may not have data with the accuracy levels needed by the advanced driver assistance system. As a result, there has been some effort in designing a geographic database specifically for advanced driver assistance systems. For example, U.S. Patent Publication No. 2006/0100780 describes a geographic database having a data storage format designed for a sensor device in a motor vehicle system. However, there is room for improvement in a geographic database designed specifically for advanced driver assistance systems.

[0008] A method and system for using Bezier curves in vehicle positioning and electronic horizon applications for providing data to ADAS applications are disclosed. The Bezier curves are obtained from B-splines. The obtained Bezier curves are subdivided in a manner that allows the vehicle positioning application to derive a polyline representation in real time. Using the Bezier and polyline geometry, the vehicle positioning application provides a vehicle position approximation to the ADAS applications. Using the Bezier curves, the electronic horizon application provides curvature, slope, and heading profiles to the ADAS applications.

[0009] These as well as other aspects and advantages will become apparent to those of ordinary skill in the art by reading the following detailed description, with reference where appropriate to the accompanying drawings. Further, it is understood that this summary is merely an example and is not intended to limit the scope of the invention as claimed.

ADAS Architecture

[0021] FIG. 1 is a block diagram of map-enhanced ADAS architecture 100. In this example, the map-enhanced ADAS architecture 100 includes driver assistance applications 114, and a map and positioning engine (MPE) 116. The MPE 116 is shown in FIG. 1 as a standalone module; however, it is understood that the MPE 116 may be distributed into multiple packages and/or integrated into other device packages, such as a sensor package. The MPE 116 includes a processor 102, a positioning system 104, a geographic database 106, a communications system 108, and an in-vehicle data bus interface 110. The MPE 116 may also include other hardware, software, and/or firmware, such as memory and a power source.

[0022] The processor 102 may be any type of processor, controller, or other computing device. For example, the processor 102 may be a digital signal processor. The processor 102 receives inputs from the positioning system 104, the geographic database 106, the communication system 108, the in-vehicle data bus interface 110, and other sources. The processor 102 then processes the inputs using application software programs 200, some of which are described with reference to FIG. 2.

[0023] The processor 102 then provides outputs to the driver assistance applications 114 via the in-vehicle data bus interface 110 and a data bus 112. Preferably, the in-vehicle data bus interface 110 and the data bus 112 are a Controller-Area Network (CAN) interface and a CAN bus, which are designed for automotive applications. The driver assistance applications 114 may include adaptive headlight aiming, adaptive cruise control, obstruction detection, obstruction avoidance, collision avoidance, adaptive shift control, and others.

[0024] The positioning system 104 may utilize GPS-type technology, a dead reckoning-type system, or combinations of these or other systems, which are known in the art. The positioning system 104 may also include suitable sensing devices that measure the traveling distance speed, direction, orientation, and so on. For example, the positioning system 104 may include a GPS system and a gyroscope. The positioning system 104 provides an output signal to the processor 102. Some of the application software programs 200 that run on the processor 102 use the output signal from the positioning system 104 to determine the location, direction, orientation, etc., of the MPE 116.

[0025] The geographic database 106 is designed for ADAS applications. Like a navigation system geographic database, the geographic database 106 contains data about roads and intersections in a geographic region. For example, the geographic database 106 contains at least one database record (also referred to as “entity” or “entry”) for each road segment (also referred to as a link). When the road segment is represented as a B-spline or Bezier curve(s), the road segment data record includes data providing the geographic coordinates (e.g., the latitude, longitude, and altitude) of control points. The end points (also referred to as nodes) of the road segment correspond to the first and last control points. Additionally, the road segment data record may also contain a knot vector for B-spline geometry.

[0026] When the road segment is represented as shape point geometry, the road segment data record includes data providing the geographic coordinates (e.g., the latitude, longitude, and altitude) of the end points of the represented road segment. For curved segments, the road segment data record also includes data providing the geographic coordinates (e.g., the latitude, longitude, and altitude) of the shape points used to characterize the polyline.

[0027] The road segment data record is further described with reference to FIG. 3.

[0028] The geographic database 106 may include higher quality (i.e., more accurate) data than the data typically contained in a navigation system geographic database. For example, with respect to road geometry, the data in the geographic database 106 may be more accurate with respect to longitude, latitude, and/or altitude. Also, the starting and stopping locations of tunnels may be more accurately specified in the geographic database 106. Further, the data in the geographic database 106 may be more accurate with respect to derived information, such as curvature.

[0029] The geographic database 106 may also include more kinds of data (e.g., more kinds of attributes) than the data typically contained in a navigation system geographic database. For example, the geographic database 106 may include data about road objects, such as signs and crosswalks, including their positions along a road segment, sign object type, and sign text. Some of the data attributes found in the geographic database 106 are described with reference to FIG. 4.

[0030] FIG. 2 is a block diagram depicting some of the software applications 200 available to the processor 102. The software applications 200 depicted in FIG. 2, include a map access application 202, a map update application 204, a vehicle positioning application 206, an electronic horizon application 208, and an interface application 210. As this is not an exhaustive list of all the software applications 200 available to the processor 102, FIG. 2 also depicts other applications 212, which may include a startup routine, self-test diagnostics, and so on.

[0031] The map access application 202 provides data access to the geographic database 106 stored on physical storage media. The map access application 202 receives a request for data from the processor 102 and locates data responsive to the request on the physical storage media. The map access application 202 preferably provides an application programming interface (API) for use by the processor 102 and/or the applications 200.

[0032] The map update application 204 facilitates updates to the geographic database 106. The communications system 108 receives one or more parcels that either add additional coverage to an existing database or replace existing parcels. A parcel is a unit of storage for storing geographic data in the geographic database 106 on physical storage media. For new parcels, the map update application 204 stores the parcel on the physical storage media. For existing parcels, the map update application 204 replaces the old parcel with the new parcel on the physical storage media.

[0033] The vehicle positioning application 206 determines the vehicle's position relative to a road network that is represented by data included in the geographic database 106. The vehicle positioning application 206 uses the output from the positioning system 104 and matches the output to data in the geographic database 106 using a vehicle positioning algorithm, which is sometimes referred to as a map matching algorithm.

[0034] The electronic horizon application 208 determines an electronic horizon. An electronic horizon is a collection of roads and intersections leading out from the current vehicle position to an extent determined by the electronic horizon application 208. The collection of roads and intersections are potential paths that the vehicle may follow from the current vehicle position. The electronic horizon application 208 determines extent using one or more costing functions. The costing functions are based on the needs of the driver assistance applications 114 and may take into consideration various factors, such as vehicle speed, travel time, and driving distance. An example electronic horizon application is described in U.S. Pat. No. 6,405,128, which is assigned to the same assignee as the current application and is hereby incorporated by reference in its entirety.

[0035] The interface application 210 controls communications between the MPE 116 and the driver assistance applications 114 via the interface 110 and the bus 112. Preferably, the interface application 210 is based on the CAN protocol, which is a serial communication protocol for communicating between various electronic devices in the vehicle. In accordance with the CAN protocol, the various electronic devices in the vehicle can be coupled to a single serial bus (e.g., the bus 112) such that messages and data can be sent from one electronic device in the vehicle to another. The CAN protocol is a message based protocol in which CAN frames are placed on a common CAN bus. The CAN bus may be a single wire or a differentially driven pair of wires.

[0036] FIG. 3 is a block diagram of a road segment data record 300 from the geographic database 106. The road segment data record 300 includes data used to represent a portion of the road. The data include node data 302, 304, which identify the latitude, longitude, and altitude coordinate positions of the end points of the segment.

[0037] The data also include control point data 306, 308, which identify the latitude, longitude, and altitude coordinate positions of control points that can be used to represent the shape of a straight or curved segment. While the data for two control points are shown in FIG. 3, it is understood that a segment can contain more than one curve and the number of control points may depend on the number and shape of the curves in the segment. For example, each cubic Bezier curve is represented by four control points, but the last control point of a previous Bezier curve is the same as the first control point of the next Bezier curve. The road segment data record 300 stores data for the number of control points equal to the number of Bezier curves multiplied by three, plus one.

[0038] The data further include attributes 310 for the segment. Some of the attributes 310 of the segment are depicted in FIG. 4. The road segment data record 300 may include additional data, such as shape point data, as well.

[0039] FIG. 4 is a block diagram of some of the data attributes 310 for a road segment data record 300. The data attributes 310 depicted in FIG. 4 include segment identification (ID) 402, control points 404, direction of travel 406, speed category 408, lane category 410, road type 412, segment characteristics 414, and access characteristics 416. As this is not an exhaustive list of all the data attributes for the road segment data records, FIG. 4 also depicts other attributes 418. For example, the segment data attributes 400 may also include references to node data records in the form of a node ID corresponding to end points 302, 304 of the segment.

[0040] The segment ID 402 identifies a data record in the geographic database 106.

[0041] The control point attributes 404 contain bit flags that provide additional information regarding control points to aid in the creation of curvature and slope profiles as described with reference to FIG. 9. For example, the control point attributes 404 may include a byte-size flag per control point. One of the bits in the flag is assigned to curvature, while another of the bits is assigned to slope. If the curvature bit flag is set to one, then the control point is marked as part of the curvature profile. Similarly, if the slope bit flag is set to one, then the control point is marked as part of the slope profile.

[0042] The direction of travel attribute 406 represents the allowed direction of traffic flow on a segment. For example, the segment may represent a portion of a road network in which travel is permitted in both directions. Alternatively, the segment may represent a portion of a road network allowing only one-way travel. The direction of travel attribute 406 identifies whether the segment allows bi-directional travel or unidirectional travel, and if unidirectional, the direction of travel attribute 406 also identifies the allowed direction of travel.

[0043] The speed category attribute 408 represents the general speed trend of a road based on posted or implied speed limit. The speed category attribute 408 contains data associated with a speed range. For example, the speed category attribute 408 may include a data representation of the integer 1 for speeds exceeding 80 mph, the integer 2 for speeds in the range of 65-80 mph, the integer 3 for speeds in the range of 55-64 mph, and so on until the speed range includes 0 mph.

[0044] The lane category attribute 410 represents the predominant number of lanes on a segment in one direction of travel. Preferably, the lane category attribute 410 does not include turn lanes. If the number of lanes is different for each direction, the lane category attribute 410 may represent the higher number.

[0045] The road type attribute 412 represents the type of road and/or functional class that the segment represents. For example, the road type attribute 412 may contain data associated with an interstate highway, a controlled access highway, a pedestrian walkway, and so on.

[0046] The segment characteristic attribute 414 contains bit flags that describe various characteristics of the segment. For example, the segment characteristic attribute 414 may identify whether a segment is paved, a ramp, a bridge, a tunnel, a roundabout, and so on.

[0047] The access characteristic attribute 416 contains bit flags that define the types of traffic allowed on the segment. For example, the access characteristic attribute 416 may identify whether cars, buses, trucks, taxis, emergency vehicles, pedestrians, and so on are allowed on the segment.

Creating Geometry for the MPE

[0048] FIG. 5 is a flow chart of a method 500 for creating geometry for the MPE 116. At block 503, the method 500 subdivides a geographic database 502 into tiles to enable parallel processing. The geographic database 502 may be the geographic database 106 or a different database that includes the data in the geographic database 106.

[0049] The tiles are formed in such a way that each tile contains approximately equal amount of nodes and shape points. The map surface is covered by an imaginary 2D rectangular grid with fine (approximately 2 km by 2 km) cells. Then, the density of the nodes and shape points is computed by mapping the nodes and shape points in the geographic database 502 onto the grid. The tiles are assembled from the grid cells.

[0050] In order to ensure that each tile has approximately equal number of nodes and shape points, the whole grid is recursively subdivided in half along the grid lines, both in horizontal and vertical directions, in such a way that each of the two partitions contain an equal number of geometrical points. The process continues until the tiles contain an amount of nodes and shape points that is smaller than a predefined threshold. The direction of each subdivision is selected in such a way that the aspect ratio of the tiles is minimized.

[0051] At block 504, the method 500 creates link chains within each tile using data from the geographic database 502. The link chains are a sequence of segments, with each of the segments having the same road type attribute 412. The link chains are created using a software routine. The software routine selects a first segment having an associated functional class. At each node, the software routine selects the next segment to add to the link chain. The sequence of segments is preferably made as long as possible. The link chains are used to perform a B-spline fit to ensure smoothness across segment boundaries.

[0052] At block 506, the method 500 creates 2D B-splines using the link chains created at block 504. At block 508, the method 500 creates 3D B-splines using the link chains created at block 504, the 2D B-splines created at block 506, and height data 507. A spline refers to any composite curve formed with piecewise polynomial functions representing curve sections and satisfying specified conditions at boundaries of the sections. Thus, there are many types of spline curves including B-splines. A B-spline has control points and knots. Knots are the points at which individual polynomial curve segments of a polynomial spline curve join together. The segments are joined in such a way as to provide smoothness of the complete curve. A knot vector is an ordered list of non-decreasing floating point numbers that describe points along the spline curve where segments begin and end. Splines are well-known in the art.

[0053] With splines, map features, including curving road portions, are represented by polynomial equations whose coefficients have been determined so as to generate curves that match the shapes of the geographic features with the desired degree of accuracy. Thus, splines are a means of describing the shape of the underlying road geometry by specifying the coefficients of a polynomial equation. As described in U.S. Pat. No. 7,084,882, splines have been used to represent shapes of road segments in navigation system databases. U.S. Pat. No. 7,084,882 is assigned to the same assignee as the current application and is hereby incorporated by reference.

[0054] The link chains are fitted to create 2D B-splines. The 2D B-splines are manipulated to correct irregularities and alignment problems. Knots not needed to encode curvature or preserve the position, curvature, slope, and/or heading are removed to minimize storage requirements.

[0055] The optimized 2D B-splines and the height data 507 are used to create 3D splines. The height data 507 is preferably obtained from GPS/IMU traces collected as vehicles travel on the roads represented by the road segments; however, the height data 507 may be obtained from other sources and/or sensors. The height data 507 is linearly corrected at crossing nodes to account for GPS height inaccuracies. The link chains are fitted to create an altitude B-spline using the corrected height data.

[0056] The 2D B-spline and the altitude B-spline are merged to obtain a 3D B-spline. Like the 2D B-spline, knots not needed to encode curvature and slope, or preserve the position, curvature, slope, and/or heading are removed from the 3D B-spline to minimize storage requirements.

[0057] At block 510, the 2D B-splines and the 3D B-splines may be converted to Bezier curves. If a segment does not have height data, the 2D B-spline is converted to a Bezier curve. However, if the segment does have height data, the 2D B-spline may only be used to create the 3D B-spline at block 508.

[0058] Cubic Bezier curves are defined by two end points and two additional control points that are positioned along tangents to the curve at the end points. The cubic Bezier curve equation can be written in vector form as follows:
B(t)=(1−t)³P₀+3t(1−t)²P₁+3t²(1−t)P₂+t³P₃
where P₀, P₁, P₂, and P₃ are the control points and t is the parameter. Bezier curves can be derived from B-spline curves using known methods.

[0059] While spline geometry is useful for representing road segment geometry, the use of B-splines in the MPE 116 increases the computational requirements for the vehicle positioning and the electronic horizon applications 206, 208. The analytical B-spline geometry is converted into a Bezier representation to facilitate real time derivation of a polyline representation by the vehicle positioning application 206 and an electronic horizon by the electronic horizon application 208.

[0060] At block 512, the Bezier road geometry is divided so that the vehicle positioning application 206 can derive a polyline representation in real time. The method 500 assumes that the road geometry has Bezier curves such that when a point farthest from its chord is projected onto the chord line, the point falls inside the chord. The Bezier road geometry is divided after identifying a point 600 (or possibly more than one point) at a furthest distance (or distances) from the Bezier curve to a line connecting the end points 302, 304 of the curve (i.e., the control polygon base chord, {right arrow over (P₀P₃)}) as shown in FIG. 6. Also seen in FIG. 6, the furthest distance is generally not in the center of the curve.

[0061] The optimal subdivision point 600 is the point on the Bezier curve that is the furthest from the control polygon base chord. The position of the point 600 is obtained analytically from the condition that the tangent to the 2D Bezier curve B(t) at the point 600 is parallel to the chord.

[0062] $\frac{d\overrightarrow{B}}{dt}=\alpha \overrightarrow{P_0{P}_3}.$

[0063] The expression above is reduced to a quadratic equation for the parameter t. For a general Bezier curve, the quadratic equation may not have real roots in the interval [0-1] on which the parameter t is defined. However, for well-behaved Bezier curves, the quadratic equation will have one or two real roots in the [0-1] interval. If the quadratic equation has two real roots, two subdivision points are used to split the Bezier curve at two points. Once the point 600 is obtained, the Bezier curve is split into two Bezier curves using the de Casteljau subdivision algorithm. The resulting Bezier curves are stored in the geographic database 106.

[0064] At block 514, the vehicle positioning application 206 derives a polyline representation in real time. An example polyline representation 700 is depicted in FIG. 7. The vehicle positioning application 206 derives the polyline representation 700 by connecting the end points 702 of the Bezier curves while ignoring the internal control points 704.

Using Bezier Road Geometry to Determine Vehicle Position

[0065] FIG. 8 is a flow chart for a method 800 of vehicle positioning using dual road geometry representation. The dual road geometry representation includes the Bezier geometry obtained at block 512 and the polyline geometry obtained at block 514. The vehicle positioning application 206 performs the method 800 during operation of the MPE 116. In particular, the vehicle positioning application 206 performs the method 800 after determining the polyline geometry at block 514.

[0066] At block 802, the vehicle positioning application 206 performs map matching analysis to determine the closest point to the vehicle on the polyline representation as determined at block 514. The map matching analysis may be conducted using conventional vehicle positioning algorithms.

[0067] At block 804, the vehicle positioning application 206 identifies the appropriate Bezier curve from the point on the polyline found at block 802. The vehicle positioning application 206 computes a lookup table on the fly to associate the Bezier curves with the computed polyline. The length along the polyline is used in the lookup table to identify the corresponding Bezier curve.

[0068] At block 806, the vehicle positioning application 206 projects the map matched point identified at block 802 onto the Bezier curve identified at block 804. The vehicle positioning application 206 obtains an approximation of vehicle position on the Bezier curve by solving a cubic equation numerically using a combination of Newton's and bisection methods.

[0069] Because the vehicle positioning application 206 is approximating vehicle position on the Bezier curve, the process is simplified from processes that attempt to identify exact vehicle position. This simplification is useful for the MPE 116 as the MPE 116 is likely to have less computing capabilities than a navigation system, for example. The vehicle positioning application 206 provides the vehicle position approximation to one or more of the driver assistance applications 114 via the interface application 210, the in-vehicle data bus interface 110, and the data bus 112.

Using Bezier Road Geometry to Derive Curvature and Slope Profile

[0070] FIG. 9 is a flow chart of a method 900 for generating curvature and slope profiles. The resulting curvature and slope profiles for a segment may have a piecewise linear format. Blocks 902-904 depict pre-processing steps that occur prior to loading the geographic database 106. As a result of these steps, data is stored in the geographic database 106 for use by the electronic horizon application 208. Blocks 906-908 depict processing that occurs when the MPE 116 is operational.

[0071] At block 902, the method 900 obtains curvature and slope information from the B-splines. The curvature information may be obtained by taking samples along the B-spline and computing 2D (i.e., horizontal) curvature and arc length at each sample point. The measured curvature and arc length are graphed (e.g., curvature along the y-axis, arc length along the x-axis). The method 900 applies the Douglas-Peucker line simplification technique using recursive subdivision to the plot until the polyline approximation is within a desired tolerance. These polylines have coordinates of arc length and curvature (i.e., (l, k)). The slope information may be obtained in a similar way.

[0072] At block 904, the method 900 encodes the vertices of the piecewise-linear approximation into the Bezier control points. The method 900 identifies points on the B-spline that correspond to the vertexes of the polyline. The method 900 inserts knots into the B-spline at the identified points. The inserted knots are tagged/flagged as curvature knots or slope knots. After inserting the additional knots, the method 900 removes as many original untagged knots from the B-spline not needed to keep the B-spline within a threshold tolerance from the 2D/3D position, shape, heading, slope, and curvature of the original B-spline. The resulting B-splines are then converted to Bezier curves. Additionally, the B-spline knot flags that mark the curvature and slope knots are converted to the Bezier curve control point flags 404.

[0073] At block 906, the electronic horizon program 208 computes arc length for the Bezier curves in the electronic horizon. Preferably, the electronic horizon program 208 uses Gaussian quadrature to estimate arc length. Evaluating Bezier curve derivatives at four internal points to calculate the arc length is a sufficiently good approximation.

[0074] At block 908, the electronic horizon program 208 publishes a curvature profile (curvature vs. arc length) using the curvature obtained at block 902 and encoded at block 904, and the arc length calculated at block 906. Similarly, the electronic horizon program 208 publishes a slope profile (slope vs. arc length) using the slope obtained at block 902 and encoded at block 904, and the arc length calculated at block 906.

[0075] The electronic horizon application 208 provides the curvature and/or slope profiles to one or more of the driver assistance applications 114 via the interface application 210, the in-vehicle data bus interface 110, and the data bus 112. Preferably, the electronic horizon application 208 provides the profiles as a pair of values (i.e., arc length and curvature, or arc length and slope) or two pairs of values if the profile is not continuous for a driven length. The number of pairs provided should be sufficient for the needs of the driver assistance applications 114, but not too much as to degrade communications on the data bus 112.

Using Bezier Road Geometry to Derive Heading Profile

[0076] FIG. 10 depicts a B-spline 1000 that corresponds to the segments of a road and an associated heading profile plot 1002. The lines 1004 in the plot 1002 represent an actual heading and the points 1006 in the plot 1002 are points of a piecewise-parabolic approximation described below.

[0077] A heading is the direction in which the vehicle is facing, which changes frequently as a vehicle travels on the road. The heading profile plot 1002 depicts how the vehicle's heading changes as the vehicle travels on the road relative to a compass reading. The compass reading in this example is based on north being at 0° (and 360°), east at 90°, south at 180°, and west at 270°.

[0078] Generally, the electronic horizon application 208 publishes the piecewise-parabolic heading profile plot 1002 in real time as a set of three points for each Bezier curve. The three points include the heading angles at the two end points 302, 304 and an intermediate heading angle point 1006 that the electronic horizon application 208 calculates.

[0079] To calculate the intermediate heading angle point 1006, the electronic horizon application 208 preferably samples heading angle points (e.g., four heading angle points) on the Bezier curve and performs a least squares analysis to fit a parabolic curve to the sampled heading angle points. The intermediate heading angle point 1006 is computed at midpoint l₁=l₀+0.5*(l₂−l₀) from the resulting best fitting parabolic curve derived by the least squares fit to the four sampled heading angle points on the Bezier curve. Using the three points, the electronic horizon application 208 computes the heading profile as a function of driven length. The electronic horizon program 208 provides the heading profile to one or more of the driver assistance applications 114 via the interface application 210, the in-vehicle data bus interface 110, and the data bus 112.

[0080] More specifically, the heading angle h is published as a function of the driving distance l along the segment. As heading is a smooth varying function along the road, heading is best represented by a piecewise parabolic profile instead of a piecewise linear approximation. The heading angle is computed in degrees and is measured in the clockwise direction from north. The heading angle values are published in the range of 0° to 360°. Since the heading angle is a periodic function, additional points are inserted into the heading profile when the link points exactly north to avoid a 0° to 360° transition inside a parabolic segment.

[0081] The parabolas are defined by three points. Each parabolic segment interpolates the values of the heading at the ends of a Bezier curve. The least squares fit technique is employed to derive a parabola that best approximates the internal points of the h profile as described above. The point on this parabola evaluated at the parameter value t=0.5 constitutes the third heading profile point to be published for the Bezier curve. The details of the least squares fit determination of a parabolic segment h=h(l) are presented as follows.

[0082] Let h₀=h(l₀) be the heading angle value at the left end of the Bezier curve, t=0, and h₂=h(l₂) be the heading angle value at the right end of the Bezier curve, t=1. The equation of the parabola that approximates heading angle vs. the driving distance can be written as follows:
h(l)=a(l−l₀)+b(l−l₀)(l−l₂)+c,
where a, b, and c are unknown scalar coefficients. Coefficients a and c can be eliminated using the boundary conditions to yield:

[0083] $h\left(l\right)=h_0+\frac{\Delta h}{\Delta l}\left(l-l_0\right)+b\left(l-l_0\right)\left(l-2\right),$
where Δh=h₂−h₀,Δl=l₂−l₀.

[0084] The remaining scalar coefficient b is derived by minimizing the sum of the square distances between the values sampled on the actual heading profile and the approximating parabola described above,

[0085] $\sum _i{\left(h\left(l_i\right)-\hat{h}\left(l_i\right)\right)}^2\to \min ,$
where ĥ are sampled heading values. Differentiating the expression above with respect to b and equating the derivative to zero yields the following expression for the remaining coefficient b:

[0086] $b=\frac{\sum _i\left(\left(\hat{h}\left(l_i\right)-h_0-\frac{\Delta h}{\Delta l}\left(l_i-l_0\right)\right)\left(l_i-l_0\right)\left(l_i-l_2\right)\right)}{\sum _i\left({\left(l_i-l_0\right)}^2{\left(l_i-l_2\right)}^2\right)}.$
Here l_i are the values of the driving distance along the spline at which heading values ĥ are sampled.

[0087] Introducing the substitution λ=l−l₀, where λ_i is the distance from the start of the Bezier curve, yields a simpler expression for the coefficient b:

[0088] $b=\frac{\sum _i\left((\hat{h}\left({\lambda }_i\right)-h_0-\frac{\Delta h}{\Delta l}{\lambda }_i){\lambda }_i\left({\lambda }_i-\Delta l\right)\right)}{\sum _i\left({{\lambda }_i^2\left({\lambda }_i-\Delta l\right)}^2\right)}.$
After the remaining coefficient b is evaluated from the expression above, the remaining third point for the parabolic approximation is evaluated at

[0089] $\lambda =\frac{\Delta l}{2}$
as follows:

[0090] $h_1\left(l_0+\frac{\Delta l}{2}\right)=h_1\left(l_1\right)=h_0+\frac{\Delta h}{2}-\frac{1}{4}b\Delta l^2.$

[0091] The heading angle can be evaluated from the x and y components of the tangent vector V_x,V_y as follows:

[0092] $h=\frac{\pi }{2}-a\tan 2\left(V_y,V_x\right)=a\tan 2\left(V_x,V_y\right),$
where a tan 2( ) is a standard C library function. The tangent vector components V_x,V_y, or the first derivative of the Bezier curve, can be evaluated in a number of ways. For example, the first derivative at the ends of the Bezier curve may be evaluated as follows:
V(t=0)=3(P₁−P₀), V(t=1)=3(P₃−P₂)
where P₀, P₁, P₂, and P₃ are the four control points of the Bezier curve. As another example, the first derivative in the internal points may be evaluated using the equation in the power basis form, with coefficients cached for frequent use for other purposes. The electronic horizon application 208 provides the three points (l.₀,h.₀), (l.₁,h.₁), (l.₂,h.₂) that define a parabolic segment of the global heading profile to one or more of the driver assistance applications 114.

[0093] It is intended that the foregoing detailed description be regarded as illustrative rather than limiting and that it is understood that the following claims including all equivalents are intended to define the scope of the invention. The claims should not be read as limited to the described order or elements unless stated to that effect. Therefore, all embodiments that come within the scope and spirit of the following claims and equivalents thereto are claimed as the invention.