Driving assistance systems and computer programs

The driver assistance system addresses the issue of vehicle orientation at turning sections by generating a recommended driving trajectory, ensuring smooth and appropriate driving support by preventing unnatural behavior and sudden speed changes.

JP7868519B2Active Publication Date: 2026-06-02AISIN CORP

Patent Information

Authority / Receiving Office
JP · JP
Patent Type
Patents
Current Assignee / Owner
AISIN CORP
Filing Date
2023-01-30
Publication Date
2026-06-02

AI Technical Summary

Technical Problem

Existing automatic driving support systems fail to consider the vehicle orientation at the start and end of turning sections, leading to unnatural vehicle behavior, sudden speed changes, and lateral acceleration.

Method used

A driver assistance system that acquires planned routes, identifies turning sections, and sets vehicle directions at start and end points to generate a recommended driving trajectory, preventing unnatural behavior and suppressing sudden speed changes and lateral acceleration.

Benefits of technology

The system generates a recommended driving trajectory that prevents unnatural vehicle behavior and suppresses sudden speed changes and lateral acceleration, providing smooth and appropriate driving support.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 0007868519000001
    Figure 0007868519000001
  • Figure 0007868519000002
    Figure 0007868519000002
  • Figure 0007868519000003
    Figure 0007868519000003
Patent Text Reader

Abstract

To provide a drive support device and a computer program which enable a traveling track, on which a vehicle is suppressed from behaving inappropriately when traveling on a turning section, to be created as a traveling track on which the vehicle is recommend to travel.SOLUTION: A drive support device is configured to: obtain a scheduled traveling route on which a vehicle is to travel; when the schedule traveling route includes a turning section on which the vehicle travels while turning when traveling on the scheduled traveling route, set an orientation of the vehicle in which the vehicle arrives at starting point and an ending point of the turning section on the basis of the scheduled traveling route; create a traveling track on which the vehicle is recommended to travel in the turning section, provided that the orientation of the vehicle arriving at the starting point and the ending point in the turning section matches the set orientation; and perform drive support of the vehicle on the basis of the created traveling track.SELECTED DRAWING: Figure 12
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention relates to a driving support device and a computer program for assisting 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 operations has been newly proposed. In the automatic driving support system, for example, the current position of the vehicle, the lane in which the vehicle is traveling, and the positions of other surrounding vehicles are detected at any time, and vehicle control such as steering, drive source, and brake is automatically performed so as to travel along a preset route.

[0003] Further, when performing driving by the above-described automatic driving support or performing various driving supports for other vehicles, a travel trajectory recommended for traveling 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-described travel trajectory for a section where the vehicle travels with turning (hereinafter referred to as a turning section), such as a road having a curve shape, for example, in Japanese Patent Application Laid-Open No. 2017-100652, 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 portion than the trajectory along the center line of the road has been proposed.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0005] However, in the above-mentioned Patent Document 1, the driving trajectory is generated by correcting the radius of curvature to be larger for a trajectory that follows the centerline of the road, and the driving trajectory does not take into account the orientation of the vehicle at the start and end of the turning section. Therefore, when driving along the driving trajectory, the orientation of the vehicle at the start and end of the turning section may not be the recommended orientation. For example, in the example shown in Figure 25, when driving along the driving trajectory 151 in a turning section consisting of a curved road, the orientation (angle) of the vehicle body at the end of the turning section is not aligned with the direction of the straight road that follows, and the steering is not in a neutral position. Therefore, a corrected trajectory 152 is required to correct the orientation of the vehicle body 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. Note that Figure 25 shows the end of the turning section and the connection point of the road that follows, but similar problems may occur at the start of the turning section and the connection point of the road before it.

[0006] The present invention was made to solve the aforementioned problems of the conventional method, and in the case of generating a travel trajectory when traveling through a turning section, At least one or both of the start and end points of the turning section The objective is to provide a driver assistance system and computer program that prevents unnatural vehicle behavior and enables the generation of a recommended driving trajectory for the vehicle, suppressing sudden speed changes and lateral acceleration. [Means for solving the problem]

