Driving assistance systems and computer programs

Abstract

To provide a driving support device and computer program capable of avoiding an obstacle in traveling a turning section and also generating a travel track where a vehicle is restricted from performing an unnatural behavior as the travel track to be recommended for vehicle traveling.SOLUTION: A driving support device performs: acquiring a travel plan route for a vehicle to travel; acquiring obstacle information related to an obstacle existing on the travel plan route; setting directions of the vehicle when the vehicle arrives at a start point and an end point of a turning section based on the travel plan route when the route includes the turning section where the vehicle travels by turning in traveling in accordance with the travel plan route; avoiding the obstacle in the turning section with the use of the obstacle information and generating a travel track to be recommended for vehicle traveling on condition that the directions of the vehicle when arriving at the start point and the end point of the turning section are the set directions; and performing a driving support of the vehicle based on the generated travel track.SELECTED DRAWING: Figure 29

Description

Technical Field

[0001] The present invention relates to a driving support device and a computer program for supporting the driving of a vehicle.

Background Art

[0002] In recent years, as a driving mode of a vehicle, in addition to manual driving that travels based on a user's driving operation, an automatic driving support system that assists the user in driving the vehicle by the vehicle side executing part or all of the user's driving operation has been newly proposed. In the automatic driving support system, for example, the current position of the vehicle, the lane in which the vehicle travels, and the positions of other surrounding vehicles are detected at any time, and vehicle controls such as steering, drive source, and brake are automatically performed so as to travel along a preset route.

[0003] Also, when performing driving by the above automatic driving support or performing various driving supports for other vehicles, a travel trajectory recommended for travel is generated in advance on the road on which the vehicle travels based on the planned travel route of the vehicle, map information, etc. Here, as a technique for generating the above travel trajectory for a section where the vehicle travels with turning (hereinafter referred to as a turning section), such as a road with a curved shape, for example, Japanese Patent Application Laid-Open No. 2017-100652 discloses a technique for generating a travel trajectory that improves the riding comfort of the vehicle by using, as the travel trajectory, a trajectory having a larger radius of curvature in the turning part than the trajectory along the center line of the road. Further, a technique for correcting the travel trajectory so as to ensure a predetermined safety distance from an obstacle such as another vehicle when the generated travel trajectory is close to an obstacle is also disclosed.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Summary of the Invention

[0005] However, in the above-mentioned Patent Document 1, the vehicle's orientation at the start and end points of the turning section is not considered when correcting the driving trajectory based on the above-mentioned obstacle. Therefore, as a result of correcting the driving trajectory to avoid the obstacle, the vehicle's orientation at the start and end points of the turning section when traveling along the corrected driving trajectory may not be the recommended orientation. For example, in the example shown in Figure 42, a driving trajectory 152 is shown that has been corrected to avoid the obstacle 151 in a turning section consisting of a curved road. However, when the vehicle travels along the driving trajectory 152, the orientation (angle) of the vehicle body at the end point of the turning section is not aligned with the subsequent straight road, and the steering is not in a neutral position. Therefore, a corrected trajectory 153 is required to correct the vehicle body orientation to be in the same direction as the straight road and the steering to be in a neutral position. As a result, the vehicle's behavior is not smooth, and sudden speed changes and lateral acceleration occur, resulting in a problem where the driving trajectory is not the recommended one for the vehicle. Furthermore, while Figure 42 shows the end point of the turning section and the subsequent road connection, similar problems may occur at the starting point of the turning section and the road connection just before it.

[0006] The present invention has been made to solve the aforementioned problems of the conventional method, and aims to provide a driving assistance device and computer program that, when generating a driving trajectory that avoids obstacles in a turning section, prevents unnatural behavior of the vehicle at at least one of the start or end points of the turning section, and enables the generation of a driving trajectory that is recommended for the vehicle, suppressing sudden speed changes and lateral acceleration. [Means for solving the problem]

[0007] To achieve the above objective, the present invention FirstThe driver assistance system includes: a planned route acquisition means for acquiring the planned route on which the vehicle will travel; a turning section acquisition means for acquiring turning sections on which the vehicle will travel while turning when traveling along the planned route; an obstacle information acquisition means for acquiring obstacle information regarding obstacles present on the planned route; a direction setting means for setting the direction of the vehicle when it reaches a target point that includes at least one of the start and end points of the turning section based on the planned route; a driving trajectory generation means for generating a driving trajectory that avoids obstacles in the turning section and is recommended for vehicle travel, using the obstacle information, provided that the direction of the vehicle when it reaches the target point is the direction set by the direction setting means; and a driver assistance means for providing driving assistance to the vehicle based on the driving trajectory generated by the driving trajectory generation means. Furthermore, the trajectory generation means determines whether the obstacle is located in a position that overlaps with the center line of the lane the vehicle is scheduled to travel in, when the turning section is a section on a curved road in which the vehicle will be turning, and if the obstacle is located in a position that overlaps with the center line, it uses the center line as a reference and generates a trajectory that does not overlap with the obstacle in the overlapping section within the center line that includes the area overlapping with the obstacle, as the recommended trajectory for the vehicle. . Furthermore, the second driving assistance device according to the present invention includes: a driving route acquisition means for acquiring a planned driving route on which the vehicle will travel; a turning driving section acquisition means for acquiring a turning section on which the vehicle will travel while turning when traveling according to the planned driving route; an obstacle information acquisition means for acquiring obstacle information regarding obstacles present on the planned driving route; a direction setting means for setting the direction of the vehicle when it reaches a target point that includes at least one of the start and end points of the turning section based on the planned driving route; and a driving trajectory that avoids the obstacles in the turning section and is recommended for vehicle travel, provided that the direction of the vehicle when it reaches the target point is the direction set by the direction setting means. The system comprises a road generation means and a driving support means that provides driving support for a vehicle based on a driving trajectory generated by the driving trajectory generation means. The driving trajectory generation means determines whether the obstacle is located in a position that overlaps with the center line of the lane the vehicle is scheduled to travel in, when the turning section is a section on a curved road in which the vehicle will be turning. If the obstacle is located in a position that does not overlap with the center line, the driving trajectory generation means uses a reference driving trajectory, which is a driving trajectory recommended for the vehicle in the turning section generated without considering the obstacle, as a reference, and modifies the overlapping section within the reference driving trajectory, which includes the area overlapping with the obstacle, so that the trajectory does not overlap with the obstacle, and generates a driving trajectory that is recommended for the vehicle. Furthermore, "sections involving vehicle turns" include, for example, sections where the road curves in an arc with a predetermined curvature (including shapes where the curvature of the road changes), sections where the road bends at a predetermined angle such as a right angle, and sections at intersections (junctions) where vehicles turn left or right. In addition, this includes not only sections on public roads, but also sections within facilities such as parking lots where vehicles turn, sections where vehicles turn to enter or exit a parking space, or sections where vehicles turn to enter or exit a facility from a public road. Furthermore, "vehicle orientation" may refer to the orientation (angle) of the vehicle's body, or the direction of travel of the vehicle (direction of the tires, steering angle).

[0008] Furthermore, according to the present invention FirstThe computer program is a program that generates support information used for driving assistance implemented in a vehicle. Specifically, the computer functions as: a driving route acquisition means for acquiring the planned driving route of the vehicle; a turning section acquisition means for acquiring turning sections in which the vehicle turns when driving along the planned driving route; an obstacle information acquisition means for acquiring obstacle information regarding obstacles present on the planned driving route; a direction setting means for setting the direction of the vehicle when it reaches a target point that includes at least one of the start and end points of the turning section based on the planned driving route; a driving trajectory generation means for generating a driving trajectory that avoids obstacles in the turning section and is recommended for vehicle driving, using the obstacle information, provided that the direction of the vehicle when it reaches the target point is the direction set by the direction setting means; and a driving assistance means for providing driving assistance to the vehicle based on the driving trajectory generated by the driving trajectory generation means. It is a computer program. Furthermore, the trajectory generation means determines whether the obstacle is located in a position that overlaps with the center line of the lane the vehicle is scheduled to travel in, when the turning section is a section on a curved road in which the vehicle is turning. If the obstacle is located in a position that overlaps with the center line, the means generates a trajectory that does not overlap with the obstacle in the overlapping section within the center line, using the center line as a reference, and is recommended as the trajectory for the vehicle to travel. Furthermore, a second computer program according to the present invention is a program that generates support information used for driving assistance implemented in a vehicle. Specifically, it is a computer program that causes the computer to function as: a driving route acquisition means for acquiring a planned driving route on which the vehicle will travel; a turning section acquisition means for acquiring a turning section on which the vehicle will travel while turning when traveling according to the planned driving route; an obstacle information acquisition means for acquiring obstacle information regarding obstacles present on the planned driving route; a direction setting means for setting the direction of the vehicle when it reaches a target point that includes at least one of the start and end points of the turning section based on the planned driving route; a driving trajectory generation means for generating a driving trajectory that avoids obstacles in the turning section and is recommended for vehicle travel, using the obstacle information, on the condition that the direction of the vehicle when it reaches the target point is the direction set by the direction setting means; and a driving assistance means for providing driving assistance to the vehicle based on the driving trajectory generated by the driving trajectory generation means. Furthermore, if the turning section is a section on a curved road where a vehicle makes a turn, the trajectory generation means determines whether the obstacle is located in a position that overlaps with the center line of the lane the vehicle is scheduled to travel in. If the obstacle is located in a position that does not overlap with the center line, the means generates a trajectory that is recommended for the vehicle, using a reference trajectory, which is a trajectory that the vehicle is recommended to travel in the turning section, as a reference. The trajectory is modified so that the overlapping section within the reference trajectory, which includes the area overlapping with the obstacle, does not overlap with the obstacle. [Effects of the Invention]

[0009] The present invention having the above configuration First and second Driving assistance systems 、 According to the computer program, when generating a driving trajectory that avoids obstacles, especially in a turning section, it is possible to prevent unnatural vehicle behavior at at least one of the start or end points of the turning section, and to generate a driving trajectory that is recommended for the vehicle while suppressing sudden speed changes and lateral acceleration. As a result, it becomes possible to provide appropriate driving assistance that does not burden the vehicle's occupants. [Brief explanation of the drawing]

[0010] [Figure 1] This is a schematic diagram showing the driver assistance system according to this embodiment. [Figure 2] This is a block diagram showing the configuration of the driver assistance system according to this embodiment. [Figure 3] This figure shows an example of obstacle information managed by the server device according to this embodiment. [Figure 4] It is a block diagram showing the navigation device according to this embodiment. [Figure 5] It is a flowchart of the automatic driving support program according to this embodiment. [Figure 6] It is a diagram showing an area where high-precision map information is acquired. [Figure 7] It is a diagram explaining a method for calculating a dynamic driving trajectory. [Figure 8] It is a flowchart of a sub-processing program for static driving trajectory generation processing. [Figure 9] It is a diagram showing an example of a planned driving route of a vehicle. [Figure 10] It is a diagram showing an example of a lane network constructed for the planned driving route shown in FIG. 9. [Figure 11] It is a flowchart of a sub-processing program for driving trajectory generation processing in a turning section. [Figure 12] It is a diagram showing an example of a turning section including a road with a curve shape. [Figure 13] It is a diagram explaining a case where a reference driving trajectory and an obstacle overlap. [Figure 14] It is a flowchart of a sub-processing program for reference driving trajectory generation processing. [Figure 15] It is a diagram showing an example of the orientation of a vehicle set for the start point and end point of a turning section. [Figure 16] It is a diagram explaining a method for setting a clipping point. [Figure 17] It is a diagram explaining an example of multiplying start vectors and end vectors. [Figure 18] It is a diagram explaining a case where an arc with the largest radius of curvature passing in the traveling direction of each vector of the start vector and the end vector is included within the lane in which the vehicle travels. [Figure 19] It is a diagram explaining a case where an arc with the largest radius of curvature passing in the traveling direction of each vector of the start vector and the end vector is not included within the lane in which the vehicle travels. [Figure 20]This figure shows candidate trajectories generated for a turning section. [Figure 21] This figure shows the method for generating the second and third travel tracks. [Figure 22] This diagram shows an example of a correction to smooth the running trajectory. [Figure 23] This is a flowchart of the sub-processing program for the first avoidance trajectory generation process. [Figure 24] This diagram illustrates an example of using multiple start and end vectors. [Figure 25] This is a flowchart of the sub-processing program for the second avoidance trajectory generation process. [Figure 26] This diagram shows guide lines that are set along the centerline of the lane. [Figure 27] This diagram shows the area where the lane centerline and an obstacle overlap. [Figure 28] This diagram shows the overlapping intervals. [Figure 29] This diagram shows the guide lines after being modified so that the overlapping sections do not overlap with obstacles. [Figure 30] This diagram shows guide lines and their moving averages. [Figure 31] This diagram shows candidate passing points for vehicles at the boundaries where overlapping sections are divided. [Figure 32] This diagram shows the path vector, which identifies the recommended vehicle direction when passing through a waypoint. [Figure 33] This is a flowchart of the sub-processing program for the third avoidance trajectory generation process. [Figure 34] This diagram shows guide lines that are set along the reference track. [Figure 35] This diagram shows the area where the reference track and obstacles overlap. [Figure 36] This diagram shows the overlapping intervals. [Figure 37] This diagram shows the guide lines after being modified so that the overlapping sections do not overlap with obstacles. [Figure 38] This diagram shows an example of a driving trajectory generated when the section of the intersection (junction) where a vehicle turns right or left is treated as a turning section. [Figure 39] This diagram shows an example of a driving trajectory generated when a turning section is defined as a turning section for entering or exiting a parking space. [Figure 40] This diagram shows an example of a travel trajectory generated when a section of the vehicle makes a turn to enter or exit a facility from a public road. [Figure 41] This diagram shows an example of a trajectory connecting two vectors (start vector and end vector) set at any two points. [Figure 42] This diagram illustrates the problems with conventional technology. [Modes for carrying out the invention]

[0011] Hereinafter, an embodiment of the driver assistance device according to the present invention, implemented in a navigation device 1, will be described in detail with reference to the drawings. First, the schematic configuration of the driver assistance system 2 including the navigation device 1 according to this embodiment will be described using Figures 1 and 2. Figure 1 is a schematic configuration diagram showing the driver assistance system 2 according to this embodiment. Figure 2 is a block diagram showing the configuration of the driver assistance system 2 according to this embodiment.

[0012] As shown in Figure 1, the driver assistance system 2 according to this embodiment basically comprises a server device 4 provided by the information distribution center 3 and a navigation device 1 mounted on the vehicle 5 that provides various support for the autonomous driving of the vehicle 5. Furthermore, the server device 4 and the navigation device 1 are configured to send and receive electronic data to and from each other via a communication network 6. In addition, other in-vehicle devices mounted on the vehicle 5 or a vehicle control device that controls the vehicle 5 may be used instead of the navigation device 1.

[0013] Here, vehicle 5 is a vehicle that can perform not only manual driving based on the user's driving operations, but also assisted driving through automated driving assistance, in which the vehicle automatically drives along a pre-set route or path without user operation.

[0014] Furthermore, autonomous driving assistance may be provided for all road sections, or it may be configured to be provided only while the vehicle is traveling through specific road sections (for example, highways with gates (regardless of whether they are manned or unmanned, tolled or free) at the boundaries). In the following explanation, the autonomous driving sections in which vehicle autonomous driving assistance is provided will include all road sections, including general roads and highways, as well as parking lots, and will be described as basically providing autonomous driving assistance from the time the vehicle starts traveling until it stops traveling (until the vehicle is parked). However, it is desirable that autonomous driving assistance not be provided every time the vehicle travels through an autonomous driving section, but only when the user selects to provide autonomous driving assistance (for example, by turning on the autonomous driving start button) and when it is determined that it is possible to provide autonomous driving assistance. On the other hand, vehicle 5 may be a vehicle that is only capable of autonomous driving assistance.

[0015] In the vehicle control for automated driving assistance, for example, the vehicle's current position, the lane it is traveling in, and the positions of surrounding obstacles are detected in real time, and the steering, drive source, brakes, and other vehicle controls are automatically performed so that the vehicle travels along the driving trajectory generated by the navigation device 1, as described later, and at a speed according to the speed plan that was also generated. In this embodiment, the vehicle is driven by the automated driving assistance system for assisted driving, including lane changes, right and left turns, and parking operations. However, for special driving operations such as lane changes, right and left turns, and parking operations, the vehicle may be driven manually without the automated driving assistance system.

[0016] On the other hand, the navigation device 1 is mounted in the vehicle 5 and is an in-vehicle device that displays a map of the area around the vehicle's position based on map data held by the navigation device 1 or map data acquired from an external source, allows the user to input a destination, displays the vehicle's current position on the map image, and provides driving guidance along a set guidance route. In this embodiment, in particular, when the vehicle performs assisted driving using automated driving assistance, it generates various support information related to automated driving assistance. Examples of support information include the recommended driving trajectory for the vehicle (including the recommended lane movement pattern), the selection of a parking position for parking the vehicle at the destination, and a speed plan indicating the vehicle speed when driving. Further details of the navigation device 1 will be described later.

[0017] Furthermore, the server device 4 performs route searching in response to a request from the navigation device 1. Specifically, the navigation device 1 sends information necessary for route searching, such as the departure point and destination, to the server device 4 along with the route search request (however, in the case of a re-search, it is not always necessary to send information about the destination). Upon receiving the route search request, the server device 4 uses its map information to perform a route search and identifies a recommended route from the departure point to the destination. It then sends the identified recommended route to the requesting navigation device 1. The navigation device 1 can then provide the user with information about the received recommended route, or it can use the recommended route to generate various support information related to automated driving assistance, as described later.

[0018] Furthermore, in addition to the normal map information used for route searching, server device 4 also possesses high-precision map information and facility information, which are more accurate map information. The high-precision map information includes, for example, information on road lane shapes (road shape, curvature, bending angle, lane width, etc. for each lane) and road markings (center line of the roadway, lane boundary lines, outer line of the roadway, guidance lines, etc.). It also includes information on intersections. In addition, it includes regulatory information that identifies the type and location of road markings that restrict (more specifically require stopping or slowing down) vehicle traffic, such as speed limits, traffic lights, pedestrian crossings, railway crossings, and stop signs (hereinafter referred to as "regulatory objects"). On the other hand, facility information is more detailed information about facilities that is stored separately from the facility information included in the map information. For example, it includes facility floor maps, information on parking lot entrances and exits, information on the layout of passages (roadways) and parking spaces in the parking lot, information on road markings that demarcate parking spaces and roadways, and connection information that shows the connection relationship between parking lot entrances and exits and lanes.

[0019] Furthermore, server device 4 also possesses obstacle information that identifies the type and location (and shape (occupied area) if it spans a range) of obstacles on roads and in parking lots. Examples of obstacles include vehicles parked on the road, signs and fences installed at road construction sites, uneven road surfaces, and structures such as utility poles and blocks. The type and location of obstacles can be identified, for example, by collecting camera images and sensor detection results from vehicles actually driving on roads and in parking lots.

