A Generic Interface Enabling Combinations of State-of-the-Art Path Planning and Tracking Algorithms

Abstract

In the development of Level 4 automated driving functions, very specific, but diverse, requirements with respect to the operational design domain have to be considered. In order to accelerate this development, it is advantageous to combine dedicated state-of-the-art software components, as building blocks in modular automated driving function architectures, instead of developing special solutions from scratch. However, e.g., in local motion planning and control, the combination of components is still limited in practice, due to necessary interface alignments, which might yield sub-optimal solutions and additional development overhead. The application of generic interfaces, which manage the data transfer between the software components, has the potential to avoid these drawbacks and hence, to further boost this development approach. This publication contributes such a generic interface concept between the local path planning and path tracking systems. The crucial point is a generalization of the lateral tracking error computation, based on an introduced error classification. It substantiates the integration of an internal reference path representation into the interface, to resolve the component interdependencies. The resulting, proposed interface enables arbitrary combinations of components from a comprehensive set of state-of-the-art path planning and tracking algorithms. Two interface implementations are finally applied in an exemplary automated driving function assembly task.

1. Introduction

Automated driving (AD) has been a huge challenge over the last decades in research as well as in industry. However, estimations and expectations for final breakthroughs on the market have been continuously shifted, contrary to many announcements. An analytic look at the available products on the market reveals that SAE Level 2 [1] is still state-of-the-art in passenger cars, outdone in few applications to Level 3 for very restrictive applications (e.g., [2]). Level 4 automation, in particular for urban road networks, is still an open challenge (see [2]) and therefore in focus of current research. From a general perspective, the step from Level 3 to 4 is a shift from automated to autonomous driving. This step involves full environmental perception and decision making. Furthermore, the human driver can not be applied as safety fallback anymore. Consequently, it is a game changing development step. From implementation point of view a paradigm shift in system architecture is required since sensors must be shared between components and new concepts for multi-layer control software are required.

In contrast to the “under all conditions” requirement of Level 5 automation, which is quite problematic from a technical perspective, Level 4 automation solves the task of fully autonomous driving under clearly defined conditions, i.e., in a specified operational design domain (ODD). Different ODDs can be very diverse, e.g., valet parking and highway driving, and, hence, require a carefully matched AD function. From this point of view, a modular system architecture design (e.g., [3]) is beneficial ([2]). It enables the development of modular and, hence, reusable software components with respect to dedicated tasks of the fundamental sense-plan-act principal from robotics [4], and ODD-based assembly and tuning of these components. An attempt to overview the scientific state-of-the-art on all stages of the sense-plan-act principal, reveals a tremendous amount of highly sophisticated scientific solutions (see, for example, [5,6], (pp. 71–140) and [7]), with promising simulation and also real-world testing results in specific use cases. Although equivalent components solve the same task on a qualitative level, they diverge in their specific input/output data requirements. This fact complicates ODD-based AD function assembly, yielding potential performance interdependencies between the components. This has to be avoided since the components form a safety critical overall system. Hence, a clear strategy on the definition and implementation of component interfaces is beneficial. A common approach is to define very basic, static interfaces (cf. Autoware [8]), focusing on a minimized version of the shared information. The drawback of this approach is the need for repetitive wrapper code within the single software components adapting the interface signals to match the components’ requirements. Although this wrapper code is independent from the actual component algorithm, it eventually impacts the performance of the component and of the overall combined system. A modification that affects this code involves all components. In order to overcome this drawback, these wrapper-tasks may be assigned to a dedicated interface component following, if possible, a generic design approach. This enables a clear focus of the connected components on their dedicated tasks omitting component independent input/output data processing. Simultaneously, the application of dedicated interface components supports a middelware independent component development and reduces later integration risk in combination with different middleware concepts.

The design of such an interface has to handle manifold requirements of state-of-the-art components. This obviously, on the one hand, complicates the interface design to a challenging task. On the other hand, it reveals significant benefits especially in the ODD-based AD-function assembly, since it enables straight-forward combination of arbitrary state-of-the-art components.

This publication is dedicated to the design of such an interface, between the local motion planning system and the path tracking system, which is an essential part of every AD function. The interface, hence, shall be able to connect a comprehensive set of state-of-the-art path planning and path tracking algorithms (see Figure 1), resolving performance interdependencies to the greatest possible extend. This is of special interest for example in collision avoidance, see for example [9,10], since it requires an accurate coordination of path planning and tracking.

The interface design needs an overview on state-of-the-art components and algorithms. Therefore, the publication simultaneously features a survey contribution, in particular with respect to path tracking algorithms (from a specific point of view) and specific interpolation methods. The presented classification of lateral tracking error definitions based on a comprehensive set of state-of-the-art tracking controllers is essential for the proposed interface design, but also contributes to a better understanding of the impact of tracking error definition on the performance of a tracking controller. The proposed interface design, furthermore, may serve as conceptual model for the design of other interfaces in modular system architecture for AD functions.

