WO2024013146A1

WO2024013146A1 - Method for controlling a vehicle

Info

Publication number: WO2024013146A1
Application number: PCT/EP2023/069141
Authority: WO
Inventors: Simon MANUZZI; Martin WOJKOWSKY; Mattis PASCH; Karsten Georg
Original assignee: Robert Bosch Gmbh
Priority date: 2022-07-12
Filing date: 2023-07-11
Publication date: 2024-01-18
Also published as: DE102022207103A1

Abstract

The invention relates to a method for controlling a vehicle (101), the method comprising: identifying a traffic situation from sensor data; identifying, using a traffic-situation analysis function, a behavior for the vehicle (101) appropriate for the traffic situation; specifying the identified behavior in the form of one or more driving tasks each having one or more associated parameter values which indicate the dynamic behavior of the vehicle (101) and/or a distance from a relevant reference point; generating, for each driving task, a driving-task data record comprising a specification of the driving task and of the relevant one or more associated parameter values; transferring each driving-task data record that has been generated to a movement-control function; generating, by means of the movement-control function, control signals for completing the one or more driving tasks; and controlling the vehicle (101) by means of the control signals that have been generated.

Description

title

Method for controlling a vehicle

State of the art

The present disclosure relates to methods of controlling a vehicle.

When providing driver assistance functions or functions for autonomous driving, a situation analysis is typically carried out followed by a motion control that determines control signals for the vehicle's actuators. Information about the corridor (lateral boundaries, dynamic objects such as other road users) that the movement control must take into account is transmitted via the interface between situation analysis and motion control.

A possible approach for this is that no corridor abstraction of the dynamic objects takes place. Objects with their real vehicle properties and relationships to the environment (e.g. lane assignment, vehicle type) are made directly available to the motion control. This makes very precise adaptation to the object type possible, and a respective driving task can be derived indirectly through the motion control. Driving dynamic limit values are not transmitted to the motion control; these are determined by the motion control itself. However, this creates a high dependency of the motion control on the situation analysis, a high application effort on the motion control side and a complex logic with many special cases.

Another approach is to combine all dynamic objects into a few boundaries, ie the objects to be taken into account in the control are preselected before the motion control. Driving dynamics limits apply generally for the interface and there is only one driving task (“drive to from”), which generally applies to the interface between situation analysis and motion control. However, this strong abstraction prevents targeted reactions to individual dynamic objects. In addition, the preselection of the relevant objects can lead to implausible overall behavior if the prediction of the dynamic objects is poor and the preselection therefore changes.

The invention is based on the object of avoiding the disadvantages of the above approaches and accordingly providing an interface between situation analysis and motion control, which provides an abstraction of a driving task, but at the same time provides the motion controller with all the information required to carry out the driving task comfortably and in the manner of a human driver.

Disclosure of the invention

According to various embodiments, a method for controlling a vehicle is provided, comprising determining a traffic situation from sensor data, determining, by means of a traffic situation analysis function, a behavior of the vehicle that is suitable for the traffic situation, specifying the determined behavior in the form of one or more driving tasks, each with one or more associated ones Parameter values that indicate the dynamic behavior of the vehicle and / or a distance from a respective reference point, generating, for each driving task, a driving task data set which has an indication of the driving task and the respective one or more associated parameter values, transferring each generated driving task -Data set to a motion control fiction, generating, through the motion control fiction, control signals to fulfill the one or more driving tasks; and

Controlling the vehicle using the control signals generated.

In the method described above, the driving task data sets (which are each assigned to an object, for example) provide an object-specific description of each driving task and the movement of the vehicle is limited specifically for each of the objects. The objects do not necessarily have to correspond to real objects, but can be created virtually. This enables flexible and fine adjustment of the vehicle movement, for example to user settings, ie user inputs that are recorded and according to which at least some of the parameter values are set, although generic driving tasks are still specified. The generic driving tasks enable a reduction in the complexity of the motion control (i.e. a motion controller) and enable reusability of individual components of the motion controller for various features (ACC (Adaptive Cruise Control) including predictive ACC, AEB (Autonomous Emergency Braking),... )

Various exemplary embodiments are given below.