[0007] To achieve the above objective, the present invention First The driver assistance system includes a means for acquiring a planned route on which the vehicle will travel, a means for acquiring a turning section on which the vehicle will turn while traveling along the planned route, and a means for acquiring the start and end points of the turning section based on the planned route. point The vehicle's direction upon arrival Each The means for setting the direction, A starting vector acquisition means that acquires a starting vector that specifies 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, and an ending vector acquisition means that acquires an ending vector that specifies the position and direction of the vehicle at the ending point of the turning section based on the direction of the vehicle set by the direction setting means, and a driving trajectory that passes through in the direction of each vector from the starting vector to the ending vector, The recommended driving path for the vehicle in the aforementioned turning section as The system includes a means for generating a driving trajectory and a means for providing driving assistance for a vehicle based on the driving trajectory generated by the driving trajectory generation means. Furthermore, the second driving support device according to the present invention includes: a driving plan acquisition means for acquiring a planned driving route on which a 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; a direction setting means for setting 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; a driving trajectory generation means for generating a driving trajectory on which the vehicle is recommended to travel in the turning section, provided that the direction of the vehicle when reaching the target point is the direction set by the direction setting means; and a driving support means for providing driving support for the vehicle based on the driving trajectory generated by the driving trajectory generation means. The driving support means divides the planned driving route into a plurality of sections based on the driving manner of the vehicle when traveling according to the planned driving route, stores information that identifies the driving trajectory generated by the driving trajectory generation means for the section corresponding to the turning section among the plurality of sections, and provides driving support for the vehicle based on the stored information. 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 First The computer program is a program that generates support information used for driving assistance implemented in a vehicle. Specifically, the computer includes a means for acquiring the planned route the vehicle will travel, a means for acquiring turning sections in which the vehicle will turn while traveling along the planned route, and a means for acquiring the start and end points of the turning sections based on the planned route. point The vehicle's direction upon arrival Each The means for setting the direction, A starting vector acquisition means that acquires a starting vector that specifies 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, and an ending vector acquisition means that acquires an ending vector that specifies the position and direction of the vehicle at the ending point of the turning section based on the direction of the vehicle set by the direction setting means, and a driving trajectory that passes through in the direction of each vector from the starting vector to the ending vector, The recommended driving path for the vehicle in the aforementioned turning section as The system functions as a means for generating a driving trajectory and a means for assisting the operation of a vehicle based on the driving trajectory generated by the driving trajectory generation means. Furthermore, the second computer program according to the present invention is a program that generates support information used for driving assistance implemented in a vehicle. Specifically, the computer is configured to function as: a planned route acquisition means for acquiring a planned 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 along 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 is recommended for the vehicle in the turning section, 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. Furthermore, the driving support means divides the planned route into a plurality of sections based on the driving manner of the vehicle when traveling along the planned route, stores information that identifies the driving trajectory generated by the driving trajectory generation means for the section corresponding to the turning section among the plurality of sections, and provides driving support for the vehicle based on the stored information. [Effects of the Invention]

[0009] The present invention having the above configuration FirstAccording to the driving support device and the computer program, when generating a driving trajectory during a turning section, the starting point of the turning section and end point is prevented from causing unnatural behavior in the vehicle, and it becomes possible to generate a driving trajectory recommended for a vehicle with suppressed sudden speed changes and lateral acceleration. As a result, it becomes possible to perform appropriate driving support that does not impose a burden on the vehicle occupants. Furthermore, the second driver assistance device and computer program make it possible to generate a recommended driving trajectory for the vehicle when generating a driving trajectory when traveling through a turning section, preventing unnatural behavior of the vehicle at at least one of the start or end points of the turning section, and suppressing sudden speed changes and lateral acceleration. As a result, it becomes possible to implement appropriate driver assistance that does not burden the vehicle's occupants.

Brief Description of the Drawings