In detail, the publication structures as follows: Section 2 outlines the general path tracking problem and identifies the lateral tracking error computation as a major challenge in the generic interface design. In order to tackle this challenge, Section 3 introduces a lateral tracking error classification approach. This proposed classification enables a generalized approach in tracking error computation (see Section 4), based on a concise set of three elementary path operations. This set is sufficient to cover a comprehensive set ot state-of-the-art path tracking controllers. Section 5 summarizes the contribution of the preliminary findings for the aimed interface design. Section 6 extends the interface requirements from the path planning side, yielding the final interface design concept in Section 7. Finally, in Section 8 a simple, exemplary ODD-based AD function assembly tasks is considered in order to demonstrate the proposed interface design and to substantiate its benefits. Appendix A and Appendix B provide continuative theoretical basics on path parametrization and interpolation.

2. The Path Tracking Problem

Path tracking is an important sub-problem of motion control in automated driving tasks. In contrast to the more general trajectory tracking (see for example [11,12], (p. 172)) the trajectory is split into a time-independent, spatial information—the reference path—and a time-dependent function, which defines the reference position at a specific time along this path. A lateral controller applies steering commands to approach the reference path—the so-called path tracking. Concurrently a longitudinal controller applies vehicle speed adaptions in order to track the time-dependent reference position along the path. The basic assumption behind a separated lateral and longitudinal control is almost decoupled lateral and longitudinal vehicle dynamics. In fact, they are actually coupled due to the limited traction forces of the vehicle tires and the time-dependent actuation limitations (steering rate). Whereas this assumption is valid in low- and moderate-speed driving at dry roads, respectively in high-speed driving with low steering dynamics, it is not valid in highly dynamic maneuvers, like emergency evasions or when driving on an icy road.

There exists several surveys on the classification of state-of-the-art tracking controllers like [5,13,14,15] and [6] (pp. 71–140). In general, the path tracking problem can be stated as follows: Given an planar reference path, which might be represented in a parametric way (cf. Appendix A) with respect to a curve parameter $\tau$,

$$\gamma \left(\tau \right)={\left[\begin{array}{cc}x\left(\tau \right)& y\left(\tau \right)\end{array}\right]}^T,$$

(1)

the path tracking controller has to compute a steering actuation, e.g., a steering wheel angle, in order to make a the position of the vehicle to follow the reference path. In order to use classical control system design approaches an appropriated error vector has to be defined,

$$\mathbf{e}\left(t\right)={\mathbf{f}}_{\mathrm{e}}(\gamma \left(\tau \right),\mathbf{p}\left(t\right))={\left[\begin{array}{ccc}{e}_{\mathrm{lat}}\left(t\right)& e_{\psi }\left(t\right)& \cdots \end{array}\right]}^T,$$

(2)

based on the reference path and the vehicle pose. The vehicle pose consists of the vehicle position $x\left(t\right),y\left(t\right)$ and heading $\psi \left(t\right)$ and possibly more vehicle states,

$$\mathbf{p}\left(t\right)={\left[\begin{array}{c}x\left(t\right),y\left(t\right),\psi \left(t\right),\cdots \end{array}\right]}^T.$$

(3)

The error vector consists of a mandatory spatial tracking error (some lateral offset error) and optionally of additional error measures like an orientation error or curvature error. Some special control approaches, e.g., Model Predictive Control (MPC), furthermore, require several lateral tracking errors corresponding to vehicle pose predictions.

With respect to a specific control error, the path tracking controller defines a steering command $\delta \left(t\right)$, which shall control the tracking error to zero, and consequently make the vehicle to follow the reference path:

$$\delta \left(t\right)=f_{\delta }\left(\mathbf{e}\left(t\right)\right):\mathbf{e}\left(t\right)\to \mathbf{0}$$

(4)

There are various reasonable possibilities to the define a lateral tracking error (see Figure 2) based on different motivations. In general, there exists no unique mappings between different lateral errors. It is an important but little-noticed fact that both the error definition and the control law design have to be considered as degrees of freedom in control system design and impact the final tracking performance.

The computation of the tracking error depends on the reference path, which is provided by the motion planning system. Consequently, its constitution and quality are defined by another component, which yields an undesired dependency on the planning system. Therefore, it is reasonable to think about outsourcing the tracking error computation to a generic interface component. To do so, it is necessary to analyze state-of-the-art path tracking algorithms with respect to the applied lateral tracking error definition. A unique classification of the used tracking error definitions and a generalization of the tracking error computation based on this classification is a major step towards the intend generic interface, which is addressed in the next sections.

3. Tracking Error Classification

Based on the analysis of a comprehensive set of state-of-the-art path tracking controllers (cf. Table 2), the introduction of three general and comprehensible classifier sets are introduced ($S_{\mathrm{vr}}$: vehicle reference, $S_{\mathrm{lh}}$: look-ahead (direction and distance) and $S_{\mathrm{eo}}$: error orientation), which are applicable to classify these controllers and to analyze their differences.

$$S_{\mathrm{SotA}}\in S_{\mathrm{vr}}\times S_{\mathrm{lh}}\times S_{\mathrm{eo}}$$

(5)

These classifiers shall now be discussed in more detail, in order to summarize the corresponding motivation and the effects on the control design and control performance.

3.1. Vehicle Reference Point