Embodiment 1 is a method of controlling a vehicle as described above.

Embodiment example 2 is a method according to embodiment example 1, wherein the one or more associated parameter values indicate a limitation of a jerk and/or an acceleration and/or a speed.

In other words, the driving tasks are parameterized so that they are an abstract representation that can be adapted to a respective traffic situation, i.e. so that the traffic situation is described by the driving task data sets so that the motion control function can control the vehicle in an appropriate manner.

Embodiment example 3 is a method according to embodiment example 1 or 2, comprising determining one or more further road users, with at least some of the road users being assigned a respective driving task of the one or more driving tasks.

This creates an abstract representation of road users as one (or several) driving tasks and their consideration in the movement control, without the movement control fiction having to be given a detailed description of the other road users.

Embodiment 4 is a method according to one of embodiments 1 to 3, wherein for a driving task that is assigned to one of the road users and for the one or more parameter values indicate a distance from a respective reference point, the reference point is a geometric limit that is specified by the other road user.

This means that boundaries set by other road users (since failure to observe them would result in a collision) are taken into account.

Embodiment 5 is a method according to one of embodiments 1 to 4, wherein at least one of the driving tasks is assigned to a virtual object for which there is no real object in the area surrounding the vehicle.

This means that driving tasks, such as adhering to a speed limit, can be implemented or such a driving task can be transferred to the motion control in the form of a driving task data record.

Embodiment 6 is a method according to one of embodiments 1 to 5, wherein at least one of the driving tasks is assigned to a stationary object.

This means that driving tasks that do not arise from other road users but from stationary conditions, such as taking into account the end of the road, can be transferred to the motion control in the form of a driving task data set

Embodiment 7 is a vehicle control device that is set up to carry out a method according to one of embodiments 1 to 6.

Embodiment 8 is a computer program with instructions that, when executed by a processor, cause the processor to perform a method according to any of Embodiments 1 to 6.

Embodiment 9 is a computer-readable medium that stores instructions that, when executed by a processor, cause the processor to perform a method according to any of Embodiments 1 to 6. In the drawings, similar reference numbers generally refer to the same parts throughout the several views. The drawings are not necessarily to scale, emphasis instead being placed generally on illustrating the principles of the invention. In the following description, various aspects will be described with reference to the following drawings.

Figure 1 shows a vehicle.

Figure 2 shows an exemplary traffic scenario with an ego vehicle and several other road users.

Figure 3 shows an example of a traffic scenario with an ego vehicle, a first further vehicle with an assigned first geometric limit and a second vehicle with an assigned second geometric limit.

Figure 4 shows an example of a traffic scenario with an ego vehicle and another vehicle with an assigned U-shaped geometric boundary.

Figure 5 shows a flowchart that represents a method for controlling a vehicle according to an embodiment.

The following detailed description refers to the accompanying drawings, which show by way of explanation specific details and aspects of this disclosure in which the invention may be practiced. Other aspects may be used and structural, logical and electrical changes may be made without departing from the scope of the invention. The various aspects of this disclosure are not necessarily mutually exclusive, as some aspects of this disclosure may be combined with one or more other aspects of this disclosure to form new aspects.

Various examples are described in more detail below.

In modern vehicles, automated driving functions are increasingly being offered to relieve the driver's workload, for example highway or parking assistants or, in the future, piloted functions.

Figure 1 shows a vehicle 101. In the example of Figure 1, a vehicle 101, for example a car or truck, is provided with a vehicle control device 102.

The vehicle control device 102 includes data processing components, e.g. one or more processors (e.g. one or more CPUs (central processing unit) or microcontrollers) 103 and one or more memories 104 for storing control software 107 that is executed by the CPU 103 (i.e. according to which the vehicle control device 102 works) and data processed by the processor 103.

For example, the stored control software (computer program) 107 has instructions that, when executed by the processor, cause the processor 103 to perform driver assistance functions (or collect driving data) or even control the vehicle autonomously.

The data stored in memory 104 may include, for example, sensor data (e.g. image data) captured by one or more sensors 105 (e.g. cameras).