[0010] [Figure 1] It is a schematic configuration diagram showing the driving support system according to this embodiment. [Figure 2] It is a block diagram showing the configuration of the driving support system according to this embodiment. [Figure 3] It is a block diagram showing the navigation device according to this embodiment. [Figure 4] It is a flowchart of the automatic driving support program according to this embodiment. [Figure 5] It is a diagram showing an area where high-precision map information is acquired. [Figure 6] It is a diagram explaining the method of calculating the dynamic driving trajectory. [Figure 7] It is a flowchart of the sub-processing program of the static driving trajectory generation process. [Figure 8] It is a diagram showing an example of the planned driving route of the vehicle. [Figure 9] It is a diagram showing an example of the lane network constructed for the planned driving route shown in FIG. 8. [Figure 10] It is a flowchart of the sub-processing program of the driving trajectory calculation process in the turning section. [Figure 11] It is a diagram showing an example of a turning section including a road with a curve shape. [Figure 12] It is a diagram showing an example of the vehicle orientation set for the starting point and the ending point of the turning section. [Figure 13]This diagram explains how to set clipping points. [Figure 14] This diagram illustrates an example of using multiple start and end vectors. [Figure 15] This diagram illustrates the case where the arc with the largest radius of curvature passing through the direction of travel of each vector, along with the start and end vectors, is contained within the lane in which the vehicle is traveling. [Figure 16] This diagram illustrates the case where the arc with the largest radius of curvature passing through the direction of travel of the start and end vectors is not contained within the lane in which the vehicle is traveling. [Figure 17] This figure shows candidate trajectories generated for a turning section. [Figure 18] This figure shows the method for generating the second and third travel tracks. [Figure 19] This diagram shows an example of a correction to smooth the running trajectory. [Figure 20] This figure shows an example of storing information about the generated static track. [Figure 21] 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 22] 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 23] 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 24] This diagram shows an example of a trajectory connecting two vectors (start vector and end vector) set at any two points. [Figure 25] 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. The server device 4 then distributes high-precision map information and facility information in response to requests from the navigation device 1, and the navigation device 1 uses the high-precision map information and facility information distributed from the server device 4 to generate various support information related to autonomous driving assistance, as described later. Note that the high-precision map information is basically limited to roads (links) and their surroundings, but it may also include areas other than those surrounding roads.

[0019] 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.

[0020] 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.

[0021] Next, the configuration of the server device 4 in the driver assistance system 2 will be explained in more detail using Figure 2. As shown in Figure 2, the server device 4 comprises a server control unit 11, a server-side map DB 12 as an information recording means connected to the server control unit 11, a high-precision map DB 13, a facility DB 14, and a server-side communication device 15.

[0022] 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.

[0023] 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.

[0024] 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).

[0025] 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. For roadways, it includes 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 that restrict vehicle movement (restrictions) such as speed limits on the roadway, it includes restriction information that identifies the type and location of the restrictive entities. For facilities other than parking lots, it includes information that identifies the floor map of the facility. The floor map includes information that identifies the location of entrances and exits, corridors, stairs, elevators, and escalators, for example. In the case of a mixed-use commercial facility with multiple tenants, it also includes information that identifies the location of each tenant. The facility information 17 may also be information generated by creating a 3D model of the parking lot or facility. Furthermore, the facility DB14 also includes connection information 18 that shows the connection relationship between the lanes included in the access road facing the entrance / exit of the parking lot and the entrance / exit of the parking lot, and road surface shape information 19 that identifies the area where vehicles can pass between the access road and the entrance / exit of the parking lot.

[0026] 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.

[0027] On the other hand, the server-side communication device 15 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 is also possible to receive traffic information consisting of various types of information such as congestion information, regulation information, and traffic accident information transmitted from the Internet network or traffic information centers, such as VICS (registered trademark: Vehicle Information and Communication System) centers.

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

[0029] As shown in Figure 3, 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 to the user 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, 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 an information center such as a probe center or a VICS center. Furthermore, the navigation device 1 is connected to an external camera 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.

[0030] 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.

[0031] 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.

[0032] 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.

[0033] On the other hand, the cache 46 is a storage means that stores high-precision map information 16, facility information 17, connection information 18, and off-road shape information 19 that have been previously distributed from the server device 4. The storage period can be set as appropriate, but 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, and off-road shape information 19 stored in the cache 46 to generate various support information related to automated driving assistance. Details will be described later.

[0034] 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 4) 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 direction setting means sets the direction of the vehicle when the vehicle reaches a target point that includes at least one of the start point and end point of the turning section, based on the planned driving route. The trajectory generation means generates a recommended trajectory for the vehicle in a turning section, provided that the vehicle's orientation upon reaching the target point is the orientation set by the orientation setting means. The driving support means provides driving support for the vehicle based on the trajectory generated by the trajectory generation means.

[0035] 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.

[0036] 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.

[0037] 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.

[0038] 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.

[0039] 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, and off-road shape information 19, which have been searched by the server device 4, to and from the server device 4.

[0040] 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 vehicle's front bumper 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 performs image processing on the captured images to detect 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. The external camera 39 may also be configured to be positioned at the rear or side of the vehicle, in addition to the front. Furthermore, 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 for detecting obstacles.

[0041] 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.