The vehicle reference might be defined at an arbitrary point on the vehicle chassis. There is a set of common reference points, based on a single-track abstraction of a front-axle-steered vehicle (see Figure 3) with different motivations:

• Rear axle: A vehicle, in general, features non-holonomic dynamics. The rear axle is the point of the vehicle with the "most constrained" motion. Assuming zero lateral slip, the motion of the rear axle is aligned with the vehicle heading. Therefore, a constant zero tracking implies that also the vehicle heading is aligned to the reference path, which is a favorable tracking property. From control system theory the center of the rear axle is of interest, as it is a flat output of the system restricting on slip-free vehicle kinematics (see for example [11,16]). The turning radius of the rear axle in cornering is smaller than the turning radius of the front axle (see Figure 4). Therefore, the choice of the rear axle as a vehicle reference point, in general, implies potential undesired overshooting of the vehicle’s front.
• Front axle: If the vehicle reference point is set to the center of the front axle, the non-holonomic vehicle kinematics in principle do not have to be considered in the control design, as stopping and adjustment of the steering angle enables tracking of arbitrary reference paths within the limited turning radius. This enables a simplified control design, especially for low dynamic driving tasks as parking. A drawback of this reference point is the smaller turning radius of the rear axle in cornering (cf. rear axle reference point), which implies potentially undesired curve cutting.
• Center of gravity: The choice of the center of gravity as a vehicle reference, simplifies the setup of the vehicle’s equations of motion. Therefore, it is used in many control system design approaches. From tracking perspective its position, somewhere in the middle of the car is of interest, in order to minimize the total distance of all points with respect to the reference path.
• Center of oscillations/percussion: In the center of oscillation or percussion, the translation and rotation impact of a lateral tire slip at the rear axle are in balance. Consequently, this point is of special interest in order to design control laws, which are robust with respect to lateral rear axle tires slip. The choice of this reference point is popular in tracking controllers designed for limit-handling, as racing applications (see for example [17,18]). For front-wheel-steered vehicles the position of the center of percussion with respect to the rear axle $l_{\mathrm{CP}}$ is:

  $$l_{\mathrm{CP}}=l_{\mathrm{CG}}+\frac{I_{\mathrm{zz}}}{m\times l_{\mathrm{CG}}},$$

  (6)

  where $l_{\mathrm{CG}}$ is the distance of rear axle and center of gravity, m the vehicle mass and $I_{\mathrm{zz}}$ the vehicle’s inertia in the center of gravity with respect to the vertical vehicle axis.

The set of vehicle reference classifiers $S_{\mathrm{vr}}$, hence, can be summarized as:

$$S_{\mathrm{vr}}=\left\{\begin{array}{cccc}\mathrm{rear},& \mathrm{front},& \mathrm{CG},& \mathrm{CP}\end{array}\right\}.$$

(7)

3.2. Look-Ahead

Due to the non-holonomic motion of a vehicle, reference points on the path parallel to the vehicle are out of reach without reverse driving or spacious maneuvers. Therefore, many tracking error definitions do not directly use the vehicle reference point to compute a lateral tracking error, but some point ahead of the vehicle reference point. The application of such a so-called look-ahead, or preview (see, for example, [19]), is a very natural behavior of human drivers. The look-ahead refers to the vehicle reference point and is defined by a look-ahead direction and a look-ahead distance. The introduction of a look-ahead enables preventive reaction to sudden direction changes of the reference path, which stabilizes the vehicle motion. As this becomes more crucial for higher vehicle speeds several tracking controllers (see, for example, [19,20,21,22]) use an adaptive, velocity dependent look-ahead distance, instead of a fixed distance. This is advantageous also if the tracking controller is applied in combination with simple motion planning systems, which do not provide a smooth path (cf. Section 8), since the look-ahead damps the impact of path discontinuities. In [23], the impact of this damping characteristic is analyzed with respect to control stability in frequency domain base on a linearized vehicle model. This damping characteristic at the same time reveals the main drawback of a look-ahead application. A smooth vehicle motion is achieved at the cost of worse tracking performance in the vicinity of the actual vehicle position (e.g., curve cutting). Even in the case of perfect reference tracking $e_{\mathrm{lat}}\left(t\right)\equiv 0$ the vehicle itself actually does not follow the planned reference path. This implies that planned reference path properties, like specific safety distances to obstacles, are withdrawn. If a tracking controller is applied in combination with a comprehensive motion planning system, consequently, one should carefully think about the application of a look-ahead in the tracking error definition. Three reasonable choices for the direction of a look-ahead appear (see Figure 5):

• look-ahead towards the vehicle heading,
• look-ahead towards the direction of motion in vehicle reference point,
• and look-ahead towards the reference path in a certain distance.

Considering vehicle kinematics (see Figure 4), the absolute direction of motion ${\psi }_{\mathrm{x}}$ in a vehicle reference point at distance $l_{\mathrm{x}}$ in front of the rear axle (towards the vehicle heading $\psi$), with respect to a steering angle $\delta$ is:

$${\psi }_{\mathrm{x}}=\psi +arctan\left(\frac{l_{\mathrm{x}}}{l}tan\delta \right).$$

(8)

