Navigation method and system based on signal lamp data

Abstract

The invention provides a navigation method and system based on signal lamp data. The method comprises the following steps: receiving a navigation request, wherein the navigation request comprises a starting point and an ending point; receiving cloud signal lamp data, wherein the cloud signal lamp data indicates the predicted states of a plurality of signal lamps at a future time point based on the current traffic data; receiving road side unit (RSU) end signal lamp data, wherein the RSU end signal lamp data is included in a V2X message sent from an RSU; fusing the received cloud end signal lamp data and the received RSU end signal lamp data to obtain fused signal lamp data; and generating one or more candidate routes based on the navigation request, the fused traffic light data, and a current / historical average vehicle speed of the vehicle, each of the one or more candidate routes being capable of indicating a predicted travel time of the candidate route, the predicted driving time is at least based on signal lamp data of signal lamps passed in the candidate route.

Description

TECHNICAL FIELD

[0001] The present application relates to navigation technology, and more particularly, to a navigation method and system based on traffic signal data. BACKGROUND

[0002] Currently, through the navigation function on the vehicle, the user can select the ideal route guidance. For example, the navigation function, when providing route guidance, can generally provide multiple candidate routes for the user to select based on the total length of the route, the total driving time of the route, the user's driving preferences, the user's driving history data, etc. In urban traffic, traffic signal light (e.g., red light) information is a factor worth considering for route planning. For the user, even if the selected route is shorter in total distance, it is not a satisfactory experience if the time waiting for the signal light to turn green is longer. SUMMARY

[0003] The summary is provided to introduce some concepts in a simplified form that will be further described below in the detailed description. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used to determine the scope of the claimed subject matter.

[0004] According to one embodiment of the present application, a navigation method based on signal light data is provided, comprising: receiving a navigation request, the navigation request comprising a starting point and an ending point; receiving cloud signal light data, the cloud signal light data indicating the states of a plurality of signal lights at future time points predicted based on current traffic data; receiving road side unit (RSU) end signal light data, the RSU end signal light data being included in a V2X message sent from the RSU; fusing the received cloud signal light data and the received RSU end signal light data to obtain fused signal light data; and generating one or more candidate routes based on the navigation request, the fused signal light data, and the current / historical average vehicle speed of the vehicle, each of the one or more candidate routes being able to indicate the estimated driving time of the candidate route, the estimated driving time being based at least on the signal light data of the signal lights passed in the candidate route.

[0005] According to another embodiment of the present application, there is provided a navigation system for signal light data based navigation, comprising: a navigation request receiving module configured to receive a navigation request, the navigation request comprising a start point and an end point; a cloud signal light data receiving module configured to receive cloud signal light data, the cloud signal light data indicating states of a plurality of signal lights at future time points predicted based on current traffic data; a RSU end signal light data receiving module configured to receive road side unit, RSU end signal light data, the RSU end signal light data being included in a V2X message sent from a RSU; a signal light data fusing module configured to fuse the received cloud signal light data and the received RSU end signal light data to obtain fused signal light data; and a route planning module configured to generate one or more candidate routes based on the navigation request, the fused signal light data and a current / historical average speed of a vehicle, each of the one or more candidate routes being capable of indicating a predicted travel time of the candidate route, the predicted travel time being based on at least signal light data of signal lights passed in the candidate route.

[0006] According to yet another embodiment of the present application, there is provided a vehicle, comprising: a navigation system as described above, and a display.

[0007] These and other features and advantages will be apparent from a reading of the following detailed description and a review of the associated drawings. It is to be understood that both the foregoing general description and the following detailed description are meant only to illustrate and not to limit the various aspects claimed. BRIEF DESCRIPTION OF DRAWINGS

[0008] So that the manner in which the above-recited features and advantages of the present application can be understood in detail, a brief description of the embodiments can be had below with reference to the accompanying drawings, which are intended to be illustrative only. It is to be understood that the description and the specific examples are intended to be illustrative only and are not intended to limit the scope of the application.

[0009] Figure 1 FIG. 1 shows an architecture diagram of a signal light data based navigation scheme according to an embodiment of the present application;