[0020] The server device 4 then distributes high-precision map information, facility information, and obstacle information in response to requests from the navigation device 1. The navigation device 1 uses the high-precision map information, facility information, and obstacle information distributed from the server device 4 to generate various support information related to autonomous driving assistance, as described later. The high-precision map information is basically map information that covers only roads (links) and their surroundings, but it may also include areas other than those around roads.

[0021] However, the route search process described above does not necessarily have to be performed by the server device 4; if the navigation device 1 has map information, it may be performed by the navigation device 1. Also, high-precision map information and facility information may be provided by the navigation device 1 in advance, rather than being distributed from the server device 4.

[0022] Furthermore, the communication network 6 includes numerous base stations located throughout the country and communication companies that manage and control each base station, and is constructed by connecting the base stations and communication companies to each other via wired (optical fiber, ISDN, etc.) or wireless connections. Here, each base station has a transceiver (transceiver) and antenna that communicates with the navigation device 1. In addition to conducting wireless communication between communication companies, the base stations also serve as the end of the communication network 6 and have the role of relaying communications between the navigation device 1, which is within the range (cell) of the base station's radio waves, and the server device 4.

[0023] Next, we will explain the configuration of the server device 4 in the driver assistance system 2 in more detail using Figure 2. Let me explain in detail. As shown in Figure 2, the server device 4 includes a server control unit 11, a server-side map DB 12 connected to the server control unit 11 as an information recording means, a high-precision map DB 13, a facility DB 14, an obstacle information DB 15, and a server-side communication device 20.

[0024] The server control unit 11 is a control unit (MCU, MPU, etc.) that controls the entire server device 4, and is equipped with a CPU 21 as an arithmetic unit and control device, RAM 22 used as working memory when the CPU 21 performs various arithmetic processing, ROM 23 on which control programs are stored, and flash memory 24 for storing programs read from ROM 23, among other internal storage devices. The server control unit 11, together with the ECU of the navigation device 1 described later, has various means as processing algorithms.

[0025] On the other hand, the server-side map DB12 is a storage means that stores server-side map information, which is the latest version of map information registered based on external input data and input operations. Here, server-side map information consists of various information necessary for route searching, route guidance, and map display, including road networks. For example, it consists of network data including nodes and links that show the road network, link data related to roads (links), node data related to node points, intersection data related to each intersection, location data related to locations such as facilities, map display data for displaying maps, search data for searching for routes, search data for searching for locations, etc.