The vehicle control device 102 can then determine, for example based on the sensor data (e.g. images), whether and which objects, e.g. fixed objects such as traffic signs or road markings or moving objects such as pedestrians, animals and other vehicles (i.e. other road users) are present in the area surrounding the vehicle 101 are, i.e. carry out object detection.

The vehicle 101 can then be controlled by the vehicle control device 102 according to the results of the object detection. For example, the vehicle control device 102 may control an actuator 106 (e.g. a brake) to control the speed of the vehicle, e.g. to brake the vehicle.

The vehicle control device 102 can also be implemented in a distributed manner, ie implemented by several data processing devices (eg ECUs (Electronic Control Units) that are connected to one another. The control software 107 for the various driving functions (driver assistance or even autonomous driving) is typically complex and consists of many subcomponents that interact with each other.

For example, a control consists of data acquisition (using one or more sensors 105), processing (i.e. decision-making and generation of corresponding control signals) and the actual action according to the generated control signals by the actuators and / or respective controllers, etc.

The processing can have the following functional chain for the provision of an automated driving fiction:

1) Perception (e.g. detection of other vehicles)

2) Situation analysis (i.e. analysis of the traffic situation), SIT 108 in Figure 1

3) Movement planning (i.e. planning where, at what speed and at what acceleration the vehicle 101 will be moved)

4) Motion control (i.e. determination of control signals)

5) Actuator control

For example, each function is provided by a respective software component. The functions 3)-5) become the function of a “motion control device” or a “motion controller”, MC 109 in Figure 1, i.e. the function of the “motion control”, i.e. a movement control function, summarized.

Due to the complexity, the architecture for an automated driving fiction typically aims to divide the overall processing into manageable, smaller subtasks. These sub-problems should be able to be developed as independently of one another as possible and the dependencies between them should be as clear and structured as possible.

In particular for the interface 110 between the situation analysis 108 and the motion controller 109 (also referred to as the corridor interface), it is desirable that it achieves an abstraction of the vehicle environment, but at the same time passes on all the necessary information to the motion controller 109 so that it can implement the respective can implement the driving task (selected through the situation analysis) with the highest level of comfort, safety and comprehensibility. An abstraction is desirable in order to be able to implement the motion controller 109 as independently as possible of the specific driving function (ie driving task) and thereby increase its reusability (ie even if a module for perception or situation analysis 108, for example a respective software component, exchanged).

The motion controller 109 takes into account a respective “corridor” during processing. This is given by a lateral boundary (based on lanes, road boundaries,...) and dynamic and static objects (other road users such as other vehicles, people, animals and also static obstacles,...). The motion controller 109 must generate control signals for the actuators 106 (or respective controllers) in such a way that the vehicle 101 stays within the lateral boundaries and avoids collisions with dynamic objects and maintains a minimum distance therefrom.

According to various embodiments, the information required for this is transmitted from the situation analysis 108 to the motion controller 109 in the form of an abstracted description of (static or dynamic, real or virtual) objects around the (ego) vehicle 101, which is independent of the object type is. At the same time, driving dynamics limit values are assigned to each of these abstracted objects, which limit the reaction of the vehicle 101 (ego reaction) to this object. In addition, each of the objects is assigned an abstracted driving task, which specifies the expected behavior to this object to the movement controller 109.

In a traffic situation with the ego vehicle 101 and other road users, each of the other road users is assigned a driving task data record with the following information on the interface:

Driving task (for the ego vehicle) Geometric limit Dynamic limits Such driving task data sets that contain this or part of this information can also be assigned to other objects, in particular to each of one or more virtual objects.

The driving task describes an abstracted target behavior of the ego vehicle towards other road users (or generally the respective object). Possible (abstracted) driving tasks can be:

Following the geometric boundary with a defined distance Temporarily reducing the distance to the geometric boundary Avoiding collisions with the geometric boundary

Reaching a certain speed regardless of location (in this case, the driving task is assigned to a virtual object without a geometric boundary, for example)

Reaching a specific speed at a specific location (in this case, for example, the driving task is assigned to a virtual object and the geometric boundary indicates, for example, the location at which the speed is to be achieved)

Figure 2 shows an exemplary traffic scenario with an ego vehicle 201 and with several other road users 202, 203.