[0010] Figure 2 FIG. 2 shows a block diagram of a signal light data based navigation system 200 according to an embodiment of the present application;

[0011] Figure 3A flowchart illustrating a navigation method 300 for traffic signal light data according to one embodiment of the present application is shown; and

[0012] Figure 4 A block diagram of an exemplary computing device according to one embodiment of the present application is shown. DETAILED DESCRIPTION

[0013] The present application will be described in detail below with reference to the attached drawings.

[0014] The following detailed description describes the application in connection with the illustrative embodiments. However, the application should not be construed as limited to the embodiments set forth herein, but instead, should be given the broadest interpretation of the appended claims and all equivalent techniques. To the extent that the application does not recite "means plus function" clauses, those elements are described using the specific language of the claim.

[0015] Reference throughout this specification to "an embodiment", "embodiments", "exemplary embodiment", etc., means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the application. The appearances of the phrase "in one embodiment" in various places in the specification are not necessarily referring to the same embodiment.

[0016] Terminology:

[0017] IVI (In-Vehicle Infotainment): is the use of vehicle-specific central processing unit, based on the body bus system and Internet services, the formation of vehicle integrated information processing system. IVI can achieve a series of applications including three-dimensional navigation, real-time traffic, IPTV, auxiliary driving, fault detection, vehicle information, body control, mobile office, wireless communication, online-based entertainment functions, greatly improve the level of vehicle electronics, networking and intelligent.

[0018] Vehicle to Everything (V2X): It is a key technology of intelligent transportation system. V2X mainly includes V2V (Vehicle to Vehicle), V2I (Vehicle to Infrastructure), V2N (Vehicle to Network), V2P (Vehicle to Pedestrian). Thus, V2X technology enables vehicles and base stations to communicate with each other, thereby obtaining real-time road conditions, road information, pedestrian information, and a series of information.

[0019] Road Side Unit (RSU): It is a unit installed on the roadside, and its main function is to collect current road conditions, traffic conditions, and other information. It can communicate with vehicles using technologies such as DSRC (Dedicated Short Range Communication) and the like.

[0020] Signal Phase and Timing Message (SPAT): It contains the current state information of one or more intersection signal lights.

[0021] Map Message (MAP): It is a local map message issued by the Road Side Unit (RSU), which includes intersection information, road segment information, lane information, and connection relationships between roads in the local area.

[0022] Signal Phase: In the traffic management system, signal phase is used to describe the state of traffic signal lights. It includes different colors of signal lights and / or directions of indicating arrows, which are used to indicate when traffic participants can proceed, stop, or turn.

[0023] Green Light Optimal Speed Advisory (GLOSA): As an intelligent transportation application function based on vehicle-road cooperation technology, it refers to calculating the optimal guided speed and prompting the driver before the vehicle enters the intersection, according to real-time signal phase state information (such as SPAT and MAP information received from RSU using V2X technology), vehicle state information, and auxiliary information (such as road speed limit, traffic flow, queuing, etc.), through certain optimization indicators, so as to help vehicles pass through the intersection quickly, economically, and comfortably.

[0024] Currently, a V2X system of a vehicle can be configured to communicate with external sources (e.g., RSUs, other vehicles, etc.) for V2X communication, thereby receiving V2X messages, such as SPAT messages and MAP messages. The messages received via the V2X system can be transmitted to a GLOSA application / function, which can suggest a speed for passing through a current intersection according to SPAT and MAP information received from RSUs via the V2X system, and according to a distance of the vehicle to a stop line, a vehicle location, a signal light phase, a signal light remaining time, etc., thereby achieving a green wave pass through the current intersection. However, given that the number of RSUs is small and the range of V2X message transmission is limited, the GLOSA function can only provide a green wave speed guide for the current intersection or a nearby intersection of the vehicle. Thus, the GLOSA function cannot provide a green wave speed guide for a longer route in advance.

[0025] Generally, RSUs can be supported by a traffic management system of a city, networked with a traffic system of the city, and directly obtain real state data of signal lights. Thus, the signal light data (e.g., a current phase of a signal light, a waiting time of a signal light to a next phase, a next phase of a signal light, a waiting time of a signal light to a next next phase, etc.) provided by RSUs is relatively accurate. However, as mentioned above, since RSUs are hardware facilities, the manufacturing and deployment costs are high, and currently, RSUs do not cover every intersection.