[0026] Furthermore, the high-precision map DB13 is a storage means that stores high-precision map information 16, which is map information with higher precision than the server-side map information mentioned above. The high-precision map information 16 is map information that stores more detailed information, particularly regarding roads on which vehicles are intended to travel. In this embodiment, for example, regarding roads, it includes information on lane shape (road shape and curvature per lane, lane width, etc.) and road markings (center line of the roadway, lane boundary lines, outer line of the roadway, guidance lines, etc.). In addition, data representing the slope, cant, bank, merging sections, places where the number of lanes decreases, places where the width narrows, level crossings, etc. of the road are recorded, as are data representing the radius of curvature and bending angle for curves, data representing branching points such as intersections and T-junctions, data representing downhill roads, uphill roads, etc. regarding road attributes, and data representing general roads such as national roads, prefectural roads, and narrow streets, as well as toll roads such as expressways, urban expressways, motorways, general toll roads, and toll bridges, etc., regarding road types. Furthermore, the system includes regulatory information that identifies the type and location of road regulated objects such as speed limits, traffic lights, pedestrian crossings, railway crossings, and stop signs. Information regarding lane markings also includes details on how each type of lane marking is positioned on the road. In the following explanation, "curve" refers to a shape where the road bends in an arc with a predetermined curvature (including shapes where the road's curvature changes), as well as shapes where the road bends at a predetermined angle, such as a right angle (e.g., an L-shaped intersection). In addition to the number of lanes on the road, the system also stores information identifying the direction of travel for each lane and the connections between roads (specifically, the correspondence between lanes on the road before an intersection and lanes on the road after an intersection).

[0027] On the other hand, the facility DB14 is a storage means that stores more detailed facility information than the facility information stored in the server-side map information mentioned above. Specifically, the facility information 17 includes information that identifies the location of the entrance and exit of the parking lot (including both parking lots attached to facilities and independent parking lots), information that identifies the arrangement of parking spaces within the parking lot, and information that identifies the lines that demarcate parking spaces and roadways, etc. Regarding roadways, it includes at least information that identifies the shape of the roadway (i.e., the area in the parking lot where vehicles can travel), and if there are any entities (restrictions) that restrict vehicle movement such as speed limits on the roadway, it includes restriction information that identifies the type and location of the restrictions. For facilities other than parking lots, it includes information that identifies the floor map of the facility. The floor map includes, for example, entrances and exits, corridors, stairs, This includes information that identifies the location of elevators and escalators. In the case of a mixed-use commercial facility with multiple tenants, it also includes information that identifies the location of each tenant. Facility information 17 may also be information generated by 3D models of parking lots and other facilities. Furthermore, facility DB 14 also includes connection information 18 that shows the connection relationship between the lanes included in the access road facing the entrance to the parking lot and the entrance to the parking lot, and road surface shape information 19 that identifies the area where vehicles can pass between the access road and the entrance to the parking lot.

[0028] Furthermore, while the high-precision map information 16 is basically map information that covers only roads (links) and their surroundings, it may also include areas other than those surrounding roads. Also, in the example shown in Figure 2, the server-side map information stored in the server-side map DB 12 and the information stored in the high-precision map DB 13 and facility DB 14 are different map information, but the information stored in the high-precision map DB 13 and facility DB 14 may be part of the server-side map information. In addition, the high-precision map DB 13 and facility DB 14 may be combined into a single database.

[0029] Furthermore, the Obstacle Information DB15 is a storage means that cumulatively stores information about obstacles (obstacle information) generated by statistically analyzing probe information collected from each vehicle. Obstacles are objects that hinder the movement of vehicles traveling on roads or within facilities such as parking lots, and include, for example, vehicles parked on the road, signs and fences installed at road construction sites, uneven road surfaces, and structures such as utility poles and blocks. In this embodiment, the probe information collected from the vehicle includes, in particular, (a) the detection results of obstacles using on-board cameras and other sensors installed in the vehicle, and (b) the vehicle's position coordinates and speed. By statistically analyzing this probe information, the server device 4 manages the types and locations of obstacles on roads and within facilities such as parking lots nationwide and stores them in the Obstacle Information DB15. However, information about obstacles may also be obtained from sources other than probe information.

[0030] Figure 3 shows an example of obstacle information stored in the obstacle information DB15. As shown in Figure 3, the obstacle information includes information that identifies the date and time the obstacle was detected, the type of obstacle, and information that identifies the location of the obstacle. Furthermore, the location of the obstacle is identified by the link ID of the link where the obstacle is located, the distance from the starting point of the link, the lane in which the obstacle is located, and the range within the lane where the obstacle is located. For example, in the example shown in Figure 3, it is indicated that a parked vehicle is located at a position 20m from the starting point of link ID "100001", with a total length (in the direction of road travel) of 3.5m, and within a range of 1m from the left edge of the leftmost lane. Also, it is indicated that a parked vehicle is located at a position 30m from the starting point of link ID "100013", with a total length (in the direction of road travel) of 3.5m, and within a range of 0.2m to 2.0m starting from the left edge of the leftmost lane. Furthermore, at a position 50m from the starting point of link ID "100101", the parked vehicle is located within a range of 0.4m to 2.2m, starting from the leftmost edge of the leftmost lane, with a total length (in the direction of road travel) of 3.5m. Note that the "Lane No." is defined as 1, 2, 3, etc., from left to right, for example, multiple lanes included in a link.

[0031] The server device 4 then distributes the obstacle information stored in the obstacle information DB 15 to the navigation device 1 upon request from the navigation device 1. Meanwhile, the navigation device 1, having received the obstacle information, uses the distributed obstacle information to generate various support information related to automated driving assistance, as described later.

[0032] On the other hand, the server-side communication device 20 is a communication device for communicating with the navigation device 1 of each vehicle 5 via the communication network 6. In addition to the navigation device 1, it also receives traffic congestion information, regulation information, traffic accident information, etc. transmitted from the Internet network and traffic information centers, such as VICS (registered trademark: Vehicle Information and Communication System) centers. It is also possible to receive traffic information composed of various pieces of information.

[0033] Next, the schematic configuration of the navigation device 1 installed in the vehicle 5 will be explained using Figure 4. Figure 4 is a block diagram showing the navigation device 1 according to this embodiment.

[0034] As shown in Figure 4, the navigation device 1 according to this embodiment includes a current position detection unit 31 that detects the current position of the vehicle on which the navigation device 1 is installed, a data recording unit 32 on which various data are recorded, a navigation ECU 33 that performs various calculation processing based on the input information, an operation unit 34 that accepts operations from the user, a liquid crystal display 35 that displays information such as a map of the area around the vehicle and the guidance route (planned route of the vehicle) set in the navigation device 1 to the user, a speaker 36 that outputs voice guidance regarding route guidance, a DVD drive 37 that reads a DVD which is a storage medium, and a communication module 38 that communicates with information centers such as probe centers and VICS centers. Furthermore, the navigation device 1 is connected to external cameras 39 and various sensors installed on the vehicle on which the navigation device 1 is installed via an in-vehicle network such as CAN. In addition, it is connected in a bidirectional communication manner to a vehicle control ECU 40 that performs various controls on the vehicle on which the navigation device 1 is installed.

[0035] The following describes each component of the navigation device 1 in order. The current position detection unit 31 consists of a GPS 41, a vehicle speed sensor 42, a steering sensor 43, a gyro sensor 44, etc., and is capable of detecting the current position, direction, vehicle speed, current time, etc. In particular, the vehicle speed sensor 42 is a sensor for detecting the distance traveled and vehicle speed of the vehicle, and generates pulses in accordance with the rotation of the vehicle's drive wheels and outputs the pulse signal to the navigation ECU 33. The navigation ECU 33 then calculates the rotation speed of the drive wheels and the distance traveled by counting the generated pulses. It should be noted that the navigation device 1 does not need to be equipped with all four types of sensors mentioned above, and the navigation device 1 may be configured to be equipped with only one or more of these types of sensors.

[0036] Furthermore, the data recording unit 32 includes a hard disk (not shown) as an external storage device and recording medium, and a recording head (not shown) which is a driver for reading map information DB 45, cache 46, predetermined programs, etc., recorded on the hard disk, and for writing predetermined data to the hard disk. The data recording unit 32 may also have flash memory, a memory card, or an optical disc such as a CD or DVD instead of a hard disk. Also, in this embodiment, as described above, the server device 4 searches for a route to the destination, so the map information DB 45 may be omitted. Even if the map information DB 45 is omitted, it is possible to obtain map information from the server device 4 as needed.

[0037] Here, the map information DB45 is a storage means that stores, for example, link data related to roads (links), node data related to node points, search data used for processing related to route searching and modification, facility data related to facilities, map display data for displaying maps, intersection data related to each intersection, and search data for searching for locations.

[0038] On the other hand, the cache 46 is a storage means that stores high-precision map information 16, facility information 17, connection information 18, off-road shape information 19, and obstacle information previously distributed from the server device 4. The storage period can be set as appropriate; for example, it may be a predetermined period (e.g., one month) from the time it is stored, or it may be until the vehicle's ACC power (accessory power supply) is turned off. Alternatively, after the amount of data stored in the cache 46 reaches its limit, older data may be deleted sequentially. The navigation ECU 33 then uses the high-precision map information 16, facility information 17, connection information 18, off-road shape information 19, and obstacle information stored in the cache 46 to generate various support information related to automated driving assistance. For details... This will be explained later.

[0039] On the other hand, the navigation ECU (Electronic Control Unit) 33 is an electronic control unit that controls the entire navigation device 1, and includes a CPU 51 as an arithmetic unit and control device, a RAM 52 which is used as working memory when the CPU 51 performs various arithmetic processing and stores route data when a route is searched, a ROM 53 which stores control programs as well as the automatic driving support program (see Figure 5) described later, and other internal storage devices such as a flash memory 54 which stores programs read from the ROM 53. The navigation ECU 33 also has various means as processing algorithms. For example, the planned driving route acquisition means acquires the planned driving route that the vehicle will travel. The turning section acquisition means acquires the turning section that the vehicle will travel in while driving according to the planned driving route. The obstacle information acquisition means acquires obstacle information regarding obstacles present on the planned driving route. The direction setting means sets the direction of the vehicle when the vehicle reaches a target point that includes at least one of the start and end points of the turning section, based on the planned driving route. The trajectory generation means generates a recommended trajectory for the vehicle, which avoids obstacles in turning sections, using obstacle information, provided that the vehicle's direction upon reaching the target point is the direction set by the direction setting means. The driving support means provides driving support for the vehicle based on the trajectory generated by the trajectory generation means.

[0040] The control unit 34 is operated when inputting the starting point (departure point) and the ending point (destination point), and has multiple operation switches (not shown), such as various keys and buttons. The navigation ECU 33 controls the system to perform various operations based on the switch signals output when each switch is pressed. The control unit 34 may also have a touch panel located in front of the liquid crystal display 35. It may also have a microphone and a voice recognition device.

[0041] The LCD display 35 also displays map images including roads, traffic information, operation instructions, operation menus, key guidance, guidance information along the guided route (planned driving route), news, weather forecasts, time, emails, TV programs, etc. Alternatively, a HUD or HMD may be used instead of the LCD display 35.

[0042] Furthermore, speaker 36 outputs voice guidance that directs the driver along the guided route (planned route) based on instructions from the navigation ECU 33, as well as traffic information.

[0043] Furthermore, the DVD drive 37 is a drive capable of reading data recorded on recording media such as DVDs and CDs. Based on the read data, it performs functions such as playing music and videos, and updating the map information DB 45. Alternatively, a card slot for reading and writing memory cards may be provided instead of the DVD drive 37.

[0044] Furthermore, the communication module 38 is a communication device for receiving traffic information, probe information, weather information, etc. transmitted from traffic information centers, such as VICS centers and probe centers, and includes, for example, mobile phones and DCMs. It also includes vehicle-to-vehicle communication devices for communication between vehicles and vehicle-to-infrastructure communication devices for communication with roadside devices. It is also used to send and receive route information, high-precision map information 16, facility information 17, connection information 18, off-road shape information 19, obstacle information, etc., searched by the server device 4 to and from the server device 4.

[0045] Furthermore, the external camera 39 is composed of a camera using a solid-state image sensor such as a CCD, and is mounted above the front bumper of the vehicle, with its optical axis oriented at a predetermined angle downward from the horizontal. The external camera 39 captures images of the area in front of the vehicle when the vehicle is traveling in an automated driving section. The navigation ECU 33 also captures the images. By performing image processing on the captured images, the system detects obstacles such as lane markings on the road the vehicle is traveling on and other vehicles in the vicinity, and generates various support information related to automated driving assistance based on the detection results. For example, if an obstacle is detected, a new driving trajectory is generated that avoids or follows the obstacle. Furthermore, if obstacles that hinder vehicle movement, such as parked vehicles on the road, signs and fences installed at road construction sites, uneven road surfaces, utility poles, blocks, and other structures, are detected, information identifying the location and type of the detected obstacle is also transmitted to the server device 4 as probe information. The external camera 39 may be configured to be positioned at the rear or side of the vehicle, in addition to the front. Also, instead of a camera, sensors such as millimeter-wave radar or laser sensors, or vehicle-to-vehicle communication or vehicle-to-infrastructure communication may be used as means of detecting obstacles.

[0046] Furthermore, the vehicle control ECU 40 is an electronic control unit that controls the vehicle equipped with the navigation device 1. The vehicle control ECU 40 is also connected to various drive units of the vehicle, such as the steering, brakes, and accelerator, and in this embodiment, it controls each drive unit to provide automatic driving assistance to the vehicle, especially after automatic driving assistance has been initiated in the vehicle. In addition, if the user overrides the automatic driving assistance, the ECU 40 detects that an override has occurred.

[0047] Here, after the vehicle starts driving, the navigation ECU 33 transmits various support information related to automated driving assistance generated by the navigation device 1 to the vehicle control ECU 40 via CAN. The vehicle control ECU 40 then uses the received support information to perform automated driving assistance after the vehicle starts driving. Examples of support information include the recommended driving trajectory for the vehicle and a speed plan indicating the vehicle speed during driving.

[0048] Next, the automatic driving support program executed by the CPU 51 in the navigation device 1 according to this embodiment having the above configuration will be described with reference to Figure 5. Figure 5 is a flowchart of the automatic driving support program according to this embodiment. Here, the automatic driving support program is executed after the vehicle's ACC power supply (accessory power supply) is turned ON and the vehicle starts driving with automatic driving support, and is a program that performs assisted driving with automatic driving support according to the support information generated by the navigation device 1. Furthermore, the programs shown in the flowcharts in Figures 5, 8, 11, 14, 23, 25, and 33 are stored in the RAM 52 and ROM 53 of the navigation device 1 and are executed by the CPU 51.

[0049] First, in step 1 (hereinafter abbreviated as S) of the autonomous driving support program, the CPU 51 acquires the route that the vehicle is scheduled to travel (hereinafter referred to as the planned route). The vehicle's planned route is, for example, the recommended route to the destination found by the server device 4 when the user sets the destination. If no destination is set, the route taken by following the road from the vehicle's current location may be used as the planned route.

[0050] Furthermore, when searching for a recommended route, the CPU 51 first sends a route search request to the server device 4. The route search request includes a terminal ID that identifies the navigation device 1 that sent the route search request, and information that identifies the starting point (e.g., the vehicle's current location) and the destination. Note that information that identifies the destination is not necessarily required when performing a re-search. Subsequently, the CPU 51 receives the search route information sent from the server device 4 in response to the route search request. The search route information is information that identifies the recommended route (center route) from the starting point to the destination, which the server device 4 has searched using the latest version of map information based on the transmitted route search request (e.g., a list of links included in the recommended route). For example, it may be searched using the well-known Dijkstra's algorithm.

[0051] Furthermore, when searching for the recommended route described above, it is desirable to select a recommended parking spot (parking space) at the destination parking lot and then search for a recommended route to the selected parking spot. In other words, it is desirable that the searched recommended route include not only the route to the parking lot but also the route showing the movement of the car within the parking lot. For example, from among the available parking spaces in the parking lot, a parking space that is easy for the user to park in (for example, a parking space close to the entrance / exit of the parking lot, a parking space where there are no other vehicles parked on either side, etc.) should be determined as a candidate for a recommended parking spot for the user. In addition, when selecting a parking spot, it is desirable to select a parking spot that minimizes the burden on the user by considering not only the movement of the vehicle to the parking spot but also the walking distance after parking and the movement of the car when leaving the parking spot on the way back.

[0052] Furthermore, multiple parking locations may be selected as recommended parking spots for the vehicle. If multiple parking locations are selected as recommended parking spots, the recommended routes to each parking location will be acquired as planned driving routes in S1, meaning that multiple candidate planned driving routes will be acquired. Moreover, even if only one recommended parking location is selected, if multiple recommended routes are possible to that parking location, multiple candidate planned driving routes may be acquired. In addition, if multiple candidate planned driving routes are acquired in S1, the lane movement patterns among the multiple planned driving routes will be compared in S25 described below, and the recommended lane movement pattern will be determined as one, thereby determining the parking location and planned driving route as one.

[0053] Furthermore, the server device 4 refers to connection information 18 that shows the connection relationship between the lanes included in the road facing the entrance / exit of the parking lot where the user will park (hereinafter referred to as the access road) and the entrance / exit of the parking lot. If the possible directions of travel for entering the parking lot from the access road are limited (for example, only left turns are permitted), the server device 4 also considers the direction of entry when searching for the planned driving route. Note that other search methods besides Dijkstra's algorithm may be used for route searching. Also, the search for the planned driving route in S1 may be performed by the navigation device 1 instead of the server device 4.

[0054] Next, in S2, the CPU 51 acquires high-precision map information 16 for the area including the planned route acquired in S1, starting from the vehicle's current position.

[0055] Here, the high-precision map information 16 is divided into rectangular shapes (e.g., 500m x 1km) as shown in Figure 6 and stored in the high-precision map DB 13 of the server device 4. Therefore, for example, if route 61 is acquired as the planned route of the vehicle as shown in Figure 6, the high-precision map information 16 is acquired for areas 62 to 65 that include route 61. However, if the distance to the destination is particularly far, the high-precision map information 16 may be acquired for only the secondary mesh where the vehicle is currently located, or for only the area within a predetermined distance (e.g., within 3km) from the vehicle's current location.

[0056] The high-precision map information 16 includes information such as the lane shape of roads and the markings drawn on the roads (center line of the roadway, lane boundary lines, outer line of the roadway, guidance lines, etc.). Furthermore, it includes regulatory information that identifies the type and location of regulatory objects that restrict (more specifically require stopping or slowing down) vehicle movement, such as speed limits, traffic lights, pedestrian crossings, railway crossings, and stop signs set on roads and roadways. It also includes information about intersections, parking lots, etc. The high-precision map information 16 is basically acquired from the server device 4 in the rectangular area units described above, but if high-precision map information 16 for an area is already stored in the cache 46, it is acquired from the cache 46. The high-precision map information 16 acquired from the server device 4 is temporarily stored in the cache 46.

[0057] In addition, in S2, the CPU 51 also acquires connection information 18 indicating the connection relationship between the lanes included in the access road facing the entrance / exit of the parking lot where the user will park and the entrance / exit of the parking lot, road surface shape information 19 identifying the area where a vehicle can pass between the access road and the entrance / exit of the parking lot where the user will park, and similarly acquires obstacle information regarding obstacles on the planned route (including on the road and within facilities such as the parking lot).

[0058] Subsequently, in S3, the CPU 51 executes the static driving trajectory generation process (Figure 8) described below. Here, the static driving trajectory generation process generates a static driving trajectory, which is the driving trajectory recommended for the vehicle on the roads included in the planned driving route, based on the vehicle's planned driving route and the high-precision map information 16 acquired in S2. In particular, the CPU 51 not only identifies the lane on which the vehicle is recommended to drive, but also generates a static driving trajectory that identifies the specific driving position within the lane on which driving is recommended. Furthermore, for obstacles managed in the obstacle information DB 15, the CPU 51 generates a driving trajectory that avoids the obstacle by acquiring obstacle information from the server device 4. If the distance to the destination is particularly far, it is also possible to generate a static driving trajectory only for the section from the vehicle's current position to a predetermined distance ahead in the direction of travel (for example, within the secondary mesh where the vehicle is currently located). The predetermined distance can be changed as appropriate, but the static driving trajectory is generated for an area that includes at least the area outside the range (detection range) where the road conditions around the vehicle can be detected by the external camera 39 or other sensors.

[0059] Next, in S4, the CPU 51 generates a vehicle speed plan for traveling along the static track generated in S3, based on the high-precision map information 16 acquired in S2. For example, it calculates the recommended vehicle speed for traveling along the static track, taking into account speed limit information and speed change points on the planned route (e.g., intersections, curves, railway crossings, pedestrian crossings, etc.).

[0060] The speed plan generated in S4 is then stored in flash memory 54 or the like as support information for autonomous driving assistance. In addition, a plan of acceleration indicating the acceleration and deceleration of the vehicle necessary to realize the speed plan generated in S4 may also be generated as support information for autonomous driving assistance.

[0061] Next, in S5, the CPU 51 performs image processing on the image captured by the external camera 39 to determine whether there are any factors in the surrounding road conditions, particularly around the vehicle itself, that could affect the vehicle's movement. Here, the "factors that could affect the vehicle's movement" to be determined in S5 are dynamic factors that change in real time, and static factors such as those based on road structure are excluded. For example, this includes other vehicles traveling or parked in front of the vehicle's direction of travel, congested vehicles, pedestrians located in front of the vehicle's direction of travel, and construction zones in front of the vehicle's direction of travel. On the other hand, intersections, curves, railway crossings, merging sections, lane reduction sections, etc., are excluded. Furthermore, even if other vehicles, pedestrians, or construction zones exist, they are excluded from "factors that could affect the vehicle's movement" if there is no risk of them overlapping with the vehicle's future trajectory (for example, if they are located far from the vehicle's future trajectory). Therefore, as described later, when generating a static driving trajectory (S3), obstacles that were targeted for avoidance (obstacles managed in the obstacle information DB15) have already had driving trajectories generated that avoid these obstacles, and since they do not overlap with the current driving trajectory, they are excluded from the "factors that affect the driving of the vehicle." In addition, instead of cameras, sensors such as millimeter-wave radar or laser sensors, or vehicle-to-vehicle communication or vehicle-to-infrastructure communication may be used as means to detect factors that may affect the driving of the vehicle.

[0062] Furthermore, for example, the real-time location of each vehicle traveling on roads nationwide is managed by an external server, and the CPU 51 obtains the location of other vehicles located around its own vehicle from the external server and then... You may also perform the judgment process described in S5.

[0063] If it is determined that there are factors in the vicinity of the vehicle that could affect its operation (S5: YES), the process proceeds to S6. Conversely, if it is determined that there are no factors in the vicinity of the vehicle that could affect its operation (S5: NO), the process proceeds to S9.

[0064] In S6, the CPU 51 generates a new dynamic trajectory to avoid or follow the "factors affecting the vehicle's movement" detected in S5, returning to the static trajectory. The dynamic trajectory is generated for the section containing the "factors affecting the vehicle's movement." The length of the section varies depending on the nature of the factor. For example, if the "factor affecting the vehicle's movement" is another vehicle (forward vehicle) traveling in front of the vehicle, the dynamic trajectory 67 is generated as an avoidance trajectory, which is the trajectory from changing lanes to the right to overtake the forward vehicle 66, and then changing lanes to the left to return to the original lane, as shown in Figure 7. Alternatively, a follow trajectory may be generated as the dynamic trajectory, which is the trajectory of following the forward vehicle 66 at a predetermined distance behind it (or traveling alongside the forward vehicle 66) without overtaking it. Furthermore, multiple candidates may be generated as dynamic trajectories, in which case the candidate with the lowest cost will be selected from among the multiple candidates in S7, described later.

[0065] To explain the calculation method of the dynamic driving trajectory 67 shown in Figure 7 as an example, the CPU 51 first starts turning the steering wheel to move to the right lane and calculates the first trajectory L1 necessary for the steering wheel to return to the straight-ahead position. The first trajectory L1 is calculated based on the vehicle's current speed, and the lateral acceleration (lateral G) that occurs when changing lanes is calculated. The lateral G does not exceed an upper limit (e.g., 0.2G) that does not interfere with the automatic driving assistance and does not cause discomfort to the vehicle's occupants. The rate of change of lateral G per unit time is also limited to the same upper limit (e.g., 0.6m / s²). 3 The system calculates a trajectory that is as smooth as possible and minimizes the distance required for lane changes, using clothoid curves and circular arcs, provided that the value does not exceed [a certain value]. It also requires that an appropriate following distance N or greater be maintained between the vehicle 66 in front. Next, a second trajectory L2 is calculated, which involves driving in the right lane at the speed limit to overtake vehicle 66 and maintaining an appropriate following distance N or more between the two vehicles. The second trajectory L2 is basically a straight line, and its length is calculated based on the speed of vehicle 66 and the road's speed limit. Next, the system calculates a third trajectory L3, which is necessary to initiate the steering turn to return to the left lane and for the steering wheel to return to the straight-ahead position. The third trajectory L3 is calculated based on the vehicle's current speed, determining the lateral acceleration (lateral G) generated during the lane change. The system ensures that the lateral G does not exceed a certain upper limit (e.g., 0.2G) that does not interfere with the automated driving assistance system or cause discomfort to the vehicle's occupants. Similarly, the rate of change of lateral G per unit time is also limited to a certain upper limit (e.g., 0.6 m / s²). 3 The system calculates a trajectory that is as smooth as possible and minimizes the distance required for lane changes, using clothoid curves and circular arcs, provided that the value does not exceed [a certain value]. It also requires that an appropriate following distance N or greater be maintained between the vehicle 66 in front. Furthermore, since the dynamic driving trajectory is generated based on the road conditions around the vehicle acquired by the external camera 39 and other sensors, the area in which the dynamic driving trajectory is generated is at least within the range (detection range) in which the road conditions around the vehicle can be detected by the external camera 39 and other sensors.

[0066] Next, in S7, the CPU 51 reflects the dynamic trajectory newly generated in S6 into the static trajectory generated in S3. Specifically, it calculates the cost of both the static trajectory and the dynamic trajectory (there may be multiple candidates for the dynamic trajectory) from the vehicle's current position to the end of the section containing "factors that affect the vehicle's movement," and then determines the trajectory that minimizes this cost. A track is selected. As a result, a portion of the static track will be replaced with a dynamic track as needed. However, in some situations, the dynamic track may not be replaced; that is, even if the dynamic track is reflected, it may not change from the static track generated in S3. Furthermore, if the dynamic track and the static track are the same track, the static track generated in S3 may not change even if the replacement is performed.

[0067] Next, in S8, the CPU 51 modifies the vehicle's speed plan generated in S4 based on the content of the dynamic trajectory, after the dynamic trajectory has been reflected in S7. If the static trajectory generated in S3 does not change as a result of the reflection of the dynamic trajectory, the process in S8 may be omitted.

[0068] Next, in S9, the CPU 51 calculates the control amounts necessary for the vehicle to travel at a speed according to the speed plan generated in S4 (or the modified plan if the speed plan was modified in S8) based on the static driving trajectory generated in S3 (or the trajectory after the dynamic driving trajectory has been reflected in S7). Specifically, the control amounts for the accelerator, brake, gear, and steering are calculated, respectively. Note that the processing in S9 and S10 may be performed by the vehicle control ECU 40, which controls the vehicle, rather than the navigation device 1.

[0069] Subsequently, in S10, the CPU 51 reflects the control values ​​calculated in S9. Specifically, it transmits the calculated control values ​​to the vehicle control ECU 40 via CAN. The vehicle control ECU 40 performs vehicle control of the accelerator, brakes, gears, and steering based on the received control values. As a result, it becomes possible to provide driving support control that drives the vehicle at a speed according to the speed plan generated in S4 (or the modified plan if the speed plan was modified in S8) along the static driving trajectory generated in S3 (or the trajectory after the dynamic driving trajectory has been reflected in S7).

[0070] Next, in S11, the CPU 51 determines whether the vehicle has traveled a certain distance since the static track was generated in S3. For example, the certain distance is 1 km.

[0071] Then, if it is determined that the vehicle has traveled a certain distance since the static trajectory was generated in S3 (S11: YES), the process returns to S2. Subsequently, the static trajectory is generated again for a section within a predetermined distance from the vehicle's current position along the planned route (S2-S4). In this embodiment, the static trajectory is repeatedly generated for a section within a predetermined distance from the vehicle's current position along the planned route each time the vehicle travels a certain distance (e.g., 1 km). However, if the distance to the destination is short, the static trajectory to the destination may be generated all at once at the start of travel.

[0072] On the other hand, if it is determined that the vehicle has not traveled a certain distance since the static driving trajectory was generated in S3 (S11: NO), it is determined whether or not to terminate the assisted driving by the automated driving support system (S12). In addition to arriving at the destination, the assisted driving by the automated driving support system may be terminated if the user intentionally disables (overrides) the assisted driving by operating the control panel on the vehicle, or by operating the steering wheel or brakes.

[0073] If it is determined that the automated driving assistance should be terminated (S12: YES), the automated driving assistance program is terminated. Conversely, if it is determined that the automated driving assistance should be continued (S12: NO), the process returns to S5.

[0074] Next, the subprocessing of the static track generation process executed in S3 will be explained with reference to Figure 8. Figure 8 is a flowchart of the subprocessing program for the static track generation process. ru.

[0075] First, in S21, the CPU 51 acquires the current position of the vehicle detected by the current position detection unit 31. It is desirable to determine the vehicle's current position in detail using, for example, high-precision GPS information or high-precision location technology. Here, high-precision location technology is a technology that detects white lines and road paint information captured from a camera installed on the vehicle using image recognition, and further compares the detected white lines and road paint information with, for example, high-precision map information 16, thereby enabling the detection of the driving lane and the vehicle's position with high precision. Furthermore, if the vehicle is traveling on a road with multiple lanes, the lane the vehicle is traveling in is also identified. In addition, if the vehicle is located in a parking lot, the specific location within the parking lot (for example, the parking space in which the vehicle is located) and the vehicle's orientation (for example, the direction of travel of the vehicle, and, if located in a parking space, the orientation in which it is parked relative to the parking space) are also identified.

[0076] Next, in S22, the CPU 51 acquires information such as lane shape, lane markings, and intersection information, particularly for the section in front of the vehicle's direction of travel where a static driving trajectory is to be generated (for example, the planned driving route within a predetermined distance from the vehicle's current position), based on the high-precision map information 16 acquired in S2. It also acquires regulatory information that identifies the type and location of roads and roadways that restrict (more specifically require stopping or slowing down) vehicle movement (regulatory objects) such as speed limits, traffic lights, pedestrian crossings, railway crossings, and stop signs. Furthermore, if the section in which the static driving trajectory is to be generated includes a parking lot, the CPU 51 acquires information that identifies the location of the parking lot entrance and exit, information that identifies the arrangement of parking spaces within the parking lot, and information about lane markings that demarcate parking spaces and roadways. Regarding roadways, the CPU 51 also acquires information that identifies the shape of the roadway (i.e., the area in the parking lot where a vehicle can travel). Furthermore, the lane shape and marking information acquired in S22 includes information that identifies how the lanes that a vehicle can select to travel in are arranged relative to the road, and also includes information that identifies the number of lanes, the type and arrangement of markings that separate the lanes, the curvature of the road (lanes), the lane width, where and how the number of lanes increases or decreases if there is an increase or decrease, the traffic divisions for each lane in the direction of travel, and the connections between roads (specifically, the correspondence between the lanes included in the road before passing through an intersection and the lanes included in the road after passing through an intersection).

[0077] Next, in S23, the CPU 51 constructs a lane network for the section in front of the vehicle's direction of travel where a static driving trajectory is generated, based on the lane shape and lane marking information acquired in S22. Here, the lane network is a network that shows the lane changes that the vehicle can choose.

[0078] Here, as an example of constructing a lane network in S23, we will explain using the example of a vehicle traveling along the planned route shown in Figure 9. The planned route shown in Figure 9 is a route in which the vehicle travels straight from its current position, turns right at the next intersection 71, turns right again at the next intersection 72, and turns left at the next intersection 73. In the planned route shown in Figure 9, for example, when turning right at intersection 71, it is possible to enter either the right lane or the left lane. However, since it is necessary to turn right at the next intersection 72, it is necessary to move to the rightmost lane when entering intersection 72. Similarly, when turning right at intersection 72, it is possible to enter either the right lane or the left lane. However, since it is necessary to turn left at the next intersection 73, it is necessary to move to the leftmost lane when entering intersection 73. Figure 10 shows a lane network constructed for sections where such lane changes are possible.

[0079] As shown in Figure 10, the lane network divides the section that generates the static driving trajectory in front of the vehicle's direction of travel into multiple sections (groups). Specifically, the boundaries are defined by the entry point of an intersection, the exit point of an intersection, and the points where lanes increase or decrease. The boundaries of each divided section are then... Node points (hereinafter referred to as lane nodes) 75 are set for each lane located at the boundary. Furthermore, links (hereinafter referred to as lane links) 76 are set to connect the lane nodes 75. In the case where the lane links 76 do not cross lanes, they are basically set to the center of the lane.

[0080] Furthermore, the lane network, particularly through the connection of lane nodes and lane links at intersections, includes information that identifies the correspondence between lanes included in the road before passing through an intersection and lanes included in the road after passing through an intersection, that is, information that identifies the lanes that can be moved to after passing through an intersection in relation to the lanes before passing through an intersection. Specifically, it indicates that vehicles can move between lanes corresponding to lane nodes connected by lane links, among the lane nodes set on the road before passing through an intersection and the lane nodes set on the road after passing through an intersection. In order to generate such a lane network, the high-precision map information 16 stores lane flags that indicate the correspondence between lanes for each combination of roads entering and exiting an intersection for each road connected to an intersection. When the CPU 51 constructs the lane network in S23, it refers to the lane flags to form the connection between lane nodes and lane links at the intersection.

[0081] Although Figure 10 shows an example of a lane network constructed for roads, a similar network (hereinafter referred to as the parking lot network) can be constructed for parking lots if the section for generating static driving trajectories includes a parking lot. The parking lot network consists of parking lot nodes and parking lot links. Parking lot nodes are set at the entrances and exits of the parking lot, intersections where vehicle-accessible paths intersect, corners of vehicle-accessible paths (i.e., connection points between paths), and the ends of paths. Parking lot links, on the other hand, are set for vehicle-accessible paths between parking lot nodes.

[0082] Furthermore, if multiple candidate routes are obtained in S1, the lane network and parking lot network described above will be constructed for each of the multiple routes.

[0083] Next, in S24, the CPU 51 sets a starting lane (departure node) at the lane node located at the starting point of the lane network constructed in S23 (including the parking lot network if the section for generating the static driving trajectory includes a parking lot, the same applies hereinafter), and sets a target lane (destination node) at the lane node located at the end point of the lane network, which is the target lane to which the vehicle will move. If the starting point of the lane network is a road with multiple lanes in one direction, the lane node corresponding to the lane in which the vehicle is currently located becomes the starting lane. On the other hand, if the end point of the lane network is a road with multiple lanes in one direction, the lane node corresponding to the leftmost lane (in the case of left-hand traffic) becomes the target lane. Furthermore, if the starting or ending point of the lane network is within a parking lot, the starting lane is set in the parking space or passage where the vehicle is currently located within the parking lot network, and the target lane is set in the parking space where the vehicle will park or in the passage leading to the parking space.

[0084] Subsequently, in S25, the CPU 51 refers to the lane network constructed in S23 and derives the route with the smallest lane cost among the routes that continuously connect the starting lane to the target lane (hereinafter referred to as the recommended route). For example, Dijkstra's algorithm is used to search for a route from the target lane side. However, other search methods besides Dijkstra's algorithm may be used as long as a route that continuously connects the starting lane to the target lane can be found. The derived recommended route becomes the recommended lane movement pattern for the vehicle when the vehicle moves (information that identifies the lane that is recommended to drive in and the recommended position for lane changes).

[0085] Furthermore, the lane cost used to search for the above route is assigned for every 76 lane links. The lane cost assigned to each lane link 76 is based on the length of each lane link 76 or the time required for movement. In particular, in this embodiment, the length of the lane link (in meters) is used as the base value for the lane cost. In addition, for lane links involving lane changes, a lane change cost (e.g., 50) is added to the above base value. The value of the lane change cost may be changed depending on the number of lane changes and the location of the lane changes. For example, the value of the added lane change cost can be increased when lane changes occur near an intersection or when lane changes involving two lanes occur.

[0086] Furthermore, if multiple candidate routes are obtained in S1, the recommended route with the lowest lane cost is derived from among the multiple routes. The route to be driven is then determined to be the same as the recommended route derived.

[0087] Next, in S26, the CPU 51 acquires obstacle information from the server device 4 regarding obstacles along the planned route the vehicle will travel. Obstacles are objects that hinder the movement of vehicles traveling on roads or within facilities such as parking lots. Examples include vehicles parked on the road, signs and fences installed at road construction sites, uneven road surfaces, and structures such as utility poles and blocks. Specifically, the obstacle information includes information identifying the date and time the obstacle was detected, the type of obstacle, and the location of the obstacle. In particular, the location of the obstacle is specified by the link ID of the link where the obstacle is located, the distance from the starting point of the link, the lane in which the obstacle is located, and the range within the lane where the obstacle is located. This obstacle information is managed in advance by the server device 4 based on probe information collected from each vehicle traveling throughout the country and stored in the obstacle information DB 15 of the server device 4 (Figure 3). Therefore, in S26, it becomes possible to acquire information about obstacles that are outside the range (detection range) in which the vehicle's external camera 39 and other sensors can detect road conditions around the vehicle.

[0088] On the other hand, in S26, the CPU 51 may also acquire information about obstacles within the detection range identified by detecting road conditions around the vehicle using the vehicle's external camera 39 and other sensors (i.e., information about obstacles detected by the vehicle itself).

[0089] Next, in S27, the CPU 51 performs the turning section trajectory generation process (Figure 11), which will be described later. The turning section trajectory calculation process is a process that generates a recommended trajectory when traveling along the recommended route derived in S25, targeting turning sections in particular, which are part of the planned travel route for which a static trajectory is to be generated in front of the vehicle in the direction of travel, and which involve the vehicle turning when traveling along the planned travel route. Here, turning sections include, for example, sections where the road curves in an arc shape with a predetermined curvature (including shapes where the curvature of the road changes), as well as sections where the road bends at a predetermined angle such as a right angle, and sections of intersections (junctions) where the vehicle turns left or right. Furthermore, it includes not only sections on public roads, but also sections where the vehicle turns when traveling within facilities such as parking lots, sections where the vehicle turns to enter or exit a parking space, or sections where the vehicle turns to enter or exit a facility from a public road. However, in this embodiment, lane changes for the purpose of changing driving lanes are excluded from the above-mentioned turns, and the driving trajectory for the section in which a lane change is performed will be generated in S28 as described below. Furthermore, if the planned driving route includes multiple turning sections, a recommended driving trajectory will be generated for each of the multiple turning sections. In addition, if there is an obstacle identified by the obstacle information acquired in S26 within the turning section, a driving trajectory will be generated that avoids that obstacle.

[0090] Subsequently, in S28, the CPU 51 generates a recommended driving trajectory for driving along the recommended route derived in S25, excluding the turning section. For example, lane changes Regarding the driving trajectory in the associated section, the lane change locations are set so that lane changes are not continuous as much as possible and are performed at locations far from intersections. Furthermore, when generating the driving trajectory when changing lanes, the lateral acceleration (lateral G) generated in the vehicle is calculated, and it is ensured that the lateral G does not exceed an upper limit (e.g., 0.2G) that does not interfere with the automated driving assistance and does not cause discomfort to the vehicle's occupants. The rate of change of lateral G per unit time is also set to the same upper limit (e.g., 0.6m / s²). 3 The process calculates a trajectory that connects the points as smoothly as possible using a clothoid curve, provided that it does not exceed the specified limit. By performing the above process, a recommended driving trajectory is generated for the roads included in the planned route. In addition, for sections that are neither turning sections nor sections where lane changes are made, the recommended driving trajectory for the vehicle is one that passes through the center of the lane. Furthermore, if there is an obstacle identified by the obstacle information obtained in S26, especially outside of a turning section, a driving trajectory is generated that avoids that obstacle.

[0091] In S29, the CPU 51 combines the driving trajectories calculated in S27 and S28 to generate a static driving trajectory, which is the driving trajectory recommended for the vehicle on the roads included in the planned driving route. The static driving trajectory generated in S29 is stored in the flash memory 54 or the like as support information used for automated driving assistance. The process then proceeds to S4, where various driving assistance functions are performed based on the generated static driving trajectory.

[0092] Next, the subprocessing for calculating the travel trajectory of the turning section, which is performed in S27, will be explained with reference to Figure 11. Figure 11 is a flowchart of the subprocessing program for calculating the travel trajectory of the turning section. In particular, the following embodiment will be explained using an example of generating a static travel trajectory for a turning section in which a vehicle travels on a curved road (including not only cases where the road bends in an arc shape, but also cases where it bends at a predetermined angle such as a right angle).

[0093] First, in S31, the CPU 51 acquires information to identify the driving area on which the vehicle travels, based on the high-precision map information 16 acquired in S2, for the section that generates a static driving trajectory in front of the vehicle in the direction of travel. Specifically, information is acquired to identify the positions of the left and right lane markings (or the edges of the road for single-lane roads or roads without lane markings) and the curvature of the road on which the vehicle travels when traveling according to the lane movement pattern selected in S25.

[0094] Next, in S32, the CPU 51 calculates the centerline of the lane (driving area) in which the vehicle travels, based on the driving area information and road curvature acquired in S31, for the section in front of the vehicle in the direction of travel where a static driving trajectory is generated. For roads without lane divisions, the centerline of the road is used. For example, it is possible to calculate the centerline at the center of the driving area from the positions of the left and right lane lines or the edges of the road. Alternatively, it is possible to calculate the centerline from the curvature of the road. However, instead of calculating the centerline from the lane lines or road curvature, it is also possible to calculate it in advance for each lane and store it in the high-precision map DB 13.

[0095] Next, in S33, the CPU 51 calculates a moving average line for the lane (driving area) in which the vehicle travels, based on the center line calculated in S32, for the section in front of the vehicle in the direction of travel where a static driving trajectory is generated. For roads without lane divisions, the moving average line for the road is used. The moving average line is a line connecting the average points of a predetermined number of consecutive coordinate points arranged along the center line of the lane. More specifically, for each coordinate point set at predetermined intervals along the center line, the average point (the point where the latitude and longitude are averaged) of five coordinate points including the two coordinate points before and after it is calculated, and the line connecting these average points is used as the moving average line. However, it is also possible to calculate the moving average line for each lane in advance and store it in the high-precision map DB 13, rather than calculating it from the center line.

[0096] Furthermore, in S34, the CPU 51 compares the center line calculated in S32 with the moving average line calculated in S33, and calculates the range in which the center line and the moving average line do not coincide. The area where the curve exists is detected. Here, Figure 12 shows an example of the center line 81 and moving average line 82 calculated in S31 and S32. As mentioned above, the moving average line 82 is calculated by taking five coordinate points, including the two coordinate points before and after each coordinate point set at predetermined intervals along the center line 81, and averaging the latitude and longitude of those points, and then drawing a line connecting these average points. Therefore, in sections where the center line 81 is arranged in a straight line, the center line 81 and the moving average line 82 coincide, but as shown in Figure 12, there are areas where the center line 81 and the moving average line 82 do not coincide, such as in places where the road curves in an arc or bends at a predetermined angle. Therefore, in S34, the area where the center line 81 and the moving average line 82 do not coincide is detected as the area where the curve exists.

[0097] In addition, in S34, the CPU 51 detects curves in the section that generates the static driving trajectory ahead of the vehicle's direction of travel by comparing the center line 81 and the moving average line 82. However, it is also possible to detect curves based on map information. In that case, the map information should include information that identifies the location of the curve in advance (for example, information that identifies the link corresponding to the curve, or the coordinates of the start and end points of the curve). Alternatively, the range in which the curvature of the road exceeds a threshold can be identified as the range in which curves exist.

[0098] Next, in S35, the CPU 51 determines whether or not there is at least one curve in the section where the static driving trajectory ahead of the vehicle's direction of travel is generated, based on the detection results from S34.

[0099] Then, if it is determined that there is at least one curve in the section for generating the static track ahead of the vehicle's direction of travel (S35: YES), the process proceeds to S36. On the other hand, if it is determined that there are no curves in the section for generating the static track ahead of the vehicle's direction of travel (S35: NO), the process proceeds to S28, where a recommended track is generated for driving along the recommended route derived in S25.

[0100] In S36, the CPU 51 acquires the turning section (more specifically, the start and end points of the turning section) that includes the curve detected as described above. The positions of the start and end points of the turning section may be appropriately changed depending on the lane movement pattern selected in S25, or they may be set under fixed conditions regardless of the lane movement pattern. For example, the starting point of the turning section can be set to a predetermined distance (e.g., 20m) before the start point of the section where the center line 81 and the moving average line 82 no longer coincide, and the ending point of the turning section can be set to a point that is a predetermined distance in the direction of travel from the end point of the section where the center line 81 and the moving average line 82 no longer coincide. Also, if the vehicle's current position is before the curve, the vehicle's current position may become the starting point of the turning section. Furthermore, the map information may be pre-recorded to include information that identifies the turning section along with the curve (e.g., information that identifies the links included in the turning section and the coordinates of the start and end points of the turning section), and the turning section may be set based on the map information.

[0101] From S37 onwards, the following process is used to generate a recommended trajectory for driving through the turning section, targeting the curves detected as described above. If multiple curves are detected, the following process is executed for each turning section corresponding to all detected curves to generate a trajectory.

[0102] First, in S37, the CPU 51 performs the reference trajectory generation process (Figure 14) described later. The reference trajectory generation process targets a turning section and generates a recommended trajectory for driving through the turning section. In particular, the reference trajectory generation process generates a recommended trajectory for driving through the turning section without considering the obstacles, even if there are obstacles identified by the obstacle information acquired in S26 within the turning section. Hereinafter, the trajectory generated in S37 without considering obstacles will be referred to as the reference trajectory.

[0103] Subsequently, in S38, the CPU 51 determines whether the reference driving trajectory generated in S37 overlaps with an obstacle identified by the obstacle information acquired in S26. Here, as shown in Figure 3, the obstacle information identifies the link ID of the link where the obstacle is located, the distance from the starting point of the link, the lane where the obstacle is located, and the area (occupied area) within the lane where the obstacle is located. Based on this obstacle information, it is possible to determine whether the reference driving trajectory and the obstacle overlap. Furthermore, in S38, "the reference trajectory and the obstacle overlap" means not only when the area 78 where the obstacle is located and the reference trajectory 79 overlap, as shown in the left diagram of Figure 13, but also when the vehicle overlaps with the area 78 where the obstacle is located when the vehicle travels along the reference trajectory 79, that is, when the distance X between the area 78 where the obstacle is located and the reference trajectory 79 is less than a predetermined distance (for example, 1 / 2 of the vehicle width + α), as shown in the right diagram of Figure 13.

[0104] Then, if it is determined that the reference driving trajectory generated in S37 does not overlap with an obstacle identified by the obstacle information acquired in S26 (S38: NO), the reference driving trajectory generated in S37 is selected as the recommended driving trajectory when driving through the turning section (S39). In addition, if there are no obstacles identified by the obstacle information acquired in S26 within the turning section, it is determined that the reference driving trajectory does not overlap with an obstacle. Subsequently, the process moves to S28, where a recommended driving trajectory is generated for driving along the recommended route derived in S25 for sections other than the turning section. Finally, by combining the generated driving trajectories, a static driving trajectory is generated, which is the driving trajectory recommended for the vehicle to drive on the roads included in the planned driving route (S29). Furthermore, the generated static driving trajectory is stored in the flash memory 54 or the like as support information used for automated driving assistance.

[0105] On the other hand, if it is determined that the reference trajectory generated in S37 overlaps with an obstacle identified by the obstacle information acquired in S26 (S38: YES), it is considered that the reference trajectory cannot avoid the obstacle in the turning section, and the process proceeds to S40 in order to generate a new trajectory to avoid the obstacle.

[0106] In S40, the CPU 51 performs the first avoidance trajectory generation process (Figure 23), which will be described later. The first avoidance trajectory generation process generates a recommended trajectory for driving through a turning section, taking obstacles into consideration. Hereinafter, the trajectory generated in S40, taking obstacles into consideration, will be referred to as the first avoidance trajectory.

[0107] Subsequently, in S41, the CPU 51 determines whether it was able to generate at least one first avoidance trajectory that does not overlap with the obstacles identified by the obstacle information acquired in S26 during the first avoidance trajectory generation process in S40. In S41, "the first avoidance trajectory and the obstacle overlap" means not only when the area where the obstacle is located overlaps with the first avoidance trajectory, as in S38, but also when the area where the obstacle is located overlaps with the vehicle when the vehicle travels along the first avoidance trajectory, i.e., when the distance X between the area where the obstacle is located and the first avoidance trajectory is less than a predetermined distance (for example, 1 / 2 of the vehicle width + α).

[0108] Then, in the first avoidance trajectory generation process of S40, if it is determined that at least one first avoidance trajectory that does not overlap with the obstacles identified by the obstacle information acquired in S26 has been generated (S41: YES), then the trajectory with the lowest cost indicating suitability as a trajectory (highest suitability) among the first avoidance trajectories generated in S40 is selected as the recommended trajectory when traveling through the turning section (S42). Details of cost calculation will be described later. After that, the process proceeds to S28, and the turning section For sections other than those specified, recommended driving trajectories are generated when driving along the recommended route derived in S25, and finally, by combining each of the generated driving trajectories, a static driving trajectory is generated, which is the driving trajectory recommended for the vehicle to drive on the roads included in the planned driving route (S29). Furthermore, the generated static driving trajectory is stored in the flash memory 54 or the like as support information used for automated driving assistance.

[0109] On the other hand, if, in the first avoidance trajectory generation process of S40, it is determined that a first avoidance trajectory that does not overlap with the obstacle identified by the obstacle information acquired in S26 could not be generated (S41: NO), it is assumed that the first avoidance trajectory cannot avoid the obstacle in the turning section, and the process proceeds to S43 in order to generate a new trajectory to avoid the obstacle.

[0110] In S43, the CPU 51 determines whether the obstacles in the turning section identified by the obstacle information acquired in S26 overlap with the centerline of the lane (driving area) in which the vehicle is traveling, as calculated in S32. As shown in Figure 3, the obstacle information identifies the link ID of the link where the obstacle is located, the distance from the starting point of the link, the lane in which the obstacle is located, and the area (occupied area) within the lane where the obstacle is located. Based on this obstacle information, it is possible to determine whether the centerline and the obstacle overlap.

[0111] If it is determined that an obstacle in the turning section overlaps with the center line of the lane (driving area) in which the vehicle is traveling (S43: YES), the process proceeds to S44. Conversely, if it is determined that an obstacle in the turning section does not overlap with the center line of the lane (driving area) in which the vehicle is traveling (S43: NO), the process proceeds to S45.

[0112] In S44, the CPU 51 performs the second avoidance trajectory generation process (Figure 25), which will be described later. Meanwhile, in S45, the CPU 51 performs the third avoidance trajectory generation process (Figure 33), which will be described later. The second and third avoidance trajectory generation processes, like the first avoidance trajectory generation process in S40, are processes that generate a recommended trajectory when driving through a turning section, taking obstacles into consideration. However, the second and third avoidance trajectory generation processes differ in that the guide lines used as the basis for calculating the trajectory are set so as not to overlap with obstacles, and the trajectory that avoids obstacles is calculated using the guide lines. Furthermore, the second avoidance trajectory generation process sets the guide lines based on the center line of the lane the vehicle is traveling in, while the third avoidance trajectory generation process sets the guide lines based on the reference trajectory calculated in S37. Hereinafter, the trajectory that takes into account the obstacles generated in S44 will be referred to as the second avoidance trajectory, and the trajectory that takes into account the obstacles generated in S45 will be referred to as the third avoidance trajectory.

[0113] Subsequently, from the second avoidance driving trajectory generated in S44 or the third avoidance driving trajectory generated in S45, the driving trajectory with the lowest cost indicating suitability as a driving trajectory (highest suitability) is selected as the recommended driving trajectory when driving through the turning section (S42). Details of cost calculation will be described later. Then, the process moves to S28, where recommended driving trajectories are generated for sections other than the turning section, following the recommended route derived in S25. Finally, by combining the generated driving trajectories, a static driving trajectory, which is the driving trajectory recommended for the vehicle to drive on the roads included in the planned driving route, is generated (S29). Furthermore, the generated static driving trajectory is stored in flash memory 54 or the like as support information used for automated driving assistance.

[0114] Next, the subprocessing of the reference track generation process performed in S37 will be explained with reference to Figure 14. Figure 14 is a flowchart of the subprocessing program for the reference track generation process.

[0115] First, in S51, the CPU 51 sets the recommended vehicle orientation when the vehicle is located at the starting point (target point) of the turning section and the recommended vehicle orientation when the vehicle is located at the ending point (target point) of the turning section. The vehicle orientation includes both the orientation (angle) of the vehicle body and the direction of travel (tire direction, steering angle). However, it is also acceptable to set only one of them. Here, as shown in Figure 15, the recommended vehicle orientation when the vehicle is located at the starting point 83 of the turning section is basically set so that the orientation (angle) of the vehicle body is in the same direction as the direction of travel on the road at the starting point 83 of the turning section (parallel to the road), and the direction of travel of the vehicle is set to the straight-ahead direction (steering angle of 0° (neutral state)). Similarly, when the vehicle is located at the end point 84 of the turning section, the recommended vehicle orientation is basically set so that the vehicle's body orientation (angle) is in the same direction as the road's direction of travel at the end point 84 of the turning section (parallel to the road), and the vehicle's direction of travel is set to a straight line (steering angle of 0° (neutral state)). However, in cases where lane changes are required before or after the turning section, or when other turning sections are adjacent (for example, an S-curve), the above does not apply, and the vehicle's body orientation (angle) may be set to be inclined relative to the road's direction of travel, and the vehicle's direction of travel (tire orientation, steering angle) may also be set to a direction that turns to the right or left. In other words, the vehicle orientation set in S51 does not need to be fixed, and it is desirable to set the recommended vehicle orientation when the vehicle is located at the start of the turning section and the recommended vehicle orientation when the vehicle is located at the end of the turning section, taking into account the lane movement pattern selected in S25.

[0116] Next, in S52, the CPU 51 obtains a start vector that specifies the position and direction of the vehicle at the start of the turning section, and an end vector that specifies the position and direction of the vehicle at the end of the turning section, based on the positions of the start and end of the turning section obtained in S36, and the vehicle direction recommended when the vehicle is located at the start of the turning section and the vehicle direction recommended when the vehicle is located at the end of the turning section, as set in S51.

[0117] Here, the positions of the start and end vectors along the road's direction of travel (forward and backward positions) correspond to the start and end points of the aforementioned turning section. On the other hand, the position of the start and end vectors in the road width direction should basically be the center of the lane in which the vehicle is traveling (or the center of the road in the case of a single-lane road or a road without lane divisions). However, this does not apply when lane changes are required before or after a turning section, or when other turning sections are adjacent (for example, an S-curve), in which case the position of the start and end vectors in the road width direction may be set to the left or right of the center of the lane. Furthermore, the directions of the start vector and end vector are set to correspond to the vehicle's orientation as set in S51.

[0118] Figure 16 shows an example of a start vector 83 and an end vector 84 set for a turning section that includes a right-angle bend. In the example shown in Figure 16, the start vector 83 is set at the center of the lane a predetermined distance before the start of the section where the center line 81 and the moving average line 82 no longer coincide, and the end vector 84 is set at the center of the lane at a point a predetermined distance in the direction of travel from the end of the section where the center line 81 and the moving average line 82 no longer coincide. The direction of both the start vector 83 and the end vector 84 is parallel to the direction of travel (road length direction) of the road.

[0119] Subsequently, in S53, the CPU 51 sets a clipping point (passing point) 85 between the moving average line calculated in S33 and the inner boundary line of the curve. Here, the clipping point 85 can be appropriately set between each coordinate point arranged along the center line 81 and the inner boundary line of the curve, or more appropriately between the moving average line and the inner boundary line of the curve. For example, as shown in Figure 16, the nearest point of tangency of the inner boundary line 86 of the curve to the moving average line 82 is set as the clipping point 85. Note that, as shown in Figure 12, the moving average line is basically moving from the center line 81. Since the moving average line 82 is closer to the inner boundary line of the curve, if a clipping point 85 is set between the moving average line 82 and the inner boundary line of the curve, that clipping point 85 will be located between each coordinate point arranged along the center line 81 and the inner boundary line of the curve. However, the example shown in Figure 16 assumes the vehicle width is 0, and if the vehicle width is taken into consideration, the clipping point should be located half the vehicle width towards the center line from the nearest point of contact of the inner boundary line 86 of the curve to the moving average line 82, or half the vehicle width + α considering errors, etc. For example, it is desirable to set clipping point 85 at a position 30 cm closer to the center line.

[0120] Next, in S54, the CPU 51 generates a new candidate start vector at the starting point of the turning section for which the driving trajectory is to be generated, in addition to the start vector obtained in S52. Furthermore, it generates a new candidate end vector at the end point of the turning section, in addition to the end vector obtained in S52. For example, in the example shown in Figure 17, a new start vector 91 is generated at a point moved a predetermined distance (e.g., 1 / 4 or 1 / 6 of the lane width) outward from the initial start vector 83, and a new start vector 92 is generated at a point moved a predetermined distance (e.g., 1 / 4 or 1 / 6 of the lane width) further outward from the curve. Similarly, a new end vector 93 is generated at a point moved a predetermined distance (e.g., 1 / 4 or 1 / 6 of the lane width) outward from the initial end vector 84, and a new end vector 94 is generated at a point moved a predetermined distance (e.g., 1 / 4 or 1 / 6 of the lane width) further outward from the curve. In the example shown in Figure 17, two new start vectors and two new end vector candidates are generated, but it is also possible to generate only one or three or more. It is also possible to generate them in the direction of the curve's inward direction. Generating more new start and end vector candidates increases the likelihood of generating a more appropriate trajectory, but on the other hand, the processing load for calculating the trajectory increases because there are more trajectory candidates.

[0121] The subsequent processes S55 to S61 are executed for each combination of start vector and end vector obtained in S52 and newly generated in S54. For example, in the example shown in Figure 17, there are 3 start vectors and 3 end vectors, so the processes S55 to S61 are executed for all 3 x 3 = 9 possible combinations. After the processes S55 to S61 have been executed for all combinations of start vector and end vector, the process proceeds to S62.

[0122] First, in S55, the CPU 51 calculates the arc with the maximum radius of curvature that passes through the start and end vectors to be processed in the direction of each vector's movement (i.e., the tangent direction of the arc coincides with the direction of each vector's movement).

[0123] Subsequently, in S56, the CPU 51 determines whether the arc calculated in S55 is included within the lane in which the vehicle travels (within the travel area acquired in S31) between the start vector and the end vector.

[0124] If it is determined that the arc calculated in S55 is within the lane in which the vehicle travels between the start vector and the end vector (within the travel area acquired in S31) (S56: YES), the process proceeds to S57. On the other hand, if it is determined that the arc calculated in S55 is not within the lane in which the vehicle travels between the start vector and the end vector (within the travel area acquired in S31) (S56: NO), the process proceeds to S58.

[0125] In S57, the CPU 51 generates a first travel trajectory for the arc between the start vector and the end vector calculated in S55. For example, the example shown in Figure 18 is an example where the arc 95 calculated in S55 is included within the lane in which the vehicle travels (within the travel area acquired in S31) between the start vector 83 and the end vector 84. Arc 95 is generated as the first travel trajectory. Then, the process transitions to S59.

[0126] On the other hand, in S58, the CPU 51 determines that the arc calculated in S55 is a trajectory that extends beyond the driving area and cannot be used. Therefore, it generates a new arc that passes through the clipping point 85 set in S53, and further generates a first driving trajectory that connects to the new arc by traveling straight along the direction of travel of the road to the start vector and end vector of the processing target. The first driving trajectory generated in S58 is a trajectory that passes through the start vector and end vector in the direction of travel of each vector. For example, the example shown in Figure 19 is an example where the arc 95 calculated in S55 is not included within the lane in which the vehicle travels (within the driving area acquired in S31) between the start vector 83 and the end vector 84, and a trajectory 96 that passes through the clipping point 85 is generated as the first driving trajectory. The conditions for the arc of trajectory 96 are that the curvature should be as small as possible, and that trajectory 96 does not involve a change in the direction of turning (does not include multiple turning movements).

[0127] Subsequently, in S59, the CPU 51 generates a second travel trajectory to move from the start vector acquired in S52 to the first travel trajectory generated in S57 or S58. Note that, as shown in Figures 18 and 19, if the start vector to be processed is the start vector acquired in S52, the second travel trajectory becomes part of the first travel trajectory, so the processing in S59 is unnecessary. On the other hand, as shown in Figure 20, if the start vector to be processed is not the start vector acquired in S52 (a start vector newly added in S54), a second travel trajectory is generated. For example, in the example shown in Figure 20, the first travel trajectory 96 is generated using a new start vector 92 set to the left of the center of the lane as the target of processing, and a new second travel trajectory 97 is generated to move from the original start vector 83 to the first travel trajectory 96. The second travel trajectory 97 generated in S45 is a trajectory that passes through the start vector 83 in the direction of travel of the start vector 83.

[0128] Next, in S60, the CPU 51 generates a third travel trajectory to move from the first travel trajectory generated in S57 or S58 to the end vector obtained in S52. Note that, as shown in Figures 18 and 19, if the end vector to be processed is the end vector obtained in S52, the third travel trajectory becomes part of the first travel trajectory, so the processing in S60 is unnecessary. On the other hand, as shown in Figure 20, if the end vector to be processed is not the end vector obtained in S52 (an end vector newly added in S54), a third travel trajectory is generated. For example, in the example shown in Figure 20, the first travel trajectory 96 is generated with a new end vector 94 set to the left of the center of the lane as the target of processing, and a new third travel trajectory 98 is generated to move from the first travel trajectory 96 to the original end vector 84. The third travel trajectory 98 generated in S46 is a trajectory that passes through the end vector 84 in the direction of travel of the end vector 84.

[0129] Here, the recommended vehicle trajectory when a vehicle moves to the right or left within a lane, as in the second and third trajectories described above, includes a clothoid curve with continuously changing curvature. More specifically, it is a trajectory formed by connecting multiple clothoid curves of different shapes. Figure 21 shows, for example, the recommended vehicle trajectory when moving to the right within a lane (note that when moving to the left, the trajectory is symmetrical). As shown in Figure 21, the recommended vehicle trajectory when moving to the right within a lane is a first clothoid curve 101 that proceeds from the starting point P1 to the first intermediate point P2 while gradually turning the steering wheel to the right (i.e., gradually increasing the curvature), a second clothoid curve 102 that proceeds from the first intermediate point P2 to the midpoint P3 while gradually returning the steering wheel to the straight direction (i.e., gradually decreasing the curvature), a third clothoid curve 103 that proceeds from the midpoint P3 to the second intermediate point P4 while gradually turning the steering wheel to the left (i.e., gradually increasing the curvature), and then from the second intermediate point P4, gradually It consists of a fourth clothoid curve 104 that moves towards the end point P5 while returning to the straight direction (i.e., while gradually changing the curvature). The lateral movement distance by clothoid curves 101-104 is set to the distance that overlaps with the first travel trajectory at P5 for the second travel trajectory, and to the distance that overlaps with the initial end vector 84 at P5 for the third travel trajectory. The CPU 51 then ensures that the acceleration (lateral G) generated when moving within the lane for each clothoid curve 101-104 does not exceed an upper limit (e.g., 0.2G) that does not cause discomfort to the vehicle occupants, and the rate of change of lateral G per unit time is also set to the same upper limit (e.g., 0.6m / s²). 3 With the condition that it does not exceed ), a clothoid curve is used to calculate a trajectory that is as smooth as possible and minimizes the distance required for movement within the lane. Then, by connecting the calculated clothoid curves 101 to 104, the second and third travel trajectories are calculated.