This direction is obviously equal to the vehicle heading at the rear axle (for $l_{\mathrm{x}}=0$) and equal to the steering direction at the front axle ($l_{\mathrm{x}}=l$). The application of a look-ahead extends the possibilities in achieving specific constitution of the final model-based tracking problem, as it is proposed for example in [12] (pp. 199–201) (front axle vehicle reference and a look-ahead in direction of motion): In this case, decoupling and input–output linearization can be achieved with a static feedback. The above considerations yield the set of look-ahead classifiers $S_{\mathrm{lh}}$:

$$S_{\mathrm{lh}}=\left\{\begin{array}{ccc}\mathrm{heading},& \mathrm{motion},& \mathrm{path}\end{array}\right\}.$$

(9)

3.3. Error Orientation

Based on a vehicle reference point and the optional look-ahead (direction and distance) the orientation of the tracking error needs to be defined in order to compute a lateral tracking error. Similar to the definition of look-ahead directions, reasonable orientations are:

• perpendicular to the vehicle heading,
• perpendicular to the direction of vehicle motion in the vehicle reference point,
• perpendicular to the path.

For almost straight reference paths, different error orientations approximately coincide if the vehicle drives along the reference path. On the other hand, if the vehicle first has to approach the reference path, or drives along curvy path sections, differences reveal (see Figure 6). In summary the classification set for the error orientation is:

$$S_{\mathrm{eo}}=\left\{\begin{array}{ccc}\mathrm{heading},& \mathrm{motion},& \mathrm{path}\end{array}\right\}.$$

(10)

The above definitions can be used to give a comprehensive definition of a lateral tracking error based on the classifiers vehicle reference, look-ahead (direction and distance) and error orientation in the combined set,

$$S=S_{\mathrm{vr}}\times S_{\mathrm{lh}}\times S_{\mathrm{eo}},$$

(11)

according to (7), (9) and (10). Figure 6 exemplarily illustrates all possible error definitions for the vehicle reference at the front axle, i.e., for the set $\left\{\begin{array}{c}\mathrm{heading}\end{array}\right\}\times S_{\mathrm{lh}}\times S_{\mathrm{eo}}$, as listed in

Table 1. Corresponding tracking error definition classifiers to Figure 6.

	Look-Ahead	Error Orientation
$e_{0,\mathrm{h}}$	no	heading
$e_{0,\mathrm{m}}$	no	motion
$e_{0,\mathrm{p}}$	no	path
$e_{\mathrm{h},\mathrm{h}}$	heading	heading
$e_{\mathrm{h},\mathrm{m}}$	heading	motion
$e_{\mathrm{h},\mathrm{p}}$	heading	path
$e_{\mathrm{m},\mathrm{h}}$	motion	heading
$e_{\mathrm{m},\mathrm{m}}$	motion	motion
$e_{\mathrm{m},\mathrm{p}}$	motion	path
$e_{\mathrm{p},\mathrm{h}}$	path	heading
$e_{\mathrm{p},\mathrm{m}}$	path	motion
$e_{\mathrm{p},\mathrm{p}\left(\mathrm{h}\right)}$	path	path (heading)
$e_{\mathrm{p},\mathrm{p}\left(\mathrm{m}\right)}$	path	path (motion)

. In the case of a look-ahead towards the path and an error orientation perpendicular to the path, the lateral error has to be defined either with respect to the vehicle heading or motion (see errors $e_{\mathrm{p},\mathrm{p}\left(\mathrm{h}\right)}$ and $e_{\mathrm{p},\mathrm{p}\left(\mathrm{m}\right)}$).

Based on given coordinates of the vehicle reference point, a specified look-ahead distance and direction and error orientation define a reference point on the path. In addition to the lateral tracking error, this reference point can be used to compute further error measures like an orientation or curvature error. In [24], the choice of an appropriate heading error is discussed and its impact on the tracking performance is analyzed.

3.4. Application to State-of-the-Art Tracking Controller

To prove the applicability of the proposed tracking error definition classification, it is applied to a comprehensive set of state-the-art tracking controllers.

Table 2. Tracking error classification of state-of-the-art path tracking controllers.

Controller	Vehicle Ref.	Look-Ahead	Error Orient.
Hoffmann (Stanley) [25], Kolb [26]	front	no	path
Sun [27,28], Kritayakirane [17],	CG	no	path
Chen [29], Hu [30] Bruschetta [31]
Chatzikomis [14], Xu [19], Zhang [32]	CG	no	heading
Hiraoka [33]	CP	no	path
Tieber [34], Samson [35],	rear	no	path
Dominguez [36], Solea [37]
Nestlinger [20], Ackermann [38],	CG	heading	heading
ARGO [21], Guldner [23], Yuan [22]
Elkaim [39]	CG	heading	path
Solea [37]	rear	motion	path
Sentouh [40]	CG	motion	motion
Coulter (Pure-pursuit) [41]	rear	path	heading

lists the classification according to the specified classifiers.