The boundaries 204 assigned to the other road users 202 are shown as dashed lines. In this example, they are located (along the course of the road) in front of the ego vehicle 201, each at the rear of another road user 202, 203, but they can also be behind the ego vehicle 202 at the front of road users 202, 203.

The boundaries 204 initially have no lateral restriction across the road, but are infinitely extended. A boundary does not need to be assigned exactly to a road user; rather, either several road users can be abstracted by a boundary, such as the two road users 203 here, whose rear is at the same height, or there is no physical equivalent of a geometric boundary (in the case of a virtual one Object to realize a specific driving task, such as the above task of reaching a speed at a specific location). The dynamic limits, which can be part of a driving task data set as a third component, are dynamic limits that indicate limitations on the vehicle movement that the movement controller 109 takes into account. Possible limits can be:

Minimum and maximum jerk limits (longitudinal and/or transverse)

Minimum and maximum acceleration limits (longitudinal and/or transverse) Minimum and maximum speed limits (longitudinal and/or transverse) Distance requirements (relative or absolute, longitudinal and/or transverse) Comfort level (relative)

Figure 3 shows an example of a traffic scenario with an ego vehicle 301, a first further vehicle 302 with an associated first geometric boundary 304 and a second vehicle 303 with an associated second geometric boundary 305.

The situation analysis 108 determines here that it should be avoided that the ego vehicle 301 overtakes on the right (e.g. for ACC).

Table 1 shows examples of the data set for the first additional vehicle 302 (right column) and the data set for the second additional vehicle 303 (middle column), which the situation analysis 108 transmits to the motion controller 109 via the interface 110.

Table 1

For the vehicle in the left lane (first additional vehicle 302), the driving task can also be “reaching a certain speed at a certain place” if one assumes that the vehicle can be overtaken on the right at a certain relative speed.

The maximum number of road users (or objects, which can also include virtual objects) for which the situation analysis 108 transmits data sets to the motion controller 109 via the interface 110 is not limited. As mentioned above, a data set (for a virtual object) with only one driving task and dynamic limits can also be transferred to the motion controller 109. For example, a simple cruise control can be implemented in which only a desired speed is set.

In a further embodiment, the interface 110 can be expanded for lateral driving functions (i.e. driving tasks). In this case, the one-dimensional geometric boundary is extended to a two-dimensional U-shape, for example. The other two components are retained, so that a data set that is transmitted on the interface 110 can have the following components in this embodiment: Driving task Geometric limit (two-dimensional U-shape) Dynamic limits

In this embodiment, the lateral extent of other road users or other objects is taken into account. As in the previous case, these do not have to be real objects (but an object can also be a virtual object) and stationary objects (lost charge, etc.) can also be abstracted.

Figure 4 shows an example of a traffic scenario with an ego vehicle 401 and another vehicle 402 with an assigned geometric (U-shaped) boundary 403. The situation analysis 108 determines here that an emergency evasion function should be carried out.

Table 2 shows an example of the data record for the additional vehicle 402, which the situation analysis 108 transmits to the motion controller 109 via the interface 110.

Table 2

In this case, the interface 110 enables a combined longitudinal and transverse reaction of the ego vehicle 401 to the traffic situation.

In summary, according to various embodiments, a method is provided as shown in Figure 5.

Figure 5 shows a flowchart 5, which represents a method for controlling a vehicle according to an embodiment.

In 501, a traffic situation is determined from sensor data (i.e. sensor data is recorded and a traffic situation is determined from it, e.g. using object detection, etc.).

In 502, a traffic situation analysis function is used to determine vehicle behavior that is suitable for the traffic situation (complete control, depending on the case). of the vehicle or a control to assist the driver, such as maintaining a distance).

In 503, the determined behavior is specified in the form of one or more driving tasks, each with one or more associated parameter values that indicate the dynamic behavior of the vehicle and/or a distance from a respective reference point (i.e. a geometric limit in the above examples).