[0130] Subsequently, in S61, the CPU 51 combines the first travel trajectory generated in S57 or S58, the second travel trajectory generated in S59 (only if a second travel trajectory is generated), and the third travel trajectory generated in S60 (only if a third travel trajectory is generated) to form a single travel trajectory. The travel trajectory generated in S61 is a "recommended travel trajectory candidate for traveling through a turning section" generated for a combination of the start vector and end vector of the target to be processed. In particular, the travel trajectory is such that the vehicle's orientation when reaching the starting point 83 of the turning section, which is the target point, is the orientation set in S51, and the vehicle's orientation when reaching the ending point 84 of the turning section, which is the target point, is the orientation set in S51. For example, when a vehicle travels along the trajectory generated in S61, the orientation (angle) of the vehicle body at the start point 83 and end point 84 of the turning section is in the same direction as the road's direction of travel (parallel to the road), and the vehicle's direction of travel is straight ahead (steering angle is 0° (neutral state)). Furthermore, the trajectory generated in S61 is a combination of at least two trajectories, including a straight trajectory, a circular arc trajectory, and a clothoid curve trajectory, and the distance and the amount of change in direction (how the curvature changes) of each trajectory are at least specified.

[0131] Furthermore, in the case of a track consisting only of the first track generated in S57 or S58, or in the case of a track including the second and third tracks but where the arc and straight track are directly connected, there is a problem that the curvature does not match before and after the connection point of each track between the straight track and the arc track because a clothoid curve is not inserted between the arc track and the straight tracks before and after it (in order for the vehicle to travel along the track, it is necessary to stop and steer at each connection point). Therefore, it is desirable to modify the track so that a clothoid curve is inserted between the arc track and the straight track as shown below. However, it is not necessarily required to modify turning sections where it is not a problem to stop and steer along the way, such as turning sections where the vehicle turns to enter (enter) or exit (exit) a parking space, or turning sections where the vehicle turns to enter or exit a facility from a public road.