While Table 2 shows the application of various vehicle reference points, and look-ahead directions, most tracking controllers are based on an error orientation perpendicular to the reference path or to the vehicle heading. Only one of the considered controllers [40] is based on an error orientation perpendicular to the vehicle motion in the reference point. A possible explanation for this is the fact that direct measurement of the actual vehicle motion direction is challenging due to the side slip of the tires. As an alternative, an estimation based on the yaw rate has to be used. In fact, in [40], the authors do not propose a steering controller for application in an autonomous vehicle but propose a human driver model for simulation purpose. In [42], a hybrid concept consisting of an Pure-pursuit and Stanley controller is proposed in order to combine a tracking error definition with look-ahead and without look-ahead. In [17], the control law is designed with a vehicle reference point in the center of percussion. The used lateral control error $e_{\mathrm{CP}}$, however, is a projection of the distance of the center of gravity to the path $e_{\mathrm{CG}}$:

$$e_{\mathrm{CP}}=e_{\mathrm{CG}}+d_{\mathrm{CG},\mathrm{CP}}\times sin{e}_{\psi },$$

(12)

according to the distance between center of gravity and center of percussion $d_{\mathrm{CG},\mathrm{CP}}$ and the heading error $e_{\psi }$. Therefore, the vehicle reference point is assigned to the center of gravity. In [27,28,31], an MPC is applied for path tracking. In every MPC step, actuation signals are optimized with respect to a specific cost function on a prediction horizon. In general, the cost function includes a deviation from the reference path, i.e., a lateral tracking error. Instead of an evaluation of the tracking error at a single vehicle pose (cf. Figure 8), hence additionally an evaluation at several predicted vehicle poses is required.

The choice of the single introduced classifiers can be considered as part of the control parametrization. As Figure 6 indicates, the actual control error computation is defined by specific geometrical operations with respect to the current vehicle pose, the control parametrization and the provided reference path. A generalization of the tracking error computation is presented in the next section.

4. Tracking Error Computation

Based on a generalized reference point, which already considers an optional vehicle-oriented look-ahead (except for a look-ahead towards to reference path), it is noticeable that despite the various possibilities in the tracking error definition the actual error computation can be handled with only five geometric operations (see

Table 3. Path operations.

	Operation
A	intersection line/path
B	intersection circle/path
C	point projection on path
a	intersection line/line
c	point projection on line

and

Table 4. Operations for error computation.

		Error Orientation
		Path	Heading	Motion
look-ahead	no	C	A	A
	path	B+a	B+c	B+c
	heading	C	A	A
	motion	C	A	A

and Figure 7).

The operations a (intersection of two lines) and c (projection of a point on a line) do not depend on the reference path and have simple analytic solutions. Contrary, the operations A (intersection of the reference path with a line), B (intersection of the reference path and a circle) and C (point projection onto the reference path) depend on the path representation (cf. Appendix A). Hence, the reference path representation also determines the resulting computational complexity. Some general statements can be made on this path operations.

4.1. Intersection of Reference Path and a Straight Line

After performing a translation and rotation of the path, this operation reveals as common root finding problem, which can, in general, not be solved analytically, for example in case of a higher order polynomial reference path. However, many well-established numeric algorithms like Newton-method, bisection-method or Brent-method, can be used to compute arbitrarily exact approximations to the solution of this problem (see, for example, [43,44,45]). The solution of this path operation is neither unique nor it exists for sure. Hence, tracking controllers relying on this path operation inevitably have to define a fallback solution for the control law. The fallback solution, e.g., a constant curvature turn, has to ensure the convergence to a region where the path operation yields a solution. With respect to the uniqueness, it is reasonable to use the closest solution.

4.2. Intersection of Reference Path and a Circle

From an analytic perspective, this operation can be considered equivalent to operation A after performing a transformation of the corresponding reference path section into polar coordinates, which is challenging for an arbitrarily parameterized path. From numerical perspective, it might also be considered as a generalization of the shortest-distance-problem (cf. operation C), searching for a fixed given distance to the reference path instead of the shortest distance. The solution of this path operation in general yields at least two solutions, which can be prioritized following again the most-progress-on-path principle. The solution of this path operation obviously does not exist if the shortest distance between the center point of the circle and the path exceeds the specified circle radius.While this offers a straight-forward method to test for the existence of a solution, there is, in contrast to operation A, no simple fallback, which can be applied for arbitrary controllers, which rely on this path operation. Therefore, a reliable fallback solution, which ensures that the vehicle is approaching the path, has to be design including the specific control law. For many controllers including the famous pure-pursuit controller [41], the solution of the shortest-distance-problem (see operation C) is applicable as a fallback solution.

4.3. Point Projection Onto the Reference Path

Point projection is a well investigated topic, but still an ongoing research field in geometry (see, for example, [46,47,48,49]). Although for some path representations (e.g., if the path consists of circular arcs) an analytic solution exists, most implementations apply iterative numeric methods, similar to path operation A, to compute approximations of the solution. The existence of a solution is not ensured. A widely used fallback for tracking controllers is to transition to the shortest-distance-problem. A solution to this fallback problem always exists and if a solution to the point projection problem exists, the solutions are equivalent. The ambiguity of the solution can be handled based on the path direction (choosing the solution which gains the most progress along the reference path).

5. Summary of Interface Requirements from Tracking Control Perspective