[0042] 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.

[0043] 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 4. Figure 4 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 4, 7 and 10 below are stored in the RAM 52 and ROM 53 of the navigation device 1 and are executed by the CPU 51.

[0044] 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.

[0045] 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.

[0046] 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.

[0047] 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.

[0048] 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 above-mentioned driving route. Note that other search methods besides Dijkstra's algorithm may be used as the route search method. Also, the driving route search in S1 may be performed by the navigation device 1 instead of the server device 4.

[0049] 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.

[0050] Here, the high-precision map information 16 is divided into rectangular shapes (e.g., 500m x 1km) as shown in Figure 5 and stored in the high-precision map DB 13 of the server device 4. Therefore, for example, if a route 61 is acquired as the vehicle's travel route as shown in Figure 5, the high-precision map information 16 is acquired for areas 62 to 65 that include the 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.

[0051] 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.

[0052] In addition, in S2, the CPU 51 also similarly 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 parks and the entrance / exit of the parking lot, and road surface shape information 19 that identifies the area where vehicles can pass between the access road and the entrance / exit of the parking lot where the user parks.

[0053] Subsequently, in S3, the CPU 51 executes the static driving trajectory generation process (Figure 7) 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. 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) on which the road conditions around the vehicle can be detected by the external camera 39 or other sensors.

[0054] 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.).

[0055] 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.

[0056] 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). In addition, 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 to detect factors that may affect the vehicle's movement.

[0057] Alternatively, for example, the real-time location of each vehicle traveling on roads nationwide may be managed by an external server, and the CPU 51 may obtain the locations of other vehicles located around its own vehicle from the external server and perform the determination process in S5.

[0058] 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.

[0059] In S6, the CPU 51 generates a new dynamic trajectory to avoid or follow the "factors affecting the vehicle's movement" detected in S5, and return 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 6. 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 (or traveling parallel to) 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.

[0060] To explain the calculation method of the dynamic driving trajectory 67 shown in Figure 6 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 an 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.

[0061] Next, in S7, the CPU 51 reflects the newly generated dynamic trajectory in S6 onto 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 selects the trajectory with the lowest cost. As a result, a portion of the static trajectory will be replaced with the dynamic trajectory as needed. However, in some situations, the dynamic trajectory may not be replaced, meaning that even if the dynamic trajectory is reflected, it may not change from the static trajectory generated in S3. Furthermore, if the dynamic trajectory and the static trajectory are the same trajectory, even if replacement occurs, it may not change from the static trajectory generated in S3.

[0062] 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.

[0063] 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.

[0064] 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).

[0065] 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.

[0066] 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 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.

[0067] 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.

[0068] 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.

[0069] Next, the subprocessing of the static trajectory generation process executed in S3 will be explained with reference to Figure 7. Figure 7 is a flowchart of the subprocessing program for the static trajectory generation process.

[0070] 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.

[0071] 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).

[0072] 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.

[0073] 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 8. The planned route shown in Figure 8 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 8, 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 9 shows a lane network constructed for sections where such lane changes are possible.

[0074] As shown in Figure 9, 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 and exit points of intersections and the points where lanes increase or decrease. A node point (hereinafter referred to as a lane node) 75 is set for each lane located at the boundary of each divided section. Furthermore, links (hereinafter referred to as lane links) 76 are set to connect the lane nodes 75. Note that, when the lane links 76 do not cross lanes, they are basically set to the center of the lane.

[0075] 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.

[0076] Although Figure 9 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 parking lots, 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.

[0077] 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.

[0078] 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.

[0079] 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).

[0080] Furthermore, the lane cost used in searching for the above route is assigned to each lane link 76. The lane cost assigned to each lane link 76 is based on the length of each lane link 76 or the time required to travel through it. 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 that involve lane changes, a lane change cost (e.g., 50) is added to the above base value. Note that 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.

[0081] 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.

[0082] Next, in S26, the CPU 51 performs the turning section trajectory generation process (Figure 10), 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 in front of the vehicle's direction of travel is to be generated, 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 while 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 occurs will be generated in S27 described later. Furthermore, if the planned driving route includes multiple turning sections, a recommended driving trajectory will be generated for each of the multiple turning sections.