[0132] First, as shown in Figure 22, the radius of curvature R of the circular track 110 included in the candidate track generated in S61 is modified as needed. For example, it is modified to a radius of curvature smaller by a predetermined percentage (e.g., 80%). Next, a first clothoid curve 111 is drawn, which connects to the circular arc trajectory 110 with the same curvature as the circular arc trajectory 110, starting from a trajectory that moves in the direction of the start vector 83 at the beginning of the turning section. A second clothoid curve 112 is drawn, which connects to the circular arc trajectory 110 with the same curvature as the circular arc trajectory 110, and also becomes a trajectory that moves in the direction of the end vector 84 at the end of the turning section. The length Lc and clothoid constant A of each clothoid curve can be set as appropriate, but for example, Lc = 9.4m and A = 6.85 are used. A clothoid curve is a curve drawn when the curvature is changed at a constant rate with respect to distance (for example, if the vehicle speed is fixed, the steering angle is changed at a constant angular velocity). The clothoid curve can be calculated, for example, by calculating the Fresnel integral using Simpson's method or an approximation formula, or by replacing it with a complex plane. The method for calculating the soid curve is already publicly known, so I will omit the details. Next, the first clothoid curve 111, the circular arc trajectory 110, and the second clothoid curve 112 are connected, and straight trajectories 113 and 114 that connect to the connected trajectory (hereinafter referred to as the connected trajectory) are calculated as shown in Figure 22. For example, the straight trajectory 113 is a straight trajectory connecting the starting point of the turning section (start vector 83) to the starting point of the connected trajectory, and the straight trajectory 114 is a straight trajectory connecting the end point of the connected trajectory to the end point of the turning section (end vector 84). Then, the calculated straight trajectory 113, the connected trajectory, and the straight trajectory 114 are connected with the same curvature to generate the final candidate running trajectory 115. In the candidate running trajectory 115, the running position and direction of the vehicle traveling on the running trajectory are continuous (i.e., the running trajectory is a continuous line without interruption and does not bend in the middle). Furthermore, as shown in the graph in Figure 22, the change in direction (curvature) of the moving vehicle is also continuous. Specifically, the curvature before and after the connection points of the straight track 113 and the first clothoid curve 111, the first clothoid curve 111 and the circular arc track 110, the circular arc track 110 and the second clothoid curve 112, and the second clothoid curve 112 and the straight track 114 are the same, resulting in a smooth track. Note that the curvature (change in direction) before and after the connection points does not need to be perfectly identical; it may be required that it be within a predetermined range. Even in that case, the candidate track 115 will be a smooth track with continuous changes in direction within a predetermined range. Furthermore, regarding the candidate track connecting the first track 96, the second track 97, and the third track 98 as shown in Figure 20, the curvature before and after each track is the same at the connection point, and the curvature is also the same before and after the connection point with the straight tracks before and after. Therefore, even without making the above-mentioned modifications, a smooth track with continuous changes in direction within a predetermined range is obtained.

[0133] Similarly, for each combination of start and end vectors acquired in S52 and newly generated in S54, a "candidate driving trajectory recommended for driving through a turning section" is generated, and after generating "candidate driving trajectories recommended for driving through a turning section" for all combinations of start and end vectors, the process proceeds to S62.

[0134] Subsequently, in S62, the CPU 51 calculates the cost of traveling each of the multiple candidate travel paths generated in S61, taking into account the vehicle's behavior when traveling. The cost indicates the suitability of the travel path; a smaller cost indicates higher suitability. An example of the cost calculation method in S62 is described below.

[0135] Specifically, the final cost for each candidate track is calculated by adding up the costs calculated based on each of the following elements (1) to (3). (1) Travel time (or distance) ... Travel time [s] × 1.0 (2) Maximum curvature...Maximum curvature x 0.1 (3) Number of times the steering direction is changed... Number of times × 5.0

[0136] First, regarding (1), the cost is determined by the travel time along the track, and specifically, the longer the time required to travel along the track, the higher the cost calculated, meaning that it is less likely to be selected as a recommended track. Furthermore, assuming that the vehicle speed is constant when traveling through the turning section, the travel time along the track is also equivalent to the length of the travel distance.

[0137] Furthermore, for (2), the maximum curvature of the curves included in the track is calculated. Then, the cost is calculated based on the calculated maximum curvature. Specifically, the larger the maximum curvature of the track, the sharper the turns that will be made when traveling along the track, which places a greater load on the occupants, resulting in a higher cost, meaning that it is less likely to be selected as a recommended track.

[0138] Furthermore, for (3), the cost is determined according to the number of times the steering direction is changed within the driving trajectory, specifically the number of times the steering direction is changed. This indicates that a higher cost is calculated, meaning it is less likely to be selected as a recommended route.

[0139] Furthermore, when calculating the cost for a candidate trajectory in S62, it is not necessary to consider all of the elements (1) to (3) above, but rather to consider only some of the elements (1) to (3) above when calculating the cost. For example, the sum of the costs of (1) and (2) may be calculated. Alternatively, the cost may be calculated using elements other than those (1) to (3) above (for example, whether or not there is acceleration or deceleration, the amount of steering rotation, etc.).

[0140] Subsequently, in S63, the CPU 51 compares the costs calculated in S62 and selects the recommended trajectory for driving through the turning section from among the multiple candidate trajectories generated in S61. Basically, the candidate trajectory with the smallest calculated cost is selected as the recommended trajectory for driving through the turning section. Note that the trajectory calculated in S63 is a reference trajectory calculated without considering obstacles. If the reference trajectory does not overlap with an obstacle, that is, if the reference trajectory is a trajectory that can avoid the obstacle (S38: NO), the reference trajectory is determined to be the recommended trajectory for driving through the turning section. Then, the process moves to S28, where recommended trajectories are generated for driving along the recommended route derived in S25 for sections other than the turning section. Finally, by combining the generated trajectories, a static trajectory is generated, which is the trajectory recommended for the vehicle to drive on the roads included in the planned driving route (S29). Furthermore, the generated static trajectory is stored in the flash memory 54 or the like as support information used for automated driving assistance. On the other hand, if the standard trajectory cannot avoid the obstacle (S38: YES), the first avoidance trajectory generation process (S40), described later, will be performed.

[0141] Next, the subprocessing of the first avoidance trajectory generation process executed in S40 will be explained with reference to Figure 23. Figure 23 is a flowchart of the subprocessing program for the first avoidance trajectory generation process.

[0142] Here, the processes S71 to S81 below are basically the same as the processes S51 to S61 of the aforementioned reference track generation process (Figure 14). However, the processes differ in the following respects.