The comprehensive investigations of the last sections provide the theoretical backbone in order to state the general requirements for a generic planning and control interface from control side. The central idea for the interface implementation is to detach the tracking error computation from the control component. On the one hand, this avoids redundant computations in different control components. On the other hand, it enables careful coordination with respect to the representation of the provided reference path. This supports the performance of the overall system, which is especially of interest in safety critical applications like collision avoidance. According to Section 3, the definition of three classifiers (vehicle reference point, look-ahead and error orientation) is sufficient to define the lateral tracking error definition applied in state-of-the-art path tracking controllers. Furthermore, according to Section 4, three elementary path operations are sufficient to compute all possible tracking errors, which can be defined based on the introduced tracking error classifiers. Hence, these elementary path operations can be implemented with respect to the reference path representation outside of the actual path tracking component, in order to supply various different tracking controllers with the required tracking error, as illustrated in Figure 8.

In order to complete the interface concept, the following section consider the path planning problem in general and the interface requirements resulting from the state-of-the-art in path planning.

6. Interface Requirements from Path Planning Perspective

Similar to path tracking path planning, is a sub-problem of the more general trajectory planning problem. It focuses exclusively on the spatial planning, also known as lateral planning, neglecting the temporal aspect of the motion planning. The general limitations of the applicability of such a decoupled motion planning and control have already been mentioned in the Section 2. In addition, from planning perspective also limitations of this approach with respect to complex dynamic environments arise. However, this separation enables simplified planning for relevant use-cases like valet parking. The general path planning problem can be stated as follows: The planner has to compute a collision-free path from a given starting pose to a given final pose, complying constraints with respect to drivability (limited actuation systems, like a vehicle’s bounded steering angle), comfort (bounded lateral acceleration and jerk), efficiency (length of the path and necessary actuation effort) and safety (distance to obstacles). Many surveys on different path planning approaches and algorithms have been published (see, for example, [2,5,50,51,52]).

In contrast to the state-of-the-art path tracking controllers, where it was necessary to establish a reasonable generalization of the input requirements via a careful study of state-of-the-art components, the generalization of the output requirements of path planning components is more straight forward and does not need an extensive consideration of specific state-of-the-art path planning algorithms. On a qualitative level, there are two different output formats provided by path planning systems: Hermite path data and analytic curve expressions.

Hermite path data consist of a set of consecutive way points (position $x,y$↦ G0 Hermite data) and optional higher-order geometric information: tangent (position $x,y$ + orientation $\psi$↦ G1 Hermite data), curvature (position $x,y$s + orientation $\psi$ + curvature $\kappa$: ↦ G2 Hermite data (cf. Figure 9)) and so on. Hermite path data give a hint about the qualitative course of a continuous path, assuming that the single samples do not skip a significant section of the path.

Alternatively a path planning algorithm may provide the reference path in form of an analytic curve expression. The most commonly used analytic curve expressions are parametric curves. In Appendix A, an overview on the basics of parametric curves and commonly used parametric curves expressions in path planning are given.

The more accurate the shape of a single analytic curve shall be specified, the more complex representations (e.g., high-order polynomials) are required. In practice, this yields an increased computational complexity and corresponding numerical issues. Hence, it is far more practicable to represent the planned path not as one single analytic curve but as a sequence of aligned curve segments, in which each are defined by simple analytic curves, yielding a so-called spline. The application of a segmented path needs an adaption of the elementary path operations stated in Section 4. The determination of a tracking control error has to be managed in two stages:

• Global: Identification for the respective path segment.
• Local: Application of the actual error computation within the path segment (see Section 4).

The identification of the respective path segment can inflate to a complex issue, since the actual optimal solution of this task requires the application of the path operation (step 2) on each path segment. In order to reduce the computational effort for step 1, a practicable workaround is to aim for a sub-optimal solution. Such a solution can be obtained, for example by applying the path operation to a simplified version of the path, like for example a linear interpolation of the way point within the path segments. However, the discrepancy between the sub-optimal solution and the optimal one, may become significant especially for reference paths including sharp turns, loops or cusps.

In summary, the path representations provided by state-of-the-art path planning algorithms feature a huge diversity. There is no obvious link for a potential generalization similar to the error classification for path tracking. However, according to Section 5, the implementation of identified elementary path operations depends on the reference path representation. Therefore, it is reasonable to include an internal reference path representation into the interface, which, in general, may differ from a possible parametric path provided by the planner. Since it is straight forward to generate Hermite path data from a given parametric path, by path sampling, the generalized input format is defined as Hermite path data. The drawback of this definition is that the proposed interface may withdraw analytic curve expressions potentially provided by high-sophisticated planning components.

The choice for an internal path representation is a degree of freedom in the interface design. Appendix A gives important hints for the pros and cons of different curves. A common choice are polynomial splines. Such splines may be defined in different polynomial bases (e.g., monomial and Bernstein basis). The missing step to finalizing the wanted generic motion planning and control interface is the parametrization of the internal path with respect to given Hermite way point data. This is covered by the well investigate research field of interpolation. For sake of completeness, Appendix B surveys some state-of-the-art algorithms for the interpolation of Bezier splines, which serve as internal path representation for the exemplary implementation of the interface (cf. Section 8).