[0083] Subsequently, in S27, the CPU 51 generates a recommended driving trajectory for driving along the recommended route derived in S25, excluding the turning section. For example, for driving trajectories involving lane changes, the CPU 51 sets the lane change locations so that lane changes are not consecutive and are performed as far away from intersections as possible. When generating a driving trajectory for lane changes, the CPU 51 calculates the lateral acceleration (lateral G) generated in the vehicle and ensures that the lateral G does not exceed an upper limit (e.g., 0.2G) that does not interfere with automatic driving assistance or cause discomfort to the vehicle's occupants. The same upper limit (e.g., 0.6m / s) is also set for the rate of change of lateral G per unit time. 3The system 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. For sections that are neither turning sections nor lane changes, the recommended driving trajectory for the vehicle is the trajectory that passes through the center of the lane.

[0084] In S28, the CPU 51 combines the driving trajectories calculated in S26 and S27 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 S28 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.

[0085] Next, the subprocessing for calculating the travel trajectory of the turning section, which is performed in S26, will be explained with reference to Figure 10. Figure 10 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 while turning on a curved road (including cases where the road bends in an arc shape, as well as cases where it bends at a predetermined angle such as a right angle).

[0086] 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.

[0087] Next, in S32, the CPU 51 calculates the centerline of the lane 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 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 also 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.

[0088] Next, in S33, the CPU 51 calculates a moving average line for the lane 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. 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 obtained by averaging the latitude and longitude of 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.

[0089] Furthermore, in S34, the CPU 51 compares the center line calculated in S32 with the moving average line calculated in S33 and detects the range where the center line and the moving average line do not coincide as the range where a curve exists. Here, Figure 11 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 a line that connects the average points (points where the latitude and longitude are averaged, respectively) of five coordinate points, including the two coordinate points before and after each coordinate point set at predetermined intervals along the center line 81. 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 11, there are ranges where the center line 81 and the moving average line 82 do not coincide in places where the road curves in an arc or bends at a predetermined angle. Therefore, in S34, the range where the center line 81 and the moving average line 82 do not coincide is detected as the range where a curve exists.

[0090] 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.

[0091] 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.

[0092] 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. Conversely, 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 S27, where a recommended track is generated for driving along the recommended route derived in S25.

[0093] 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.

[0094] 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.

[0095] First, in S37, 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 12, 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 for turning to the right or left. In other words, the vehicle orientation set in S37 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.

[0096] Next, in S38, 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, which were set in S37.

[0097] 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 defined in S37.

[0098] Figure 11 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 11, 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.

[0099] Subsequently, in S39, 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 13, the nearest point of tangency of the inner boundary line 86 to the moving average line 82 is set as the clipping point 85. Note that, as shown in Figure 11, the moving average line 82 is basically closer to the inner boundary line of the curve than the center line 81, so if the 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 13 assumes the vehicle width is 0. If the vehicle width is to be considered, it is preferable to set the clipping point 85 at a position half the vehicle width towards the center line from the nearest point of contact of the inner lane line 86 on the curve to the moving average line 82, or, taking errors into account, at a position half the vehicle width + α (for example, 30 cm) towards the center line.

[0100] Next, in S40, 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 S38. Furthermore, it generates a new candidate end vector at the end point of the turning section, in addition to the end vector obtained in S38. For example, in the example shown in Figure 14, 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 further predetermined distance (e.g., 1 / 4 or 1 / 6 of the lane width) outward from the initial start vector 84. 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 further predetermined distance (e.g., 1 / 4 or 1 / 6 of the lane width) outward from the initial end vector 84. In the example shown in Figure 14, 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.

[0101] The subsequent processes S41 to S47 are executed for each combination of start vector and end vector obtained in S38 and newly generated in S39. For example, in the example shown in Figure 14, there are 3 start vectors and 3 end vectors, so processes S41 to S47 are executed for all 3 x 3 = 9 possible combinations. After executing processes S41 to S47 for all combinations of start vector and end vector, the process proceeds to S48.

[0102] First, in S41, 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).

[0103] Subsequently, in S42, the CPU 51 determines whether the arc calculated in S41 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.

[0104] If it is determined that the arc calculated in S41 is within the lane in which the vehicle travels between the start vector and the end vector (within the travel area acquired in S31) (S42: YES), the process proceeds to S43. On the other hand, if it is determined that the arc calculated in S41 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) (S42: NO), the process proceeds to S44.

[0105] In S43, the CPU 51 generates a first travel trajectory for the arc between the start vector and the end vector calculated in S41. For example, the example shown in Figure 15 is when the arc 95 calculated in S40 is 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, and the arc 95 is generated as the first travel trajectory. The process then proceeds to S45.