[0143] First, in S74, when generating a candidate for a new start vector in addition to the start vector obtained in S72 at the starting point of the turning section for which the driving trajectory is to be generated, as shown in Figure 24, a new start vector 91 is generated at a point moved a predetermined distance (for example, 1 / 4 or 1 / 6 of the lane width) outward from the initial start vector 83, and a new start vector 92 is generated at a point moved a predetermined distance (for example, 1 / 4 or 1 / 6 of the lane width) further outward from the curve. In addition, a new start vector 121 is generated at a point moved a predetermined distance (for example, 1 / 4 or 1 / 6 of the lane width) inward from the initial start vector 83, and a new start vector 122 is also generated at a point moved a predetermined distance (for example, 1 / 4 or 1 / 6 of the lane width) further inward from the curve. Similarly, when generating candidate termination vectors for the end of a turning section in addition to the termination vector 84 obtained in S72, as shown in Figure 24, a new termination vector 93 is generated at a point moved a predetermined distance (for example, 1 / 4 or 1 / 6 of the lane width) outward from the initial termination vector 84, and a new termination vector 94 is generated at a point moved a predetermined distance (for example, 1 / 4 or 1 / 6 of the lane width) further outward from the curve. In addition, a new termination vector 123 is generated at a point moved a predetermined distance (for example, 1 / 4 or 1 / 6 of the lane width) inward from the initial termination vector 84, and a new termination vector 124 is also generated at a point moved a predetermined distance (for example, 1 / 4 or 1 / 6 of the lane width) further inward from the curve. As a result, in the first avoidance driving trajectory generation process, when turning, if the vehicle turns from the inside of the road or enters the inside of the road after turning, the system will not intentionally make a turn. By including trajectories with a high ratio (low turning radius) as candidate trajectories, it becomes possible to generate trajectories that avoid obstacles.

[0144] Furthermore, in S79, when generating a second travel trajectory to move from the start vector acquired in S72 to the first travel trajectory generated in S77 or S78 (towards the outside of the road), the CPU 51 ensures that the acceleration (lateral G) generated when moving within the lane does not exceed an upper limit (e.g., 0.2G) that does not cause discomfort to the vehicle occupants, and that the rate of change of lateral G per unit time also exceeds an upper limit (e.g., 0.6m / s²). 3 The system calculates a trajectory that minimizes the distance required to move within the lane, provided that it does not exceed a certain limit. This makes it easier to generate a trajectory that avoids obstacles.

[0145] On the other hand, in the case where S80 generates a third travel trajectory to move from the first travel trajectory generated in S77 or S78 to the termination vector obtained in S72 (moving towards the inside of the road), the CPU 51 also ensures that the acceleration (lateral G) generated when moving within the lane does not exceed an upper limit (e.g., 0.2G) that does not cause discomfort to the vehicle occupants, and that the rate of change of lateral G per unit time also exceeds an upper limit (e.g., 0.6m / s²). 3 The system calculates a trajectory that minimizes the distance required to move within the lane, provided that it does not exceed a certain limit. This makes it easier to generate a trajectory that avoids obstacles.

[0146] Then, in the same manner as the reference trajectory generation process, for each combination of start vectors and end vectors acquired in S72 and newly generated in S74, a "candidate trajectory recommended for driving through a turning section" is generated. After generating "candidate trajectories recommended for driving through a turning section" for all combinations of start vectors and end vectors, the process proceeds to S82. Compared to the reference trajectory generation process, the number of candidate start and end vectors generated in S74 increases, resulting in a larger number of candidate trajectories being generated. For example, in the example shown in Figure 24, there are 5 start vectors and 5 end vectors, so the processes in S75 to S81 are executed for all 25 possible combinations (5 x 5), and a "candidate trajectory recommended for driving through a turning section" is generated for each combination.

[0147] Furthermore, if the running track consists only of the first running track generated in S77 or S78, or if it includes the second and third running tracks but the arc and straight tracks are directly connected, there is a problem that the curvature does not match before and after the connection points of each track (in order for the vehicle to travel along the running track, it is necessary to stop and operate the steering wheel at each connection point). Therefore, it is desirable to modify the process to insert a clothoid curve between the arc and straight tracks, similar to the reference running track generation process described above (Figure 14) (see Figure 22).

[0148] Subsequently, in S82, the CPU 51 calculates the cost of driving each of the multiple candidate driving trajectories generated in S81, taking into account the vehicle's behavior when driving. The cost indicates the suitability of the trajectory, with a smaller cost indicating higher suitability. This is basically the same as in S62, and the final cost for each candidate driving trajectory is calculated by adding the costs calculated based on each of the elements (1) to (3) described above.

[0149] However, in S82, when the CPU 51 calculates the cost based on each of the elements (1) to (3), it first determines whether each of the multiple candidate travel trajectories generated in S81 overlaps with an obstacle identified by the obstacle information acquired in S26. Here, as shown in Figure 3, the obstacle information identifies the link ID of the link where the obstacle is located, the distance from the starting point of the link, the lane where the obstacle is located, and the range (occupied area) within the lane where the obstacle is located. Based on the obstacle information, each of the multiple candidate travel trajectories overlaps with an obstacle. It is possible to determine whether or not to do so. Furthermore, in S82, "the candidate trajectory and the obstacle overlap" means, as in S38 above, not only when the area where the obstacle is located overlaps with the candidate trajectory, but also when the area where the obstacle is located overlaps with the vehicle when the vehicle travels along the candidate trajectory, i.e., when the distance X between the area where the obstacle is located and the candidate trajectory is less than a predetermined distance (for example, 1 / 2 of the vehicle width + α) (see Figure 13). Then, the candidate trajectory determined to overlap with an obstacle is excluded from the cost calculation, i.e., removed from the list of candidate trajectories. Alternatively, instead of excluding the candidate trajectory determined to overlap with an obstacle from the cost calculation, a very large value may be added to the cost.

[0150] Subsequently, in S83, the CPU 51 compares the costs calculated in S82 and selects a recommended driving path from among the multiple candidate driving paths generated in S81 that avoids obstacles and is suitable for driving through turning sections. Basically, the candidate driving path with the smallest cost calculated without overlapping with obstacles is selected as the recommended driving path. Then, the process moves to S28, where recommended driving paths are generated for driving along the recommended route derived in S25 for sections other than turning sections. Finally, by combining the generated driving paths, a static driving path is generated, which is the driving path recommended for the vehicle to take on the roads included in the planned driving route (S29). Furthermore, the generated static driving path is stored in flash memory 54 or the like as support information used for automated driving assistance. However, if a driving path that can avoid obstacles cannot be generated in the first avoidance driving path generation process (S41: NO), the second avoidance driving path generation process (S44) or the third avoidance driving path generation process (S45) described later will be performed.

[0151] Next, the subprocessing of the second avoidance trajectory generation process executed in S44 will be explained with reference to Figure 25. Figure 25 is a flowchart of the subprocessing program for the second avoidance trajectory generation process.

[0152] First, in S91, CPU51 sets the recommended vehicle orientation when positioned at the starting point (target point) of the turning section and the recommended vehicle orientation when positioned at the ending point (target point) of the turning section. The details are the same as in S51, so the explanation will be omitted.

[0153] Next, in S92, the CPU 51 obtains a start vector that specifies the vehicle's position and direction at the start of the turning section, and an end vector that specifies the vehicle's position and direction at the end of the turning section, based on the positions of the start and end of the turning section obtained in S36, and the vehicle's recommended direction when positioned at the start of the turning section and the vehicle's recommended direction when positioned at the end of the turning section, as set in S91. The details are the same as in S52, so the explanation is omitted.

[0154] Subsequently, in S93, the CPU 51 sets a base guide line for calculating the driving trajectory for the turning section, along the center line of the lane (driving area) on which the vehicle is traveling, as calculated in S32. For example, Figure 26 shows an example of a start vector 83, an end vector 84, and a guide line 125 set for a turning section that includes a right-angle curve. As shown in Figure 26, the guide line 125 is set on the center line of the lane (driving area) on which the vehicle is traveling. Note that the second avoidance driving trajectory generation process is executed when there is an obstacle in the turning section and the obstacle overlaps with the center line (S43: YES), so as shown in Figure 26, the obstacle 126 and the guide line 125 also overlap.

[0155] Next, in S94, the CPU 51 identifies the area where the guide line set in S93 and the obstacle overlap. Here, as shown in Figure 3, the obstacle information obtained from the server device 4 includes the link ID of the link where the obstacle is located, the distance from the starting point of the link, and the position of the obstacle. The system identifies the lane in which the vehicle will be positioned and the area within that lane where the obstacle is located (occupied area). Based on the obstacle information, it is possible to identify the area where the guide line and the obstacle overlap. Furthermore, in S94, the "area where the guide line and the obstacle overlap" includes not only the area where the obstacle 126 and the guide line 125 overlap, but also the area where a vehicle positioned along the guide line 125 overlaps with the obstacle, that is, the area obtained by adding the total length of the vehicle before and after the area where the obstacle 126 and the guide line 125 overlap, as shown in Figure 27. For example, in the example shown in Figure 27, the area from P to Q is identified as the area where the guide line 125 and the obstacle 126 overlap.

[0156] Next, in S95, the CPU 51 identifies the overlapping section as the range obtained by adding the distance required for the vehicle's lateral movement to the range before and after the "range where the guide line and the obstacle overlap" identified in S94. Here, "the distance required for the vehicle's lateral movement" is defined as the distance along the direction of road travel required to move from the center line (guide line) of the lane to the outermost edge of the lane (the same distance is used if the distance along the direction of road travel required to move from the outermost edge of the lane to the center line of the lane). Here, the recommended vehicle trajectory when the vehicle moves to the right or left within the lane includes a clothoid curve with continuously changing curvature. More specifically, it is a trajectory formed by connecting multiple clothoid curves of different shapes, as shown in Figure 21 above. For example, in Figure 21, if P1 is on the center line and P5 is the outermost position in the lane, then the distance along the direction of road travel from P1 to P5 is "the distance required for the vehicle's lateral movement". Furthermore, the acceleration (lateral G) generated when moving within a lane must not exceed an upper limit (e.g., 0.2G) that does not cause discomfort to the vehicle occupants, and the rate of change of lateral G per unit time must also not exceed an upper limit (e.g., 0.6 m / s²). 3 The minimum distance required for movement within the lane is calculated, provided that it does not exceed [a certain value]. As a result, in the example shown in Figure 28, for example, the section from R to S, obtained by adding the "distance required for lateral movement of the vehicle" before and after the range from P to Q, is identified as the overlapping section.

[0157] Subsequently, in S96, the CPU 51 modifies the guide lines by moving the overlapping section identified in S95 from the guide lines set in S93 away from the obstacle. Specifically, as shown in Figure 29, P and Q are slid along the road width towards the road edge that is away from the obstacle 126 (in the example shown in Figure 29, the road edge on the inside of the curve). In particular, they are moved to the limit where there is no risk of the vehicle contacting the road edge if the vehicle is assumed to be traveling along the guide line 125. Straight lines are drawn between R and P, P and Q, and Q and S, and as a result, the guide line 125, which is used as the base when calculating the travel trajectory, is modified to a shape that does not overlap with the obstacle 126, as shown in Figure 29.

[0158] Next, in S97, the CPU 51 calculates a moving average of the guide line for the turning section based on the guide line corrected in S96. The moving average is a line connecting the average points of a predetermined number of consecutive coordinate points arranged along the guide line. More specifically, for each coordinate point set at predetermined intervals along the guide line, the average point (the point obtained by averaging the latitude and longitude of each) of five coordinate points including the two coordinate points before and after it is calculated, and the line connecting these average points is the moving average. Figure 30 shows the moving average 127 calculated for the guide line 125 shown in Figure 29.

[0159] Subsequently, in S98, the CPU 51 divides the overlapping interval identified in S95 using the intersection point of the corrected guide line and the moving average line calculated in S97 as the boundary. For example, in the example shown in Figure 30, the overlapping interval is divided with T1 to T3 as the boundary.

[0160] Next, in S99, the CPU 51 generates a new candidate start vector at the starting point of the turning section for which the travel trajectory is to be generated, in addition to the start vector obtained in S92. Furthermore, it generates a new candidate end vector at the end point of the turning section, in addition to the end vector obtained in S92. Specifically, this is done in the same way as in S74 of the first avoidance travel trajectory generation process (Figure 23). As shown in 24, a new start vector 91 is generated at a point that moves a predetermined distance (for example, 1 / 4 or 1 / 6 of the lane width) outward from the initial start vector 83, and a new start vector 92 is generated at a point that moves a predetermined distance (for example, 1 / 4 or 1 / 6 of the lane width) further outward from the curve. In addition, a new start vector 121 is generated at a point that moves a predetermined distance (for example, 1 / 4 or 1 / 6 of the lane width) inward from the initial start vector 83, and a new start vector 122 is also generated at a point that moves a predetermined distance (for example, 1 / 4 or 1 / 6 of the lane width) further inward from the curve. Similarly, a new termination vector 93 is generated at a point moved a predetermined distance (for example, 1 / 4 or 1 / 6 of the lane width) outward from the initial termination vector 84, and a new termination vector 94 is generated at a point moved another predetermined distance (for example, 1 / 4 or 1 / 6 of the lane width) outward from the curve. In addition, a new termination vector 123 is generated at a point moved a predetermined distance (for example, 1 / 4 or 1 / 6 of the lane width) inward from the initial termination vector 84, and a new termination vector 124 is also generated at a point moved another predetermined distance (for example, 1 / 4 or 1 / 6 of the lane width) inward from the curve.

[0161] Furthermore, in S100, the CPU 51 sets candidate passing points for the vehicle with respect to the boundaries T1 to T3, which were created in S98 to divide the overlapping section. For example, as shown in Figure 31, if the normal of the moving average line 127 that passes through the intersection of the corrected guide line and the moving average line calculated in S97 is set as the boundary line T1 to T3, then candidate passing points are set on the boundary line T1 to T3. Note that there may be only one candidate passing point for each boundary, or multiple points may be set. For example, in the example shown in Figure 31, candidate passing points X1 to X3 are set for boundary line T1, candidate passing points Y1 to Y3 are set for boundary line T2, and candidate passing points Z1 to Z3 are set for boundary line T3, but four or more points may be set. It is desirable that the candidate passing points be set within the lane (driving area) where the vehicle travels and in a position that does not overlap with the obstacle 126. It is also desirable that at least the intersection of the guide line and the moving average line be included as candidate passing points. While generating more waypoints increases the likelihood of generating a more appropriate trajectory, it also increases the processing load involved in calculating the trajectory because the number of possible trajectories increases.

[0162] Next, in S101, the CPU 51 obtains a passage vector that specifies the recommended vehicle position and direction when passing through each of the candidate passage points set in S100. Here, the position of the passage vector is set to match the candidate passage points set in S100. The direction of the passage vector is set to the direction that intersects the boundary lines T1 to T3, i.e., the tangent direction of the moving average line 127. Figure 32 shows an example of passage vectors set for boundary lines T1 to T3.

[0163] The subsequent processes S102 to S105 are executed for each combination of the start vector and end vector obtained in S92 and newly generated in S99, and the pass vector obtained in S101. For example, in the examples shown in Figures 24 and 32, there are 5 start vectors, 5 end vectors, and 3 x 3 x 3 pass vectors, so the processes S102 to S105 are executed for all 675 possible combinations (5 x 3 x 3 x 3 x 5). After the processes S102 to S105 have been executed for all combinations of start vectors, end vectors, and pass vectors, the process proceeds to S106.

[0164] First, in S102, the CPU 51 generates a first travel trajectory that passes through the start vector, end vector, and trajectory of the object to be processed, respectively, in the direction of each vector's movement. The generated trajectory is designed to have the smallest possible curvature. Here, in generating the first travel trajectory in S102, for example, the section from the start of the turning section to boundary line T1 is considered the first turning section, the section from boundary line T1 to boundary line T2 is considered the second turning section, the section from boundary line T2 to boundary line T3 is considered the third turning section, and the section from boundary line T3 to the end of the turning section is considered the fourth turning section, and so on for each of the first to fourth turns. Alternatively, the recommended travel trajectory that passes through the vectors at the start and end points in a section in the direction of the vectors may be calculated, and the final result of connecting these trajectories may be generated as the first travel trajectory. In this case, the passing vectors X1 to X3 set relative to boundary line T1 become the end vector of the first turning section and the start vector of the second turning section, the passing vectors Y1 to Y3 set relative to boundary line T2 become the end vector of the second turning section and the start vector of the third turning section, and the passing vectors Z1 to Z3 set relative to boundary line T3 become the end vector of the third turning section and the start vector of the fourth turning section. The recommended travel trajectory from the start vector to the end vector in each of the first to fourth turning sections can be calculated using the same process as the reference travel trajectory generation process (Figure 14) already described.

[0165] Subsequently, in S103, the CPU 51 generates a second travel trajectory to move from the start vector obtained in S92 to the first travel trajectory generated in S102 (towards the outside of the road). The details are the same as those described in S59 and S79, so the explanation will be omitted.

[0166] Next, in S104, the CPU 51 generates a third travel trajectory to move from the first travel trajectory generated in S102 to the termination vector obtained in S92 (moving towards the inside of the road). The details are the same as those of the processes in S59 and S79 described above, so the explanation will be omitted.

[0167] Subsequently, in S105, the CPU 51 combines the first travel trajectory generated in S102, the second travel trajectory generated in S103 (only if a second travel trajectory is generated), and the third travel trajectory generated in S104 (only if a third travel trajectory is generated) to form a single travel trajectory. The travel trajectory generated in S105 is a "recommended travel trajectory candidate for traveling through a turning section" generated for the combination of the start vector, end vector, and passing vector of the target. In particular, the travel trajectory is such that the vehicle's orientation when reaching the starting point 83 of the turning section, which is the target point, is the orientation set in S91, and the vehicle's orientation when reaching the ending point 84 of the turning section, which is the target point, is the orientation set in S91. For example, when a vehicle travels along the trajectory generated in S105, the orientation (angle) of the vehicle body at the start point 83 and end point 84 of the turning section will be in the same direction as the road's direction of travel (parallel to the road), and the vehicle's direction of travel will be straight ahead (steering angle 0° (neutral state)). Furthermore, the trajectory generated in S105 is based on the center line, and the trajectory is modified so that the overlapping section, which includes the area within the center line that overlaps with an obstacle, does not overlap with the obstacle.

[0168] Furthermore, if the trajectory generated in S105 does not include a clothoid curve between the arc trajectory and the straight trajectories before and after it, there is a problem in that the curvature does not match before and after the connection points of the straight trajectories and the arc trajectories (in order for the vehicle to travel along the trajectory, it is necessary to stop at each connection point and operate the steering wheel). Therefore, it is desirable to modify the trajectory to include a clothoid curve between the arc trajectory and the straight trajectory, similar to the reference trajectory generation process described above (Figure 14) (see Figure 22).

[0169] Subsequently, in S106, the CPU 51 calculates the cost of driving each of the multiple candidate driving trajectories generated in S105, taking into account the vehicle's behavior when driving. The cost indicates the suitability of the trajectory, with a smaller cost indicating higher suitability. This is basically the same as in S62, and the final cost for each candidate driving trajectory is calculated by adding the costs calculated based on each of the elements (1) to (3) described above.