Figure 10 illustrates the intermediate result with respect to the input structure of the proposed generic interface.

7. A Generic Path Planning and Tracking Interface

Combining the above considerations from path planning and path tracking side, the concept for the generic interface design shall now be summarized (see Figure 11). The three major steps in the implementation of such an interface are:

• Decision for an internal path representation.
• Implementation of corresponding Hermite waypoint data interpolation algorithms (see Appendix B), in order to accomplish input (planning) modularity with respect to different data types (G0, G1, ⋯).
• Implementation of corresponding error computation, based on the path operations discussed in Section 4 (path-line intersection, path-circle intersection and point projection), in order to accomplish output modularity (control).

The key design decision is the choice of an internal path representation. The internal path representation, on the one hand, has to be able to accurately describe a planned reference path. On the other hand the computational aspects of the required interpolation and path operation algorithms have to be considered. It is an important fact that this design decision impacts the final performance of the motion planning and control system, in terms of tracking performance (cf. Section 8) and computational effort.

Such an interface is able to connect state-of-the-art path planning algorithms, which provide Hermite waypoint data, with state-of-the-art path tracking controller, which requires a lateral tracking error definition that is covered by the introduced error classifiers: vehicle reference, look-ahead and error orientation. Consequently, it enables the combination of a huge range of planning or tracking components without necessary interface modifications, which offers significant benefits in both simulation and operation:

• In simulation, it supports a straight-forward identification of an appropriate component set, based on iterative combination, simulation and evaluation, considering specific scenarios and corresponding KPIs. This is an important aspect of ODD-based AD function assembly. Furthermore, a specific error definition can be applied as common evaluation measure for a set of tracking controllers, which could not be compared on a quantitatively based on their different native error definition on a fair basis (cf. the example in Section 8).
• In operation, it enables the simultaneous execution of different software components as well as switching between different components. This on the one hand supports the design of AD-functions, for a set of varying ODDs extending the application range of Level 4 driving functions. On the other hand, it supports the application of redundant and fail-operational software in order to increase safety of an AD function.

In addition to these major benefits in simulation and operation, the application of the proposed interface offers additional possibilities in the AD function development. The resolution of the component interdependencies, which might impact the overall system performance, is a significant advantage in safety critical applications, like collision avoidance. Furthermore, as already mentioned in Section 2 and Section 3.4, the tracking error computation can be executed also on a set of vehicle poses, generated by some motion prediction in order to support, e.g., MPC-based path tracking approaches. However, there might occur cases, which exclude the possibility of outsourcing the error computation to an interface component for some algorithmic reasons. In this case, the proposed interface still can operate as a reference path pre-processing unit, which may provide reference path sections of fixed quality, with respect to configurable requirements, e.g., equidistant sampling and path continuity, without any modifications of the planning components. Finally, the application of specific error definitions based on the current and predicted vehicle poses are also applicable and beneficial as risk indicators in threat and risk assessment (see for example [53,54]).

8. Exemplary Interface Application

In this final section, some of the aforementioned benefits and aspects of a generic interface shall be demonstrated in a practical use case. Starting point is a simplified but exemplary ODD-based AD function assembly problem. A path tracking controller shall be selected for application in an AD function for highway driving. This ODD arises a considerable number of specific scenarios. This example is restricted to an exemplary lane-change maneuver. Therefore, a standardized maneuver—the second half of a standardized double lane-change maneuver in [31]—is considered. The maneuver is performed at a constant speed of $v=72$ km/h. Since no obstacles have to be considered in this maneuver a simple path planner is used. It uses cubic Bezier splines (cf. Appendix A) to plan a smooth trajectory within the defined maneuver corridor. The planned path is provided to the generic interface as G2 Hermite data, with a sample distance of 5 m. In order to show the impact of the internal path representation on the control performance, two different interface implementations are applied in simulation. The first one uses a simple linear path representation. The provided Hermite path data are interpolated linearly, resulting in piece-wise straight sections, respectively piece-wise linear orientation and curvature. Note that the linear interpolation of orientation and curvature do not represent the actual orientation and curvature of the resulting polygonal path, which would be piece-wise constant respectively zero, but serves as an improved approximation. The second interface implementation is based on piece-wise polynomial path sections an applies the interpolation algorithms described in Appendix B. The G2 Hermite waypoint data are interpolated with quintic Bezier splines in order to achieve a G2 continuous internal reference path.

An exemplary set of two state-of-the-art path tracking controllers is used with a fixed parametrization (see

Table 5. Parametrization of Stanley tracking controller.

Parameter	Value
k	19
$k_{\mathrm{soft}}$	1
$k_{\mathrm{ag}}$	0.013
vehicle reference	front
look-ahead	no
error orientation	path

and

Table 6. Parametrization of PurePursuit tracking controller.

Parameter	Value
l	2.68 m
$d_{\mathrm{lh}}$	10 m
vehicle reference	rear
look-ahead	path
error orientation	heading

), including the applied lateral tracking error definition according to the proposed classification in Section 3:

• Stanley ([25]):

  $$\delta \left(t\right)=e_{\psi }-k_{\mathrm{ag}}\times v^2\times {\kappa }_{ref}\times sin{e}_{\psi }+arctan\left(\frac{k\times e_{\mathrm{lat}}}{k_{\mathrm{soft}}+v}\right)$$

  (13)
• PurePursuit ([41]):

  $$\delta \left(t\right)=arctan\left(\frac{2\times l\times e_{\mathrm{lat}}}{d_{\mathrm{lh}}^2}\right)$$

  (14)

The two controllers shall just serve as an exemplary set of components for this demonstration. The performed evaluation can be extended straight forwardly for example to the entire set of tracking controllers listed in Table 2.

In order to compare the performance of different controllers, which, in general, apply different error definition, an additional lateral tracking error definition (vehicle reference: center of gravity, look-ahead: no, error orientation: heading) is used to provide a comparable error measure. The path planning system, the two exemplary interface implementations as well as the exemplary tracking controllers have been implemented in a Python-based software framework. This framework has been used to perform the simulations, which are discussed within the following section.

Discussion

Figure 12 shows the results of a series of four simulations (all combinations of the two controllers and the two interfaces implementations). According to the top plots, both controllers in principle accomplish the required scenarios task and keep the vehicle inside the defined scenario corridor. Due to its look-ahead the lateral error of the PurePursuit controller increase earlier, resulting in an earlier initiation of the lane-change maneuver. Furthermore, this yields a more smooth maneuver with reduced steering effort due to the damping behavior of a look-ahead in path tracking (cf. Section 3.2 and [23]). The drawback of this property is the curve-cutting behavior of the final vehicle motion, which brings the vehicle to the borders of the scenario corridor several times. Considering the defined common error measure, this fact substantiates in a considerable $\approx 1$ m) lateral offset of the vehicle’s center of gravity with respect to the reference path. From this point of view, the Stanley controller shows superior tracking performance to the cost of an increased steering effort.

The comparison of the two different applied interfaces reveals the important fact that the internal path representation impacts the final tracking performance. The non-smooth linear reference path yields a non-smooth tracking error. The damping characteristic of the PurePursuit’s look-ahead still ensures a satisfying steering command, which is almost equivalent to the corresponding steering command when applying the polynomial internal path. Contrary, the Stanley controller is affected through-out by this effect, yielding an unsatisfying jerky steering command. This consideration shows that in absence of an interface the Stanley controller is not applicable at all in this scenario in combination with the used planning system. Obviously, this is an illustrative edge-case example and the effect may be reduced when using a more dense sampling of the reference path, but, in general, this might be a fixed parameter of the planning system. The slight steering into the opposite direction of the Stanley controller results from an undesired property of the applied path interpolation algorithm, the so-called Runge’s phenomenon.

In order to conclude this exemplary evaluation, based on the defined error measure lateral offset of the vehicle’s center of gravity, the Stanley controller has to be favored in this scenario.

9. Conclusions

Level 4 autonomous driving requires AD-functions, which are carefully matched to the specific ODD. The scientific state-of-the-art provides a tremendous amount of dedicated algorithms, which may be applicable for specific tasks of an AD-function in different ODDs. Hence, contrary to developing AD-functions from scratch for each ODD, it is beneficial to aim for a modular system architecture with generic interfaces, enabling fast combination and evaluation of sets of algorithms, without any code adaptions. This publication is dedicated to the design of such a generic interface between a local path planning and path tracking system. In order to ensure modularity with respect to different state-of-the-art path tracking controller, it contributes a classification of controllers based on the applied lateral tracking error definitions. Based on this classification the actual requirements from control side in the error computation are identified in terms of elementary path operations. This substantiates the advantage of including an internal reference path representation into the interface in order to resolve the interdependencies between the path planning and the path tracking system and, hence, to achieve the required input modularity (on planning side) and output modularity (on control side). With these building blocks, the publication contributes a generic interface concept and a solid theoretical basis for occurring design decisions in the implementation. Two exemplary implementations are finally applied in a demonstrative ODD-based AD assembly task. The application of such an interface offers significant advantages in simulation, like straight-forward combination, evaluation, and benchmarking of set of components in different scenarios, as well as in operation, as a key element for fail-operational and ODD-adaptive AD-function design. A concluding overview on the technical content of the publication is represented in

Table 7. Overview on the proposed generic interface concept for path planning and tracking.

Approach	Analysis of requirements based on state-of-the-art components Identification of potentials for generalization Definition of component independent interface tasks and requirements
Concept	Interface internal continuous reference path representation (Section 6) Generalization of tracking error definition based on classifiers ((11) and Section 3) Implementation of elementary path operations (Table 3) based on the internal path representation (Section 4) Generalized tracking error computation based on error definition and path operations (Table 4) Parametrization of the internal path by Hermite interpolation of reference path data (Appendix B)
Benefits	Arbitrary combination of state-of-the-art path planning and tracking algorithms Avoidance of component independent input/output data processing within the components Push modular ODD-based AD function design (iterative combination, simulation and evaluation of path planning and tracking components) Support application of redundant and fail-operational software design to increase safety of an AD function (redundant operation and ODD-based switching of components)

.