[0106] On the other hand, in S44, the CPU 51 determines that the arc calculated in S41 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 S39, 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 S44 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 16 is an example where the arc 95 calculated in S40 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 turning direction (does not include multiple turning movements).

[0107] Subsequently, in S45, the CPU 51 generates a second travel trajectory to move from the start vector acquired in S38 to the first travel trajectory generated in S43 or S44. Note that, as shown in Figures 15 and 16, if the start vector to be processed is the start vector acquired in S38, the second travel trajectory becomes part of the first travel trajectory, so the processing in S45 is unnecessary. On the other hand, as shown in Figure 17, if the start vector to be processed is not the start vector acquired in S38 (a start vector newly added in S40), a second travel trajectory is generated. For example, in the example shown in Figure 17, 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 processing target, 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 in the direction of travel of the start vector.

[0108] Next, in S46, the CPU 51 generates a third travel trajectory to move from the first travel trajectory generated in S43 or S44 to the end vector acquired in S38. Note that, as shown in Figures 15 and 16, if the end vector to be processed is the end vector acquired in S38, the third travel trajectory becomes part of the first travel trajectory, so the processing in S46 is unnecessary. On the other hand, as shown in Figure 17, if the end vector to be processed is not the end vector acquired in S38 (an end vector newly added in S40), a third travel trajectory is generated. For example, in the example shown in Figure 17, 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 in the direction of travel of the end vector.

[0109] 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 18 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 18, the recommended vehicle trajectory when moving to the right within a lane consists of 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., while 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., while 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., while gradually increasing the curvature), and a fourth clothoid curve 104 that proceeds from the second intermediate point P4 to the end point P5 while gradually returning the steering wheel to the straight direction (i.e., while gradually decreasing the curvature). Furthermore, the lateral movement distance due to clothoid curves 101-104 is defined as the distance overlapping with the first travel trajectory at point P5 for the second travel trajectory, and the distance overlapping with the initial termination vector 84 at point 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 limited to an 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 lane changes. Then, by connecting the calculated clothoid curves 101 to 104, the second and third driving trajectories are calculated.

[0110] Subsequently, in S47, the CPU 51 combines the first travel trajectory generated in S43 or S44, the second travel trajectory generated in S45 (only if a second travel trajectory is generated), and the third travel trajectory generated in S46 (only if a third travel trajectory is generated) to form a single travel trajectory. The travel trajectory generated in S47 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 S37, 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 S37. For example, when a vehicle travels along the trajectory generated in S47, 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 S47 is a trajectory that combines at least two or more trajectories, such as 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.

[0111] Furthermore, in a track consisting only of the first track generated in S43 or S44, there is a problem that the curvature does not match before and after the connection points of the straight and arc tracks because there are no clothoid curves 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 to include a clothoid curve 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 or exit a parking space, or turning sections where the vehicle turns to enter or exit a facility from a public road.

[0112] First, as shown in Figure 19, the radius of curvature R of the circular track 110 included in the candidate track generated in S47 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 clothoid curve is already publicly known, so the details are omitted. 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 19. 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 19, 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, for the candidate track formed by connecting the first track 96, the second track 97, and the third track 98 as shown in Figure 17, the curvature matches before and after the connection point of each track, and also before and after the connection point with the straight tracks before and after it. Therefore, even without making the above-mentioned modifications, a smooth track is obtained in which the change in direction is continuous within a predetermined range.

[0113] Similarly, for each combination of start and end vectors acquired in S38 and newly generated in S39, 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 S48.

[0114] Subsequently, in S48, the CPU 51 calculates the cost of running the vehicle for each of the multiple candidate running trajectories generated in S47, taking into account the vehicle's behavior when running on each trajectory. The cost indicates the suitability of the running trajectory; a smaller cost indicates higher suitability. An example of the cost calculation method in S48 is described below.

[0115] 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

[0116] 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.

[0117] 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.

[0118] Furthermore, regarding (3), the cost is determined by the number of times the steering direction is changed within the driving trajectory. Specifically, the more times the steering direction is changed, the higher the cost calculated, meaning that it is less likely to be selected as a recommended driving trajectory.

[0119] Furthermore, when calculating the cost for a candidate trajectory in S48, 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.).