[0170] However, in S106, CPU51 calculates the cost based on each of the elements (1) to (3). In performing this, first, for each of the multiple candidate driving trajectories generated in S105, it is determined whether or not it overlaps with an obstacle identified by the obstacle information acquired in S26. Here, as shown in Figure 3, the obstacle information identifies the link ID of the link where the obstacle is located, the distance from the starting point of the link, the lane where the obstacle is located, and the range (occupied area) within the lane where the obstacle is located. Based on the obstacle information, it is possible to determine whether or not each of the multiple candidate driving trajectories overlaps with an obstacle. Furthermore, in S106, "the candidate driving trajectory and the obstacle overlap" means not only when the range where the obstacle is located and the candidate driving trajectory overlap, as described in S38 above, but also when the range where the obstacle is located and the vehicle overlap when the vehicle is traveling along the candidate driving trajectory, that is, when the distance X between the range where the obstacle is located and the candidate driving trajectory is less than a predetermined distance (for example, 1 / 2 of the vehicle width + α) (see Figure 13). Furthermore, candidate routes that are determined to overlap with obstacles are excluded from the cost calculation, i.e., removed from the list of candidate routes. Alternatively, instead of excluding candidate routes that overlap with obstacles from the cost calculation, a very large value may be added to the cost.

[0171] Subsequently, in S107, the CPU 51 compares the costs calculated in S106 and selects a recommended driving path from among the multiple driving path candidates generated in S105 that avoids obstacles and is suitable for driving through turning sections. Basically, the candidate driving path with the smallest cost calculated without overlapping with obstacles is selected as the recommended driving path. Then, the process moves to S28, where recommended driving paths are generated for sections other than turning sections, following the recommended route derived in S25. Finally, by combining the generated driving paths, a static driving path is generated, which is the driving path recommended for the vehicle on the roads included in the planned driving route (S29). Furthermore, the generated static driving path is stored in the flash memory 54 or the like as support information used for automated driving assistance. Furthermore, the second avoidance trajectory generation process assumes that at least one candidate trajectory capable of avoiding the obstacle is generated in S105. However, if no candidate trajectory capable of avoiding the obstacle can be generated, it is desirable to change the lane if avoidance is possible by changing the lane, and to suggest changing the planned route if avoidance is not possible even by changing the lane.

[0172] Next, the subprocessing of the third avoidance trajectory generation process executed in S45 will be explained with reference to Figure 33. Figure 33 is a flowchart of the subprocessing program for the third avoidance trajectory generation process.

[0173] First, in S111, the CPU 51 sets the recommended vehicle orientation when positioned at the starting point (target point) of the turning section and the recommended vehicle orientation when positioned at the ending point (target point) of the turning section. The details are the same as in S51, so the explanation will be omitted.

[0174] Next, in S112, the CPU 51 obtains a start vector that specifies the position and direction of the vehicle at the start of the turning section, and an end vector that specifies the position and direction of the vehicle at the end of the turning section, based on the positions of the start and end of the turning section obtained in S36, and the vehicle direction recommended when the vehicle is located at the start of the turning section and the vehicle direction recommended when the vehicle is located at the end of the turning section, as set in S111. The details are the same as in S52, so the explanation is omitted.

[0175] Subsequently, in S113, the CPU 51 sets a base guide line for calculating the travel path for the turning section, along the reference travel path calculated in S37. The reference travel path is the recommended travel path when traveling through the turning section, without considering obstacles. For example, Figure 34 shows an example of a start vector 83, an end vector 84, and a guide line 131 set for a turning section that includes a right-angle curve. As shown in Figure 34, the guide line 131 is set on the reference travel track. Note that the third avoidance travel track generation process is executed when there is an obstacle in the turning section and the obstacle does not overlap with the centerline but overlaps with the reference travel track (S38: YES, S43: NO). Therefore, as shown in Figure 34, the obstacle 126 and the guide line 131 also overlap.

[0176] Next, in S114, the CPU 51 identifies the area where the guide line set in S113 and the obstacle overlap. Here, as shown in Figure 3, the obstacle information acquired from the server device 4 identifies the link ID of the link where the obstacle is located, the distance from the starting point of the link, the lane where the obstacle is located, and the area (occupied area) where the obstacle is located within the lane. Based on this obstacle information, it is possible to identify the area where the guide line and the obstacle overlap. Furthermore, in S114, the "area where the guide line and the obstacle overlap" includes not only the area where the obstacle 126 and the guide line 131 overlap, but also the area where a vehicle positioned along the guide line 131 overlaps with the obstacle, that is, the area obtained by adding the total length of the vehicle before and after the area where the obstacle 126 and the guide line 131 overlap, as shown in Figure 35. For example, in the example shown in Figure 35, the area from P to Q is identified as the area where the guide line 131 and the obstacle 126 overlap.

[0177] Next, in S115, the CPU 51 identifies an overlapping section by adding the distance required for the vehicle's lateral movement to the area before and after the "area where the guide line and the obstacle overlap" identified in S114. Here, "the distance required for the vehicle's lateral movement" is defined as the distance along the road direction required to move from the reference driving trajectory (guide line) to a position within the lane where the obstacle can be avoided (for example, an intermediate position between the obstacle and the edge of the lane) (the same distance is used if the distance along the road direction required to move from the intermediate position to the reference driving trajectory is the same). Here, the recommended driving trajectory for a vehicle moving to the right or left within the lane includes a clothoid curve with continuously changing curvature. More specifically, it is a trajectory formed by connecting multiple clothoid curves of different shapes, as shown in Figure 21 above. For example, in Figure 21, if P1 is on the reference driving trajectory and P5 is an intermediate position between the obstacle and the edge of the lane, then the distance along the road direction from P1 to P5 is "the distance required for the vehicle's lateral movement". Furthermore, the acceleration (lateral G) generated when moving within a lane must not exceed an upper limit (e.g., 0.2G) that does not cause discomfort to the vehicle occupants, and the rate of change of lateral G per unit time must also not exceed an upper limit (e.g., 0.6 m / s²). 3The minimum distance required for movement within the lane is calculated, provided that it does not exceed [a certain value]. As a result, in the example shown in Figure 36, for example, the section from R to S, obtained by adding the "distance required for lateral movement of the vehicle" before and after the range from P to Q, is identified as the overlapping section.

[0178] Subsequently, in S116, the CPU 51 modifies the guide lines by moving the overlapping section identified in S115 from the guide lines set in S113 away from the obstacle. Specifically, as shown in Figure 37, P and Q are slid along the road width towards the road edge away from the obstacle 126 (in the example shown in Figure 37, the road edge on the inside of the curve). In particular, they are moved to a position midway between the obstacle 126 and the road edge. Straight lines are drawn between R and P, P and Q, and Q and S, and as a result, the guide line 131 that serves as the base when calculating the driving trajectory is modified to a shape that does not overlap with the obstacle 126, as shown in Figure 37.

[0179] Next, in S117, the CPU 51 calculates a moving average line of the guide line for the turning section based on the guide line modified in S116. The moving average line is a line connecting the average points of a predetermined number of consecutive coordinate points arranged along the guide line. The details are the same as in S97, so the explanation is omitted (see Figure 30).

[0180] Subsequently, in S118, the CPU 51 divides the overlapping interval identified in S115 using the intersection point of the corrected guide line and the moving average line calculated in S117 as the boundary.

[0181] Next, in S119, the CPU 51 generates a new candidate start vector at the starting point of the turning section for which the driving trajectory is to be generated, in addition to the start vector obtained in S112. Furthermore, it generates a new candidate end vector at the end point of the turning section, in addition to the end vector obtained in S112. Specifically, as shown in Figure 24, similar to S74 of the first avoidance driving trajectory generation process (Figure 23), a new start vector 91 is generated at a point moved a predetermined distance (for example, 1 / 4 or 1 / 6 of the lane width) outward from the initial start vector 83, and a new start vector 92 is generated at a point moved a predetermined distance (for example, 1 / 4 or 1 / 6 of the lane width) further outward from the curve. In addition, a new start vector 121 is generated at a point moved a predetermined distance (for example, 1 / 4 or 1 / 6 of the lane width) inward from the initial start vector 83, and a new start vector 122 is also generated at a point moved a predetermined distance (for example, 1 / 4 or 1 / 6 of the lane width) further inward from the curve. Similarly, a new termination vector 93 is generated at a point moved a predetermined distance (for example, 1 / 4 or 1 / 6 of the lane width) outward from the initial termination vector 84, and a new termination vector 94 is generated at a point moved another predetermined distance (for example, 1 / 4 or 1 / 6 of the lane width) outward from the curve. In addition, a new termination vector 123 is generated at a point moved a predetermined distance (for example, 1 / 4 or 1 / 6 of the lane width) inward from the initial termination vector 84, and a new termination vector 124 is also generated at a point moved another predetermined distance (for example, 1 / 4 or 1 / 6 of the lane width) inward from the curve.

[0182] Furthermore, in S120, the CPU 51 sets candidate passing points for the vehicle with respect to the boundaries T1 to T3, which were created in S118 to divide the overlapping section. The details are the same as in S100, so the explanation is omitted (see Figure 31).

[0183] Next, in S121, the CPU 51 obtains a passage vector that specifies the recommended vehicle position and direction when passing through each of the candidate passage points set in S120. Here, the position of the passage vector is set to match the candidate passage points set in S120. The direction of the passage vector is set to the direction that intersects the boundary lines T1 to T3, i.e., the tangent direction of the moving average line 127 (see Figure 32).

[0184] The subsequent processes S122 to S125 are executed for each combination of the start vector and end vector obtained in S112 and newly generated in S119, and the pass vector obtained in S121. For example, in the examples shown in Figures 24 and 32, there are 5 start vectors, 5 end vectors, and 3 x 3 x 3 pass vectors, so the processes S122 to S125 are executed for all 675 possible combinations (5 x 3 x 3 x 3 x 5). After the processes S122 to S125 have been executed for all combinations of start vectors, end vectors, and pass vectors, the process proceeds to S126.

[0185] First, in S122, the CPU 51 generates a first travel trajectory that passes through the start vector, end vector, and passing vector of the object to be processed, respectively, in the direction of each vector's movement. The condition is that the curvature of the generated trajectory arc should be as small as possible. Here, for generating the first travel trajectory in S122, for example, the section from the start point of the turning section to boundary line T1 may be considered the first turning section, the section from boundary line T1 to boundary line T2 may be considered the second turning section, the section from boundary line T2 to boundary line T3 may be considered the third turning section, and the section from boundary line T3 to the end point of the turning section may be considered the fourth turning section. In each of the first to fourth turning sections, recommended travel trajectories that pass through the vectors at the start and end points in the direction of the vectors are calculated, and finally, the first travel trajectory is generated by connecting these trajectories. In that case, the passing vectors X1~X3 set relative to boundary line T1 become the end vector of the first turning section and the start vector of the second turning section, and the passing vectors Y1~Y3 set relative to boundary line T2 become the end vector of the second turning section and the start vector of the third turning section. As a result, the passing vectors Z1 to Z3 set relative to the boundary line T3 become the end vector of the third turning section and the start vector of the fourth turning section. Furthermore, the recommended travel trajectory from the start vector to the end vector in each of the first to fourth turning sections can be calculated using the same process as the reference travel trajectory generation process (Figure 14) that has already been explained.

[0186] Subsequently, in S123, the CPU 51 generates a second travel trajectory to move from the start vector obtained in S112 to the first travel trajectory generated in S122 (towards the outside of the road). The details are the same as those described in S59 and S79, so the explanation is omitted.

[0187] Next, in S124, the CPU 51 generates a third travel trajectory to move from the first travel trajectory generated in S122 to the end vector obtained in S112 (towards the inside of the road). The details are the same as those of the processes in S59 and S79 described above, so the explanation will be omitted.

[0188] Subsequently, in S125, the CPU 51 combines the first travel trajectory generated in S122, the second travel trajectory generated in S123 (only if a second travel trajectory is generated), and the third travel trajectory generated in S124 (only if a third travel trajectory is generated) to form a single travel trajectory. The travel trajectory generated in S125 is a "recommended travel trajectory candidate for traveling through a turning section" generated for the combination of the start vector, end vector, and passing vector of the target. In particular, the travel trajectory is such that the vehicle's orientation when reaching the starting point 83 of the turning section, which is the target point, is the orientation set in S111, and the vehicle's orientation when reaching the ending point 84 of the turning section, which is the target point, is the orientation set in S111. For example, when a vehicle travels along the trajectory generated in S125, the orientation (angle) of the vehicle body at the start point 83 and end point 84 of the turning section will be in the same direction as the road's direction of travel (parallel to the road), and the vehicle's direction of travel will be straight ahead (steering angle 0° (neutral state)). Furthermore, the trajectory generated in S125 is based on the reference trajectory, and the overlapping section within the reference trajectory that includes the area overlapping with an obstacle will be modified so that the trajectory does not overlap with the obstacle.

[0189] Furthermore, if the trajectory generated in S125 does not include a clothoid curve between the arc trajectory and the straight trajectories before and after it, there is a problem in that the curvature does not match before and after the connection points of the straight trajectories and the arc trajectories (in order for the vehicle to travel along the trajectory, it is necessary to stop at each connection point and operate the steering wheel). Therefore, it is desirable to modify the trajectory to include a clothoid curve between the arc trajectory and the straight trajectory, similar to the reference trajectory generation process described above (Figure 14) (see Figure 22).

[0190] Subsequently, in S126, the CPU 51 calculates the cost of driving each of the multiple candidate driving trajectories generated in S125, taking into account the vehicle's behavior when driving. The cost indicates the suitability of the trajectory, with a smaller cost indicating higher suitability. This is basically the same as in S62, and the final cost for each candidate driving trajectory is calculated by adding the costs calculated based on each of the elements (1) to (3) described above.

[0191] However, in S126, when the CPU 51 calculates the cost based on each of the elements (1) to (3), it first determines whether each of the multiple candidate travel trajectories generated in S125 overlaps with an obstacle identified by the obstacle information acquired in S26. Here, as shown in Figure 3, the obstacle information identifies the link ID of the link where the obstacle is located, the distance from the starting point of the link, the lane where the obstacle is located, and the range (occupied area) within the lane where the obstacle is located. Based on the obstacle information, each of the multiple candidate travel trajectories and the obstacle are determined. It is possible to determine whether or not there is an overlap. Furthermore, in S126, "the candidate trajectory and the obstacle overlap" means not only when the area where the obstacle is located overlaps with the candidate trajectory, as described in S38 above, but also when the area where the obstacle is located overlaps with the vehicle when the vehicle travels along the candidate trajectory, i.e., when the distance X between the area where the obstacle is located and the candidate trajectory is less than a predetermined distance (for example, 1 / 2 of the vehicle width + α), it is considered that "the candidate trajectory and the obstacle overlap" (see Figure 13). Then, the candidate trajectory determined to overlap with an obstacle is excluded from the cost calculation, i.e., removed from the list of candidate trajectories. Alternatively, instead of excluding the candidate trajectory determined to overlap with an obstacle from the cost calculation, a very large value may be added to the cost.

[0192] Subsequently, in S127, the CPU 51 compares the costs calculated in S126 and selects a recommended driving path from among the multiple candidate driving paths generated in S125 that avoids obstacles and is suitable for driving through turning sections. Basically, the candidate driving path with the smallest cost calculated without overlapping with obstacles is selected as the recommended driving path. Then, the process moves to S28, where recommended driving paths are generated for sections other than turning sections, following the recommended route derived in S25. Finally, by combining the generated driving paths, a static driving path is generated, which is the driving path recommended for the vehicle on the roads included in the planned driving route (S29). Furthermore, the generated static driving path is stored in the flash memory 54 or the like as support information used for automated driving assistance. Furthermore, the second avoidance trajectory generation process assumes that at least one candidate trajectory capable of avoiding the obstacle is generated in S125. However, if no candidate trajectory capable of avoiding the obstacle can be generated, it is desirable to change the lane if the obstacle can be avoided by changing lanes, and to suggest changing the planned route if the obstacle cannot be avoided by changing lanes.

[0193] In the above embodiment, we have explained an example of generating a static driving trajectory for a turning section where a vehicle travels on a curved road (including not only cases where the road bends in an arc, but also cases where it bends at a predetermined angle such as a right angle). However, other examples include sections at intersections (junctions) where vehicles turn left or right, sections where vehicles travel while turning within facilities such as parking lots, sections where vehicles turn to enter or exit a parking space, or sections where vehicles turn to enter or exit a facility from a public road. Only some of the above may be included as turning sections. Alternatively, other sections may also be included as turning sections. For example, sections where lanes are changed may also be included as turning sections.

[0194] Furthermore, it is desirable to set the starting and ending points of the turning section (the positions where the start and end vectors are set) according to different criteria for each type of turning section. For example, as shown in Figure 38, for the section of an intersection (junction) where a vehicle turns right or left, the starting point of the turning section is the point where the vehicle begins to enter the intersection (the stop line if there is one), and the ending point is the point where the vehicle has completed exiting the intersection. Also, as shown in Figure 39, for entry into a parking space, the starting point of the turning section is a point on the roadway a predetermined distance before the parking space to be parked, and the ending point is the parking space to be parked. Also, for exit from a parking space, the starting point of the turning section is the parking space to be parked, and the ending point is a point on the roadway a predetermined distance from the parking space in the direction of travel. Also, as shown in Figure 40, for entry into a facility from a public road, the starting point of the turning section is a point on the public road a predetermined distance before the entrance to the facility, and the ending point is the point where the vehicle has entered the facility a predetermined distance from the entrance. Furthermore, for exiting the facility onto a public road, the turning section will begin at a point a predetermined distance inside the facility from the facility entrance, and end at a point on the public road a predetermined distance in the direction of travel from the facility entrance.

[0195] Furthermore, in the case of intersections like the one shown in Figure 38, there are no lanes within the intersection, but there are guide lines. In addition to road markings such as guide lines and diamond-shaped traffic guides (diamond marks) placed in the center of intersections, the system generates the aforementioned driving trajectory by considering structures such as poles as the edges of the lanes. Furthermore, for entry into or exit from a parking space as shown in Figure 39, the lane markings, in addition to the lane markings, are considered as the edge of the lane when generating the aforementioned driving trajectory. In addition, the direction of the start and end vectors set at the start and end points of a turning section is set parallel to the parking space when the parking space is the start or end point of the turning section, as shown in Figure 39. However, for the driving trajectory to enter a parking space, the direction of travel of the vehicle at the end point (tire direction, steering angle) does not necessarily have to be parallel to the parking space; that is, a clothoid curve as shown in Figure 19 is not necessary, and the driving trajectory may end as a circular arc. Furthermore, for entry into or exit from a public road as shown in Figure 40, the edge of the facility entrance facing the public road (the edge of the area between the public road and the facility where vehicles can pass) is considered the edge of the lane, and the aforementioned driving trajectory is generated accordingly. Also, for turning sections when entering or exiting the facility from a public road, it is necessary to stop before entering the sidewalk, so the driving trajectory is designed assuming a stop before the turn. The same applies to turning sections where a turn is made at an intersection with a stop line.