[0026] Currently, based on the development of big data and AI related technologies, a cloud can establish a model of a waiting time of a signal light (e.g., according to historical data and a current traffic condition, a waiting time of a signal light at a future time can be predicted) by statistically analyzing a large amount of real-time traffic data, to provide predicted signal light data for each intersection of a user's route. However, there can be some errors between the signal light state calculated by big data and the actual signal light state.

[0027] The present application fuses signal light data provided by RSUs with signal light data provided by a cloud, and integrates the fused data into a navigation function, to provide route planning based on signal light data. Through the present application, after a user issues a navigation request through a vehicle, one or more candidate routes considering waiting time for signal lights on a route can be obtained, and the driving time of the one or more candidate routes can be constantly updated as the vehicle travels, to provide a more friendly user experience to the user.

[0028] Figure 1 An architecture diagram 100 of a navigation scheme based on traffic signal light data according to one embodiment of the present application is shown.

[0029] As Figure 1As shown, specifically, the architecture mainly includes a V2X system 101 and a navigation system 102. The vehicle receives cloud-based traffic light data D1 from the cloud via an onboard network access device (NAD) (e.g., a 4G / 5G NAD). In the context of this invention, the cloud can refer to a remote service providing predicted traffic light data. In one example, the cloud-based traffic light data D1 can be obtained from the cloud according to predetermined rules. For example, traffic light data for traffic lights within a predetermined range (e.g., the entire city) can be obtained, traffic light data for traffic lights along the route from the starting point to the destination can be obtained, and so on.

[0030] The vehicle receives RSU-side traffic light data D2 from the RSU (e.g., the RSU at the current intersection or a nearby RSU) via V2X system 101. For example, this RSU-side traffic light data D2 may be included in V2X messages (e.g., SPAT and MAP messages) transmitted from the RSU and transmitted to the traffic light data fusion function 106 via V2X physical layer 104 and V2X message layer 105. This RSU-side traffic light data D2 can indicate the traffic light data at the current intersection where the vehicle is located or at intersections within a certain range near the vehicle.