[0120] Subsequently, in S49, the CPU 51 compares the costs calculated in S48 and selects a recommended driving path from among the multiple driving path candidates generated in S47 for driving through the turning section. Basically, the candidate driving path with the smallest calculated cost is selected as the recommended driving path. Then, the process moves to S27, where recommended driving paths are generated for driving along the recommended route derived in S25 for sections other than the turning section. 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 (S28). Furthermore, the generated static driving path is stored in the flash memory 54 or the like as support information used for automated driving assistance.

[0121] Here, when the generated static driving trajectory is stored in the flash memory 54 or the like as support information for automated driving assistance, as shown in Figure 20, the planned driving route is divided into multiple sections based on the vehicle's driving manner when driving along the planned route, and information is stored to identify the recommended static driving trajectory for each section. For example, Figure 20 shows a case where the vehicle is parked in a parking space in a parking lot as the starting point. Specifically, the planned driving route, which involves exiting the parking space, driving along the road within the parking lot, turning left to enter the road from the parking lot, and then turning right at an intersection, is divided into multiple sections based on the vehicle's driving manner (e.g., driving along the road, changing lanes, turning right at an intersection, etc.), and information is stored to identify the generated static driving trajectory for each section. In particular, for sections that correspond to turning sections, information is stored to identify the driving trajectory selected in S49. For example, in the example shown in Figure 20, "exiting the parking space," "turning right within the parking lot," "turning left when entering the road from the parking lot," and "turning right at an intersection" are turning sections. As shown in Figure 20, for the turning section, information identifying the driving trajectory selected in S49 is stored, such as the shape of the trajectory (including length and change in direction), a flag to determine whether it is a left or right turn, a flag to determine whether it is a forward or backward trajectory, the coordinates and direction of the start and end vectors, the radius of curvature and center coordinates if it includes a circular arc trajectory, and the clothoid coefficient and curvature at the start and end points if it includes a clothoid curve. Then, as shown in Figure 20, the navigation ECU 33 and vehicle control ECU 40 provide various driving assistance based on the stored static driving trajectory.

[0122] 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.

[0123] 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 21, 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 22, 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 23, 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.

[0124] Furthermore, in the case of intersections like the one shown in Figure 21, although there are no lanes within the intersection, the aforementioned driving trajectory is generated by considering road markings such as guide lines (white lines) and diamond-shaped traffic guides (diamond marks) placed in the center of the intersection, as well as structures such as poles, as the edges of the lanes. Furthermore, for entry into or exit from a parking space as shown in Figure 22, the lane markings, as well as the markings separating the parking space, 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 22. 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 23, 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. Additionally, if the presence of an obstacle can be identified, it may be required that the driving trajectory does not overlap with the obstacle. 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.

[0125] Furthermore, as shown in Figure 24, possible trajectories connecting two vectors (start vector and end vector) set at any two points include (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 candidate trajectories. Then, in S48, the cost of each candidate trajectory may be compared and the final recommended trajectory may be selected.

[0126] 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), 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 (S37), and a recommended driving trajectory for the vehicle in the turning section is generated (S38-S49) on the condition that the vehicle's orientation when it reaches the start and end points of the turning section is the set orientation, and the driving assistance for the vehicle is provided based on the generated driving trajectory (S9, S10). As a result, when generating a driving trajectory when traveling through a turning section, it is possible to prevent the vehicle from behaving unnaturally at the start and end points of the turning section and to generate a recommended driving trajectory for the vehicle that suppresses sudden speed changes and lateral acceleration. Furthermore, by obtaining a start vector that specifies the vehicle's position and orientation at the start of the turning section (S38), and obtaining an end vector that specifies the vehicle's position and orientation at the end of the turning section (S38), and generating a travel trajectory that passes through the direction of each vector from the start vector to the end vector as a recommended travel trajectory for the vehicle, it becomes possible to generate a travel trajectory in which the vehicle's orientation when reaching the start and end of the turning section is the set orientation. Furthermore, especially when the turning section is a section where a vehicle travels on a curved road while turning, the turning section is acquired using information about the road markings or information about the curvature of the road, and the direction of the vehicle when it reaches the start and end points of the turning section is set to the direction of travel on the road at the target point (S37). This prevents unnatural behavior at the start point of the turning section in order to align with the direction of travel on the travel trajectory. Similarly, it prevents unnatural behavior at the end point of the turning section in order to align with the subsequent direction of travel on the road. Furthermore, since the system generates a driving trajectory in which the change in direction is continuous within a predetermined range as the recommended driving trajectory for the vehicle (S38-S49), it becomes possible 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. Furthermore, the generated track is a combination of at least two tracks, including a straight track, a circular arc track, and a clothoid curve track, and the distance and azimuth change of each track are specified. Therefore, by appropriately combining the track to match the shape of the area where the vehicle can travel in the turning section, it is possible to generate a recommended track for that turning section. Furthermore, the planned route is divided into multiple sections based on the vehicle's driving pattern when traveling along the planned route, and information identifying the generated trajectory for the section corresponding to the turning section is stored. Based on the stored information, the vehicle's driving assistance is provided (S9, S10). This makes it possible to provide appropriate driving assistance for each vehicle's driving pattern based on the stored information.