In 504, a driving task data record is created for each driving task, which contains information about the driving task and the respective one or more associated parameter values. The driving task data record can be generated in the form of a predetermined driving task data record structure. The driving task data set structure is, for example, a structure corresponding to one of the two right columns of Table 1 or the right column of Table 2, which has fields (information elements) for the driving tasks and the parameter values, i.e. a data structure such as a struct or a class for each driving task -Record. Alternatively, individual partial information (e.g. distance information, acceleration limit,...) for all objects can be packaged in a data type (i.e. an array, a vector or a list for the distance information of all objects, limits of all objects, etc.) and each individually (without the explicit use of a struct) via the interface. Then the driving task data set structure corresponds to a structure that results when all data structures (each storing one type of information such as distances, limits, etc.) are considered together, i.e. as the structure that contains all such arrays, lists, vectors, etc. The parameter values can also specify ranges, e.g. in the form of an interval or a comfort level as in the examples above.

In 505, each generated driving task data set is passed to a motion control fiction.

In 506, the motion control function generates control signals to fulfill the one or more driving tasks.

In 507, the vehicle is controlled using the control signals generated (ie, for example, the control signals are transferred to actuators or respective controllers, etc.). The method of Figure 5 is computer implemented according to various embodiments and can be carried out by one or more computers with one or more data processing units. The term “data processing unit” can be understood as any type of entity that enables the processing of data or signals. The data or signals may, for example, be treated according to at least one (ie, one or more than one) specific function performed by the data processing unit. A data processing unit may be an analog circuit, a digital circuit, a logic circuit, a microprocessor, a microcontroller, a central processing unit (CPU), a graphics processing unit (GPU), a digital signal processor (DSP), a programmable gate array integrated circuit (FPGA), or any combination include it or be formed from it. Any other way to implement the functions described herein may also be understood as a data processing unit or logic circuitry. One or more of the method steps described in detail here can be carried out (e.g. implemented) by a data processing unit through one or more special functions that are carried out by the data processing unit. The traffic situation analysis function and the motion control function can be implemented by the same or by separate data processing units or data processing devices.

Different embodiments can receive sensor signals from different sensors such as. B. Receive and use video, radar, LiDAR, ultrasound, motion, thermal imaging, etc. to determine the traffic situation. The sensor data can be processed appropriately for this purpose. This may include classifying the sensor data or performing semantic segmentation on the sensor data, for example to detect the presence of objects (in the vicinity of the vehicle).

Although specific embodiments have been shown and described herein, it will be recognized by those skilled in the art that the specific embodiments shown and described may be substituted for a variety of alternative and/or equivalent implementations without departing from the scope of the present invention. This application is intended to cover any adaptations or variations of the specific embodiments discussed herein. Therefore, it is intended that this invention be limited only by the claims and the equivalents thereof.

Claims

Expectations

1. Method for controlling a vehicle, comprising:

Determining a traffic situation from sensor data;

Determining, through a traffic situation analysis function, behavior of the vehicle that is suitable for the traffic situation;

Specifying the determined behavior in the form of one or more driving tasks, each with one or more associated parameter values that indicate the dynamic behavior of the vehicle and / or a distance from a respective reference point;

Generating, for each driving task, a driving task data set which has an indication of the driving task and the respective one or more associated parameter values;

passing each generated driving task record to a motion control function;

Generating, through the motion control function, control signals to fulfill the one or more driving tasks; and controlling the vehicle using the generated control signals.

2. The method of claim 1, wherein the one or more associated parameter values indicate a limitation of a jerk and/or an acceleration and/or a speed.

3. The method according to claim 1 or 2, comprising determining one or more further road users, with at least some of the road users being assigned a respective driving task of the one or more driving tasks.

4. The method according to any one of claims 1 to 3, wherein for a driving task that is assigned to one of the road users and for which the one or more parameter values represent a distance from a respective reference point specify that the reference point is a geometric boundary that is specified by the other road user. Method according to one of claims 1 to 4, wherein at least one of the driving tasks is assigned to a virtual object for which there is no real object in the environment of the vehicle. Method according to one of claims 1 to 5, wherein at least one of the driving tasks is assigned to a stationary object. Vehicle control device which is set up to carry out a method according to one of claims 1 to 6. Computer program having instructions which, when executed by a processor, cause the processor to carry out a method according to any one of claims 1 to 6. A computer-readable medium storing instructions which, when executed by a processor, cause the processor to perform a method according to any one of claims 1 to 6.