[0031] The traffic light data fusion function 106 combines D1 received from the cloud and D2 received from the RSU to obtain fused traffic light data D3, and integrates the fused traffic light data D3 into the navigation map of the navigation system 102. The route planning function 107 in the navigation system 102 can provide the user with one or more candidate routes, such as candidate routes R1, R2, and R3, based on the fused traffic light data D3 and vehicle data D4 (e.g., the vehicle's current / historical average speed V, current timestamp T, etc.). Each candidate route can indicate the corresponding travel time taking into account the traffic light data of all traffic lights along the route. For example, R1: 34 minutes (traffic lights), R2: 30 minutes (traffic lights), R3: 32 minutes (traffic lights). For example, "R1: 34 minutes (traffic lights)" could indicate that the predicted travel time for route R1 is 34 minutes, which includes the waiting time at all traffic lights from the origin to the destination.

[0032] Figure 2 A block diagram of a navigation system 200 based on traffic light data according to an embodiment of the present invention is shown. In one embodiment, the system 200 may be integrated into an in-vehicle IVI system. In yet another embodiment, the system 200 may be implemented as a standalone system.

[0033] The system 200 may include a navigation request receiving module 201, a cloud-based traffic light data receiving module 202, an RSU-based traffic light data receiving module 203, a traffic light data fusion module 204, and a route planning module 205. Those skilled in the art will fully understand that the above module division is merely for clarity of explanation. The functions of one or more of the above modules may be combined into a single module or split into multiple modules. Furthermore, one or more of the above modules may be implemented using software, hardware, or a combination thereof. In addition, the data transmission methods between the modules may employ methods known in the art, which are beyond the scope of this invention.

[0034] According to one embodiment of the present invention, the navigation request receiving module 201 can be configured to receive navigation requests indicating a starting point, a destination, or user route preferences (e.g., preference for elevated roads, preference for ground roads, avoiding U-turns, avoiding oncoming traffic, avoiding construction zones, etc.). Generally, the route starting point can be the location of the vehicle when the user initiates the navigation request.

[0035] According to one embodiment of the present invention, the cloud-based traffic light data receiving module 202 can be configured to receive cloud-based traffic light data from the cloud, which can indicate the state of multiple traffic lights at a future point in time based on current traffic data. For example, as described above, the cloud can use various trained models based on current traffic data to predict the phase of a traffic light at a future point in time, the waiting time until the next phase, and so on.

[0036] In one example, the cloud-based traffic light data may include cloud-based traffic light data for multiple traffic lights. For example, depending on the hardware's storage capacity or other practical requirements, these multiple traffic lights could be: all traffic lights in the administrative region where the vehicle is currently located (e.g., province, city, county, etc.), all traffic lights in the areas that the route from the requested starting point to the destination may take (e.g., Yangpu District / Hongkou District / Huangpu District, Shanghai, etc.), all traffic lights on the roads that the route from the requested starting point to the destination may take, etc. The areas or roads that the route from the requested starting point to the destination may take can be determined based on historical driving data recorded in big data, current traffic flow information, current road conditions (e.g., construction, road closures, etc.), user route preferences, etc.

[0037] According to one embodiment of the present invention, the RSU-side traffic light data receiving module 203 can be configured to receive RSU-side traffic light data from the RSU, which can be included in V2X messages (e.g., SPAT and MAP messages) sent from the RSU. In practice, the traffic light itself can also be used as an RSU, that is, the traffic light itself can also send V2X messages to inform it of its own traffic light status.

[0038] The RSU-side traffic light data can indicate the current real-time traffic light data within a certain range around the vehicle. In one example, this range of traffic lights could refer to the traffic lights at the intersection ahead of the vehicle's current location. In another example, this range of traffic lights could refer to all traffic lights covered within the RSU's message transmission distance (e.g., 50 meters, 100 meters, etc.).

[0039] According to one embodiment of the present invention, the traffic light data fusion module 204 can be configured to fuse the received cloud traffic light data and the received RSU terminal traffic light data to obtain fused traffic light data.

[0040] In one example, the fusion may include updating received cloud-based traffic light data based on received RSU-based traffic light data, wherein, for one or more traffic lights involved in the RSU-based traffic light data received by the vehicle, the corresponding data in the RSU-based traffic light data is used to replace the traffic light data in the cloud-based traffic light data for that one or more traffic lights. For example, if the RSU-based traffic light data includes traffic light data for traffic light L1, the traffic light data for traffic light L1 in the cloud-based traffic light data is compared with the data in the RSU-based traffic light data; if they are inconsistent, the traffic light data for traffic light L1 in the cloud-based traffic light data is updated to the traffic light data for traffic light L1 in the RSU-based traffic light data.

[0041] In yet another example, the fusion may further include updating the signal data of other traffic lights involved in the updated cloud-based signal data. For example, continuing the example above, after updating the cloud-based signal data for signal light L1 (i.e., after obtaining the actual signal data for signal light L1), if it is found that the predicted cloud-based signal data for signal light L2 at a subsequent intersection conflicts with the actual signal data for signal light L1 (e.g., does not comply with urban traffic signal design rules, etc.), the calculation can be performed again in the cloud to update the signal data for signal light L2 (and potentially other traffic lights).

[0042] Therefore, through this fusion, the fused traffic light data provides a wider range of traffic light data compared to the received RSU traffic light data, and provides data that is closer to the real traffic light data compared to the received cloud traffic light data, thus providing more comprehensive and accurate traffic light data for subsequent route navigation calculations.

[0043] According to one embodiment of the present invention, the route planning module 205 can be configured to generate one or more candidate routes based on a start point, an end point, fused traffic light data, and the vehicle's current / historical average speed. Each of the one or more candidate routes can indicate the estimated travel time based on traffic light data of the traffic lights passed along the candidate route. For example, a vehicle can calculate the required waiting time at a traffic light when passing through an intersection at a future time point based on the fused traffic light data and the vehicle's current / historical average speed, and accumulate the required waiting time for each traffic light passed along the candidate route to include the accumulated waiting time in the calculation of the estimated travel time of the candidate route.

[0044] For example, if a candidate route will pass through traffic lights L1, L2, L3, and L4, the time of encountering each traffic light and the required waiting time at that time can be determined based on the fused traffic light data for these four traffic lights and the current / historical average vehicle speed. By summing the required waiting times for each traffic light, the total waiting time for passing through all traffic lights can be obtained, and this total waiting time is included in the estimated travel time of the candidate route.

[0045] Figure 3 A flowchart of a navigation method 300 based on traffic light data according to an embodiment of the present invention is shown. Generally, for a traffic light, the traffic light data can indicate one or more of the following: the current phase of the traffic light, the waiting time of the traffic light to the next phase, the next phase of the traffic light, the waiting time of the next phase of the traffic light to the next phase after that, etc.

[0046] At step 305, a navigation request is received, which includes the route's starting point and destination. In one example, the navigation request may also include the user's route preferences.

[0047] At 310, cloud-based traffic light data is received, which indicates the future status of multiple traffic lights based on current traffic data. These multiple traffic lights can be: all traffic lights in the vehicle's current administrative region (e.g., province, city, county), all traffic lights in the areas that the vehicle may pass through from the requested origin to the destination (e.g., Yangpu District / Hongkou District / Huangpu District of Shanghai), and all traffic lights on the roads that the vehicle may pass through from the requested origin to the destination, etc.

[0048] At 315, traffic light data from the RSU is received, which is included in the V2X message sent from the RSU. This RSU traffic light data indicates the current, real-time traffic light data within a certain range around the vehicle.

[0049] At 320, the received cloud-based traffic light data and the received RSU-based traffic light data are fused to obtain fused traffic light data. In one example, this fusion may include updating the received cloud-based traffic light data based on the received RSU-based traffic light data, wherein, for one or more traffic lights involved in the RSU-based traffic light data received by the vehicle, the corresponding traffic light data in the cloud-based traffic light data is replaced with the corresponding traffic light data in the RSU-based traffic light data.

[0050] At 325, one or more candidate routes are generated based on the received navigation request, fused traffic light data, and the vehicle's current / historical average speed. Each of these candidate routes indicates the estimated travel time based on traffic light data passed through the traffic lights along the route. Specifically, for each candidate route, the required waiting time at a specific traffic light at a future point in time is calculated based on the origin, destination, fused traffic light data, and the vehicle's current / historical average speed from the navigation request. The required waiting time for each traffic light passed through the candidate route is then accumulated and included in the estimated travel time of the candidate route.

[0051] Therefore, users can choose the optimal route (e.g., the route with the shortest estimated travel time) from one or more generated candidate routes for navigation. Alternatively, the optimal candidate route can be directly applied as the navigation route to the user's navigation.

[0052] In practice, as the vehicle moves, it continuously receives new RSU-issued traffic light data, and the cloud-based traffic light data is also continuously predicted as big data is updated. Therefore, steps 310-325 can be performed periodically (e.g., every 30 seconds, every minute, etc.) or upon receiving new RSU traffic light data to provide an updated estimated travel time for each candidate route / currently selected route as the vehicle moves forward.

[0053] Figure 4 A block diagram of an exemplary computing device according to an embodiment of the present invention is shown, which is an example of a hardware device applicable to various aspects of the present invention.

[0054] refer to Figure 4 A computing device 400 will now be described as an example of a hardware device applicable to various aspects of the present invention. The computing device 400 can be any machine configured to perform processing and / or computation, and can be, but is not limited to, a workstation, server, desktop computer, laptop computer, tablet computer, personal digital processor, smartphone, in-vehicle computer, or any combination thereof. The various methods / apparatus / server / client devices described above can be implemented wholly or at least partially by the computing device 400 or similar devices or systems.

[0055] The computing device 400 may include components that can be connected or communicated via one or more interfaces and a bus 402. For example, the computing device 400 may include a bus 402, one or more processors 404, one or more input devices 406, and one or more output devices 408. The one or more processors 404 may be any type of processor and may include, but are not limited to, one or more general-purpose processors and / or one or more dedicated processors (e.g., specialized processing chips). The input devices 406 may be any type of device capable of inputting information to the computing device and may include, but are not limited to, a mouse, keyboard, touchscreen, microphone, and / or remote controller. The output devices 408 may be any type of device capable of presenting information and may include, but are not limited to, a monitor, speaker, video / audio output terminal, vibrator, and / or printer. The computing device 400 may also include or be connected to a non-transient storage device 410. The non-transient storage device can be any storage device that is non-transient and capable of data storage, and may include, but is not limited to, disk drives, optical storage devices, solid-state storage, floppy disks, hard disks, magnetic tapes or any other magnetic media, optical discs or any other optical media, ROM (read-only memory), RAM (random access memory), cache memory, and / or any memory chip or cassette tape, and / or any other medium from which a computer can read data, instructions, and / or code. The non-transient storage device 410 may be detachable from an interface. The non-transient storage device 410 may have data / instructions / code for implementing the methods and steps described above. The computing device 400 may also include a communication device 412. The communication device 412 can be any type of device or system capable of communicating with internal devices and / or with a network, and may include, but is not limited to, modems, network cards, infrared communication devices, wireless communication devices and / or chipsets, such as Bluetooth devices, IEEE 1302.11 devices, WiFi devices, WiMax devices, cellular communication devices and / or similar devices.

[0056] When the computing device 400 is used as an in-vehicle device, it can also be connected to external devices (e.g., a GPS receiver, sensors for sensing different environmental data such as accelerometers, wheel speed sensors, gyroscopes, etc.). In this way, the computing device 400 can, for example, receive positioning data and sensor data indicating the vehicle's condition. When the computing device 400 is used as an in-vehicle device, it can also be connected to other devices used to control the vehicle's driving and operation (e.g., engine system, windshield wipers, anti-lock braking system, etc.).

[0057] Furthermore, the non-transient storage device 410 may contain map information and software components, enabling the processor 404 to perform route guidance processing. Additionally, the output device 406 may include a display for showing a map, displaying vehicle location markers, and displaying images indicating the vehicle's driving status. The output device 406 may also include a speaker or headphone jack for audio guidance.

[0058] Bus 402 may include, but is not limited to, Industry Standard Architecture (ISA) bus, Microchannel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and PCI bus. In particular, for automotive devices, bus 402 may also include Controller Area Network (CAN) bus or other architectures designed for automotive applications.

[0059] The computing device 400 may also include a working memory 414, which may be any type of working memory capable of storing instructions and / or data that are conducive to the operation of the processor 404, and may include, but is not limited to, random access memory and / or read-only memory devices.

[0060] Software components may reside in working memory 414, including but not limited to operating system 416, one or more application programs 418, drivers, and / or other data and code. Instructions for implementing the above methods and steps may be contained in the one or more application programs 418, and modules / units / components of the aforementioned various devices / servers / clients may be implemented by processor 404 reading and executing the instructions of the one or more application programs 418.

[0061] It should also be recognized that variations can be made to suit specific needs. For example, custom hardware and / or specific components may be used, and implementation may take place in hardware, software, firmware, middleware, microcode, hardware description language, or any combination thereof. Furthermore, connectivity with other computing devices, such as network input / output devices, may be employed. For example, some or all of the disclosed methods and apparatus may be implemented using the logic and algorithms according to the invention via programmable hardware (e.g., programmable logic circuits including field-programmable gate arrays (FPGAs) and / or programmable logic arrays (PLAs)) that uses assembly language or hardware programming languages ​​(e.g., Verilog, VHDL, C++).

[0062] Although various aspects of the invention have been described so far with reference to the accompanying drawings, the methods, systems, and apparatus described above are merely examples, and the scope of the invention is not limited to these aspects but is defined only by the appended claims and their equivalents. Various components may be omitted or replaced by equivalent components. Furthermore, the steps may be performed in a different order than that described in the invention. Moreover, various components can be combined in various ways. Importantly, as technology advances, many of the components described may be replaced by equivalent components that appear later.

Claims

1. A navigation method based on traffic light data, comprising: (1) Receive a navigation request, the navigation request including a starting point and a destination; (2) Receive traffic light data from the cloud, wherein the traffic light data from the cloud indicates the state of multiple traffic lights at future points in time based on current traffic data; (3) Receive traffic light data from the roadside unit (RSU), wherein the traffic light data from the RSU is included in a V2X message sent from the RSU; (4) The received cloud signal light data and the received RSU signal light data are fused together to obtain fused signal light data; as well as (5) Generate one or more candidate routes based on the navigation request, the fused traffic light data and the vehicle’s current / historical average speed, each of the one or more candidate routes being able to indicate the estimated travel time of the candidate route, the estimated travel time being based at least on the traffic light data of the traffic lights passed through in the candidate route.

2. The method as described in claim 1, characterized in that, For a traffic light, the traffic light data indicates one or more of the following: the current phase of the traffic light, the waiting time of the traffic light until the next phase, the next phase of the traffic light, and the waiting time of the next phase of the traffic light until the next phase after that.

3. The method as described in claim 1, characterized in that, The plurality of traffic lights are one of the following: all traffic lights in the administrative region where the vehicle is currently located, all traffic lights in the area that may be traversed from the starting point to the destination requested in the navigation request, and all traffic lights on the road that may be traversed from the starting point to the destination requested in the navigation request.

4. The method as described in claim 1, characterized in that, The RSU terminal signal light data indicates the current actual signal light data within a certain range around the vehicle.

5. The method as described in claim 1, characterized in that, The fusion includes updating the cloud-based traffic light data based on the traffic light data at the RSU terminal.

6. The method as described in claim 5, characterized in that, The update further includes: For one or more traffic lights involved in the RSU-side traffic light data, the corresponding traffic light data in the cloud-based traffic light data is used to replace the traffic light data for the one or more traffic lights.

7. The method as described in claim 1, characterized in that, The generation of one or more candidate routes further includes: For each candidate route, the required waiting time for a specific traffic light at a future specific time point is calculated based on the fused traffic light data and the vehicle's current / historical average speed. The required waiting time for each traffic light encountered along the candidate route is then accumulated and incorporated into the estimated travel time of the candidate route.

8. The method as described in claim 1, characterized in that, Steps (2) to (5) can be executed periodically to update the estimated travel time of the one or more candidate routes.

9. A navigation system based on traffic light data, comprising: A navigation request receiving module, configured to receive navigation requests, the navigation requests including a start point and an end point; A cloud-based traffic light data receiving module is configured to receive cloud-based traffic light data, which indicates the state of multiple traffic lights at future points in time based on current traffic data. The RSU-side traffic light data receiving module is configured to receive traffic light data from the roadside unit (RSU), and the RSU-side traffic light data is included in a V2X message sent from the RSU. A traffic light data fusion module is configured to fuse received cloud-based traffic light data and received RSU-based traffic light data to obtain fused traffic light data. as well as A route planning module is configured to generate one or more candidate routes based on the navigation request, the fused traffic light data, and the vehicle's current / historical average speed. Each of the one or more candidate routes is capable of indicating the estimated travel time of the candidate route, the estimated travel time being based at least on traffic light data of the traffic lights traversed along the candidate route.

10. The system as described in claim 9, characterized in that, The system is integrated into the vehicle's in-vehicle infotainment (IVI) system.

11. The system as described in claim 9, characterized in that, For a traffic light, the traffic light data indicates one or more of the following: the current phase of the traffic light, the waiting time of the traffic light until the next phase, the next phase of the traffic light, and the waiting time of the next phase of the traffic light until the next phase after that.

12. The system as described in claim 9, characterized in that, The RSU terminal signal light data indicates the current actual signal light data within a certain range around the vehicle.

13. The system as described in claim 9, characterized in that, The fusion includes updating the cloud-based traffic light data based on the traffic light data at the RSU terminal.

14. The system as described in claim 9, characterized in that, The generation of one or more candidate routes further includes: For each candidate route, the required waiting time for a specific traffic light at a future specific time point is calculated based on the fused traffic light data and the vehicle's current / historical average speed. The required waiting time for each traffic light encountered along the candidate route is then accumulated and incorporated into the estimated travel time of the candidate route.

15. A vehicle comprising: The navigation system as described in any one of claims 9-14; as well as monitor.

Images