[0127] 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 (S37), 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 point) may also be set.

[0128] 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.

[0129] 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.

[0130] 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.

[0131] 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.

[0132] 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.

[0133] 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.

[0134] 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.

[0135] 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.

[0136] 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.

[0137] Furthermore, in this embodiment, the navigation device 1 is configured to execute the automated driving support program (Figure 4), but it may also be configured to be executed by an in-vehicle device other than the navigation device 1 or by 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 4). In that case, the server device 4 corresponds to the driving support device of this application.

[0138] 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 4) 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]

[0139] 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

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, A direction setting means for setting the direction of the vehicle when it reaches the start and end points of the turning section based on the aforementioned planned route, A starting vector acquisition means that 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, An end vector acquisition means 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, A trajectory generation means generates a trajectory through which the vehicle passes in the direction of each vector from the start vector to the end vector, as a trajectory on which the vehicle is recommended to travel in the turning section. A driving support device comprising: a driving support means that provides driving support for a vehicle based on a driving track generated by the driving track generating means.

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, 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 generating means generates a recommended trajectory for the vehicle in the turning section, provided that the vehicle's orientation when reaching the target point is the orientation set by the orientation 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 driving assistance means is The aforementioned planned route is divided into multiple sections based on the driving manner of the vehicle when traveling along the aforementioned planned route. The system stores information that identifies the travel track generated by the travel track generation means for the section corresponding to the turning section among the aforementioned multiple sections. A driver assistance system that provides driving support for a vehicle based on stored information.

3. If the aforementioned turning section is a section where a vehicle travels on a curved road while turning, The means for acquiring the turning section acquires the turning section using information about road markings or information about the curvature of the road. The driving assistance device according to claim 1, wherein the direction setting means sets the direction of travel of the road at the start and end points of the turning section as the direction of the vehicle when the vehicle reaches the start and end points of the turning section, respectively.

4. If the aforementioned turning section is a section where a vehicle travels on a curved road while turning, The means for acquiring the turning section acquires the turning section using information about road markings or information about the curvature of the road. The driving assistance device according to claim 2, wherein the direction setting means sets the direction of travel of the road at the target point as the direction of the vehicle when the vehicle arrives at the target point.

5. The driving support device according to claim 1 or claim 2, wherein the driving trajectory generating means generates a driving trajectory in which the change in direction is continuous within a predetermined range as a driving trajectory on which the vehicle is recommended to travel.

6. The driving support device according to claim 1 or 2, wherein the driving track generated by the driving track generating means is a track that combines at least two or more tracks, namely a straight track, a circular arc track, and a clothoid curve track, and the distance and azimuth change amount of each track are specified.

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, A direction setting means for setting the direction of the vehicle when it reaches the start and end points of the turning section based on the aforementioned planned route, A starting vector acquisition means that 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, An end vector acquisition means 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, A trajectory generation means generates a trajectory through which the vehicle passes in the direction of each vector from the start vector to the end vector, as a trajectory on which the vehicle is recommended to travel in the turning section. A driving support means that provides driving support for a vehicle based on the driving trajectory generated by the aforementioned driving trajectory generating means, A computer program designed to make something function.

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, 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 generating means generates a recommended trajectory for the vehicle in the turning section, provided that the vehicle's orientation when reaching the target point is the orientation set by the orientation 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 driving assistance means is The aforementioned planned route is divided into multiple sections based on the driving manner of the vehicle when traveling along the aforementioned planned route. The system stores information that identifies the travel track generated by the travel track generation means for the section corresponding to the turning section among the aforementioned multiple sections. A computer program that provides driving assistance for a vehicle based on stored information.