[0196] Furthermore, as shown in Figure 41, the following trajectories can be formed by connecting two vectors (start vector and end vector) set at any two points: (A) a combination of a circular arc trajectory (which may include a clothoid curve, the same applies hereafter) and straight trajectories connected before and after it; (B) a combination of two circular arc trajectories; (C) a combination of two circular arc trajectories with different rotations and a straight trajectory connected between them; and (D) a combination of two circular arc trajectories with the same rotation and a straight trajectory connected between them. In the embodiment described above, only (A) is generated as a candidate trajectory connecting the start vector and the end vector, but if trajectories (B) to (D) can be generated, trajectories (B) to (D) may also be generated as candidates for trajectories. Then, in S63, S82, S106, and S126, the cost of each candidate trajectory may be compared and the final recommended trajectory may be selected.

[0197] As described in detail above, the navigation device 1 and the computer program executed by the navigation device 1 according to this embodiment acquire the planned route the vehicle will travel (S1), acquire obstacle information regarding obstacles present on the planned route (S26), and if the planned route includes a turning section in which the vehicle turns, the vehicle's orientation when it reaches the start and end points of the turning section is set based on the planned route (S51, S71, S91, S111), and, on the condition that the vehicle's orientation when it reaches the start and end points of the turning section is the set orientation, the system uses the obstacle information to generate a recommended driving trajectory that avoids obstacles in the turning section and is suitable for the vehicle (S37-S42), and provides driving assistance for the vehicle based on the generated driving trajectory (S9, S10). In particular, when generating a driving trajectory that avoids obstacles in a turning section, it is possible to prevent unnatural behavior of the vehicle at at least one of the start or end points of the turning section and to generate a recommended driving trajectory for the vehicle that suppresses sudden speed changes and lateral acceleration. As a result, it becomes possible to implement appropriate driving assistance that does not place a burden on the vehicle's occupants. Furthermore, if the turning section is a section where the vehicle travels on a curved road while turning, it is determined whether or not the obstacle is located in a position that overlaps with the center line of the lane the vehicle is scheduled to travel in (S43). If the obstacle is located in a position that overlaps with the center line, the system uses the center line as a reference and generates a driving trajectory that does not overlap with the obstacle in the overlapping section of the center line that includes the area overlapping with the obstacle, and this modified trajectory is generated as the driving trajectory recommended for the vehicle (S44). This makes it possible to generate a driving trajectory that avoids the obstacle with minimal vehicle movement while traveling near the center line of the lane the vehicle is scheduled to travel in. Furthermore, if the turning section is a section where the vehicle travels on a curved road while turning, it is determined whether the obstacle is located in a position that overlaps with the center line of the lane the vehicle is scheduled to travel in (S43). If the obstacle is located in a position that does not overlap with the center line, the system uses the standard driving trajectory, which is the recommended driving trajectory for the vehicle in the turning section generated without considering the obstacle, as a reference, and modifies the overlapping section within the standard driving trajectory that includes the area overlapping with the obstacle so that the trajectory does not overlap with the obstacle. This modified driving trajectory is then generated as the recommended driving trajectory for the vehicle (S45). This makes it possible to generate a driving trajectory that avoids the obstacle with minimal vehicle movement while traveling near the driving trajectory that would be recommended if there were no obstacle. Furthermore, a start vector specifying the vehicle's position and direction at the start of the turning section and an end vector specifying the vehicle's position and direction at the end of the turning section are obtained (S92, S112). The overlapping section is divided into multiple sections, and candidate passing points are set at the boundaries of the divided sections. A travel trajectory is then generated that passes from the start vector through the candidate passing points at the section boundaries to the end vector in the direction of each vector, and is recommended for the vehicle's travel (S102, S122). This makes it possible to generate a travel trajectory that does not overlap with obstacles in the overlapping section and in which the vehicle's direction is recommended when reaching the start and end points of the turning section. Furthermore, multiple candidate waypoints are set at the boundaries of multiple sections (S100, S120), and a travel path is generated for each candidate waypoint as a travel path candidate, passing through the candidate waypoints at the section boundaries from the start vector to the end vector in the direction of each vector (S105, S125). The multiple travel path candidates generated for each candidate waypoint are compared, and the travel path candidate that does not overlap with obstacles and is determined to be the most recommended for vehicle travel is selected (S107, S127). A travel path recommended for vehicle travel is generated using the selected travel path candidate. This makes it possible to propose multiple travel path candidates that do not overlap with obstacles in overlapping sections, and to select the most recommended travel path from among the proposed travel path candidates. The system calculates the cost for each of the multiple candidate routes generated for each candidate waypoint, compares the calculated costs, and selects the route that does not overlap with obstacles and is deemed the most recommended route for the vehicle (S107, S127). Therefore, in overlapping sections, it becomes possible to select the most recommended route by comparing the costs among the route candidates that do not overlap with obstacles. Multiple start vectors are obtained that specify the vehicle's position and direction at the start of the turning section, and multiple end vectors are obtained that specify the vehicle's position and direction at the end of the turning section (S74). A travel trajectory passing through each vector in the direction of each vector from the start vector to the end vector is generated as a candidate travel trajectory for each combination of start vector and end vector (S75~S81). From the generated candidate travel trajectories, the candidate travel trajectory that does not overlap with obstacles and is determined to be the most recommended for vehicle travel is selected (S83). A recommended travel trajectory for vehicle travel is generated using the selected candidate travel trajectory. By obtaining multiple candidate start vectors and end vectors, it becomes possible to generate a large number of candidate travel trajectories that pass through each vector in the direction of each vector, and from among them, it becomes possible to select a travel trajectory that can avoid obstacles.

[0198] It should be noted that the present invention is not limited to the embodiments described above, and various improvements and modifications are possible without departing from the spirit of the invention. For example, in this embodiment, the vehicle's orientation upon arrival at both the start and end points of the turning section is set (S51, S71, S91, S111), but the vehicle's orientation upon arrival at only one of the start or end points of the turning section may also be set. For example, when generating the trajectory of the turning section with the vehicle's current position as the start point of the turning section, it is sufficient to set the vehicle's orientation upon arrival at only the end point of the turning section. Alternatively, the vehicle's orientation upon arrival at points other than the start and end points of the turning section (e.g., clipping point 85 or intermediate points) may also be set.

[0199] In this embodiment, the center line 81 and the moving average line 82 are identified based on map information, and the presence of a curve is identified by comparing the center line 81 and the moving average line 82 (S34). However, the presence of a curve may also be identified by performing image recognition processing on an image captured by an external camera, for example.

[0200] Furthermore, in this embodiment, the center line 81 is the center line of the lane in which the vehicle travels, but for single-lane roads or roads without lane divisions, it may be the center line of the road.

[0201] Furthermore, in this embodiment, multiple possible trajectories for the turning section are generated, and the cost of each generated trajectory is compared to determine the final recommended trajectory. However, it is also possible to generate the trajectory for the turning section using only one most recommended pattern, taking into account the shape of the lane on which the vehicle will travel.

[0202] Furthermore, in this embodiment, vehicle control is performed to drive according to the generated driving trajectory after the trajectory has been generated (S9, S10), but the processing related to vehicle control from S9 onward can be omitted. For example, the navigation device 1 may be a device that guides the user along a recommended driving trajectory without performing vehicle control based on the driving trajectory.

[0203] Furthermore, in this embodiment, lane networks and parking lot networks are generated using high-precision map information 16 and facility information 17 (S23). However, it is also possible to store each network covering roads and parking lots nationwide in advance in a database and read them from the database as needed.

[0204] Furthermore, in this embodiment, the high-precision map information held by the server device 4 includes both information on the road lane shape (road shape and curvature per lane, lane width, etc.) and information on the lane markings drawn on the road (center line of the roadway, lane boundary lines, outer line of the roadway, guidance lines, etc.). However, it may also include only information on lane markings, or only information on the road lane shape. For example, even if only information on lane markings is included, it is possible to estimate information equivalent to information on the road lane shape based on the information on lane markings. Also, even if only information on the road lane shape is included, it is possible to estimate information equivalent to information on lane markings based on the information on the road lane shape. Furthermore, "information on lane markings" may be information that identifies the type and arrangement of the lane markings themselves, information that identifies whether or not lane changes are possible between adjacent lanes, or information that directly or indirectly identifies the shape of the lanes.

[0205] Furthermore, in this embodiment, as a means of reflecting the dynamic trajectory in the static trajectory, a portion of the static trajectory is replaced with the dynamic trajectory (S7). However, instead of replacement, the trajectory may be modified to bring the static trajectory closer to the dynamic trajectory.

[0206] Furthermore, in this embodiment, the vehicle control ECU 40 has been described as controlling all of the vehicle operations related to the vehicle's behavior, namely accelerator operation, brake operation, and steering operation, as an automated driving support system for driving automatically without user operation. However, automated driving support may also be defined as the vehicle control ECU 40 controlling at least one of the vehicle operations related to the vehicle's behavior, namely accelerator operation, brake operation, and steering operation. On the other hand, manual driving by user operation is described as the user performing all of the vehicle operations related to the vehicle's behavior, namely accelerator operation, brake operation, and steering operation.

[0207] Furthermore, the driving assistance of the present invention is not limited to automated driving assistance related to the automated driving of a vehicle. For example, it is also possible to provide driving assistance by displaying the static driving trajectory generated in S3 and the dynamic driving trajectory generated in S6 on the navigation screen, and by providing guidance using voice or screen (e.g., guidance for lane changes, guidance for recommended vehicle speed, etc.). Alternatively, the static driving trajectory and dynamic driving trajectory may be displayed on the navigation screen to assist the user's driving operations.

[0208] Furthermore, in this embodiment, the navigation device 1 is configured to execute the automated driving support program (Figure 5), but it may also be configured to be executed by an in-vehicle device other than the navigation device 1 or the vehicle control ECU 40. In that case, the in-vehicle device or the vehicle control ECU 40 is configured to acquire the vehicle's current position, map information, etc., from the navigation device 1 or the server device 4. Moreover, the server device 4 may execute some or all of the steps of the automated driving support program (Figure 5). In that case, the server device 4 corresponds to the driving support device of this application.

[0209] Furthermore, the present invention can be applied not only to navigation devices but also to mobile phones, smartphones, tablet devices, personal computers, etc. (hereinafter referred to as "mobile devices, etc."). It can also be applied to systems consisting of a server and mobile devices, etc. In that case, each step of the above-described automated driving support program (see Figure 5) may be performed by either the server or the mobile devices, etc. However, when applying the present invention to mobile devices, etc., the vehicle capable of performing automated driving support and the mobile devices, etc. must be connected in a way that allows for communication (whether wired or wireless). [Explanation of Symbols]

[0210] 1…Navigation device (driving assistance device), 2…Driving assistance system, 3…Information distribution center, 4…Server device, 5…Vehicle, 16…High-precision map information, 33…Navigation ECU, 40…Vehicle control ECU, 51…CPU, 83…Start vector (starting point of turning section), 84…End vector (ending point of turning section), 85…Clipping point, 96…First driving trajectory, 97…Second driving trajectory, 98…Third driving trajectory, 125…Guideline (centerline of lane), 126…Obstacle, 127…Moving average of guideline, 131…Guideline (reference driving trajectory)

Claims

1. A means for acquiring the planned route on which a vehicle will travel, A means for acquiring turning sections in which a vehicle turns while traveling along the aforementioned planned route, Obstacle information acquisition means for acquiring obstacle information regarding obstacles present on the aforementioned planned travel route, Direction setting means for setting the direction of the vehicle when it reaches a target point that includes at least one of the start and end points of the turning section based on the planned route, A trajectory generation means generates a trajectory that avoids the obstacles in the turning section and is recommended for the vehicle, provided that the vehicle's direction upon reaching the target point is the direction set by the direction setting means, and the vehicle's direction upon reaching the target point is the direction set by the direction setting means. The vehicle includes a driving support means that provides driving support for the vehicle based on the driving trajectory generated by the aforementioned driving trajectory generating means, The aforementioned track trajectory generating means is If the aforementioned turning section is a section where a vehicle travels on a curved road while turning, Determine whether the obstacle is located in a position that coincides with the center line of the lane the vehicle is scheduled to travel in. If the aforementioned obstacle is located in a position that coincides with the center line, A driving support device that generates a driving trajectory that is recommended for the vehicle, by using the aforementioned center line as a reference and modifying the overlapping section within the center line, which includes the area overlapping with the obstacle, so that the trajectory does not overlap with the obstacle.

2. A means for acquiring the planned route on which a vehicle will travel, A means for acquiring turning sections in which a vehicle turns while traveling along the aforementioned planned route, Obstacle information acquisition means for acquiring obstacle information regarding obstacles present on the aforementioned planned travel route, Direction setting means for setting the direction of the vehicle when it reaches a target point that includes at least one of the start and end points of the turning section based on the planned route, A trajectory generation means generates a trajectory that avoids the obstacles in the turning section and is recommended for the vehicle, provided that the vehicle's direction upon reaching the target point is the direction set by the direction setting means, and the vehicle's direction upon reaching the target point is the direction set by the direction setting means. The vehicle includes a driving support means that provides driving support for the vehicle based on the driving trajectory generated by the aforementioned driving trajectory generating means, The aforementioned track trajectory generating means is If the aforementioned turning section is a section where a vehicle travels on a curved road while turning, Determine whether the obstacle is located in a position that coincides with the center line of the lane the vehicle is scheduled to travel in. If the aforementioned obstacle is located in a position that does not overlap with the center line, A driving support device that generates a driving track that is recommended for vehicle travel, based on a reference driving track which is a driving track recommended for vehicle travel in the turning section generated without considering the aforementioned obstacles, and modifies the overlapping section within the reference driving track, which includes the area overlapping with the aforementioned obstacles, so that the track does not overlap with the obstacles, and generates a driving track that is recommended for vehicle travel.

3. A starting vector acquisition means acquires a starting vector that identifies the position and direction of the vehicle at the starting point of the turning section based on the direction of the vehicle set by the direction setting means, The system includes an end vector acquisition means that acquires an end vector that specifies the position and direction of the vehicle at the end of the turning section, based on the direction of the vehicle set by the direction setting means, The aforementioned track trajectory generating means is The overlapping section is divided into multiple sections, At the boundaries of the aforementioned divided sections, candidate passing points are set for the vehicle to pass through. The driving support device according to claim 1 or claim 2, which generates a driving trajectory that passes through the candidate passing points at the boundary of the section from the starting vector to the ending vector in the direction of each vector, as a driving trajectory for which the vehicle is recommended to travel.

4. The aforementioned track trajectory generating means is Multiple candidate passing points are set at the boundaries of the aforementioned multiple sections, A travel path is generated for each candidate passing point as a candidate travel path, starting from the start vector, passing through the candidate passing points at the boundary of the section, and continuing towards the end vector in the direction of each vector. The driving support device according to claim 3, which compares a plurality of candidate driving trajectories generated for each candidate waypoint, selects a candidate driving trajectory that does not overlap with obstacles and is determined to be the most recommended route for the vehicle, and generates a recommended driving trajectory for the vehicle using the selected candidate driving trajectory.

5. The aforementioned track trajectory generating means is For each of the candidate waypoints mentioned above, the cost is calculated for the multiple candidate travel paths generated. The driving assistance device according to claim 4, which compares the calculated costs and selects from among the plurality of candidate driving paths a candidate driving path that does not overlap with obstacles and is determined to be the most recommended for vehicle travel.

6. Based on the vehicle orientation set by the orientation setting means, a start vector acquisition means acquires multiple start vectors that specify the position and orientation of the vehicle at the starting point of the turning section, The system includes an end vector acquisition means that acquires multiple end vectors that specify the position and direction of the vehicle at the end of the turning section, based on the direction of the vehicle set by the direction setting means. The aforementioned track trajectory generating means is A travel path passing through the direction of each vector from the start vector to the end vector is generated as a candidate travel path for each combination of the start vector and the end vector. The driving support device according to claim 1 or 2, which selects a candidate driving path from among the generated candidate driving paths that does not overlap with obstacles and is determined to be the most recommended driving path for the vehicle, and generates a driving path that is recommended for the vehicle using the selected candidate driving path.

7. Computers, A means for acquiring the planned route on which a vehicle will travel, A means for acquiring turning sections in which a vehicle turns while traveling along the aforementioned planned route, Obstacle information acquisition means for acquiring obstacle information regarding obstacles present on the aforementioned planned travel route, Direction setting means for setting the direction of the vehicle when it reaches a target point that includes at least one of the start and end points of the turning section based on the planned route, A trajectory generation means generates a trajectory that avoids the obstacles in the turning section and is recommended for the vehicle, provided that the vehicle's direction upon reaching the target point is the direction set by the direction setting means, and the vehicle's direction upon reaching the target point is the direction set by the direction setting means. A driving support means that provides driving support for a vehicle based on the driving trajectory generated by the aforementioned driving trajectory generating means, It is a computer program that makes it function, The aforementioned track trajectory generating means is If the aforementioned turning section is a section where a vehicle travels on a curved road while turning, Determine whether the obstacle is located in a position that coincides with the center line of the lane the vehicle is scheduled to travel in. If the aforementioned obstacle is located in a position that coincides with the center line, A computer program that generates a driving trajectory that is recommended for the vehicle, by modifying the overlapping section within the center line, which includes the area overlapping with the obstacle, so that the trajectory does not overlap with the obstacle.

8. Computers, A means for acquiring the planned route on which a vehicle will travel, A means for acquiring turning sections in which a vehicle turns while traveling along the aforementioned planned route, Obstacle information acquisition means for acquiring obstacle information regarding obstacles present on the aforementioned planned travel route, Direction setting means for setting the direction of the vehicle when it reaches a target point that includes at least one of the start and end points of the turning section based on the planned route, A trajectory generation means generates a trajectory that avoids the obstacles in the turning section and is recommended for the vehicle, provided that the vehicle's direction upon reaching the target point is the direction set by the direction setting means, and the vehicle's direction upon reaching the target point is the direction set by the direction setting means. A driving support means that provides driving support for a vehicle based on the driving trajectory generated by the aforementioned driving trajectory generating means, It is a computer program that makes it function, The aforementioned track trajectory generating means is If the aforementioned turning section is a section where a vehicle travels on a curved road while turning, Determine whether the obstacle is located in a position that coincides with the center line of the lane the vehicle is scheduled to travel in. If the aforementioned obstacle is located in a position that does not overlap with the center line, A computer program that generates a recommended driving path for a vehicle, based on a reference driving path which is the driving path recommended for a vehicle in the turning section generated without considering the aforementioned obstacles, and modifies the overlapping section within the reference driving path, which includes the area overlapping with the aforementioned obstacles, so that the driving path does not overlap with the obstacles.