Method of estimating time of travel of route including point, electronic device and computer readable medium for implementing

Abstract

The disclosure relates to a method of estimating a travel time of a route including a waypoint, an electronic device implementing the method, and a computer readable medium. The method is performed by a memory storing instructions and a processor executing the instructions. An electronic device is configured to implement the estimation method. The method includes: in response to a vehicle route request including a waypoint, predicting an estimated arrival time of the waypoint; estimating the residence time of the waypoint based on the user information of the vehicle and the planned use information of the waypoint; and predicting a final travel time to the destination based on the estimated dwell time.

Description

[0001] Cross-reference to related applications

[0002] This application claims the benefit of Korean Patent Application No. 10-2024-0137647, filed on October 10, 2024, the entire contents of which are incorporated herein by reference. Technical Field

[0003] This disclosure relates to a method and apparatus for estimating the travel time of a route including waypoints, and more specifically, to a method and apparatus for estimating travel time to accurately predict the estimated arrival time to a destination as guidance for a route including waypoints. Background Technology

[0004] The electronic device may be equipped with navigation capabilities (e.g., GPS) that provide a route on a map to the user's desired destination. Here, the electronic device may be a portable device (such as a smartphone), but is not limited to this, and may be a tablet computer or other electronic device with software capabilities similar to those of a portable device and manufactured in various forms. The product may be a means of transportation, such as a vehicle.

[0005] For user convenience, navigation can handle route guidance requests, including waypoints to be visited on the way to the final destination. Regular route guidance is based on the assumption that after reaching a waypoint, the vehicle will not stop at the waypoint and will immediately proceed to the destination. Such waypoints can be points of interest at locations specified by the user. Users who have requested waypoints actually travel to their destination after a certain period of time. Regular route guidance, by not considering stopovers at waypoints, results in inaccurate travel times for routes including waypoints, making it impossible for users to know the precise estimated arrival time at their destination.

[0006] Furthermore, even with the same waypoints, the dwell time at each waypoint can vary depending on the vehicle user's characteristics and specific driving habits. Therefore, when predicting the final travel time of a route that includes waypoints, navigation systems need to provide personalized dwell times that take into account the user's characteristics and driving habits. Summary of the Invention

[0007] This disclosure aims to provide a method and apparatus for estimating travel time to accurately predict the estimated arrival time to a destination as guidance for a route including waypoints.

[0008] The technical problems to be solved by this disclosure are not limited to those described above, and those skilled in the art to which this disclosure pertains will clearly understand from the following description other technical problems not mentioned. According to this disclosure, a method for estimating the travel time of a route including waypoints includes the following steps: providing a memory configured to store at least one instruction and a processor configured to execute at least one instruction stored in the memory; the processor predicting an estimated arrival time at a waypoint in response to a vehicle route request including a waypoint; the processor estimating a dwell time at a waypoint based on user information of the vehicle and planned usage information of the waypoint; and the processor predicting the final travel time to the destination based on the estimated dwell time.

[0009] According to one aspect, a method is provided, comprising: predicting an estimated arrival time at a waypoint in response to a vehicle route request including waypoints; estimating a dwell time at a waypoint based on user information of the vehicle and planned usage information of the waypoint; and predicting a final travel time to a destination based on the estimated dwell time.

[0010] According to this method, user information may include user attribute data and driving data. The user attribute data includes at least one of the user's age and gender, and the driving data includes the distance to waypoints.

[0011] According to this method, the planned usage information may include waypoint data, estimated time intervals for using waypoints, and date characteristics associated with the usage dates of waypoints. The waypoint data may include the identifier of the waypoint, the type of waypoint, and operational data of the waypoint, and the estimated time interval may be determined based on the estimated arrival time.

[0012] According to this method, the date feature can be defined as any one of weekdays, weekends, and holidays.

[0013] According to this method, estimating the dwell time at a waypoint may include: using a deep learning-based dwell time estimation model to estimate the dwell time.

[0014] According to this method, the dwell time estimation model can use an autoencoder model based on a convolutional neural network.

[0015] According to this method, the estimated dwell time can be the average dwell time derived from the analysis of user information and planned usage information.

[0016] According to this method, the estimated dwell time can be generated as equal to or longer than the minimum dwell time derived from the analysis of user information and planned usage information.

[0017] According to this method, the dwell time used for learning the dwell time estimation model can be generated based on time data from previous driving trajectory data of visiting waypoints, and the time data may include the arrival time and departure time of the waypoint.

[0018] According to this method, the dwell time used for learning the dwell time estimation model can utilize the dwell time accumulated through previous waypoint usage, and can be generated as a weighted average of the accumulated waypoint dwell times, and the weighted average can assign lower weights to the dwell times of relatively earlier collected waypoints.

[0019] According to this disclosure, an electronic device includes: a communication unit for transmitting data to and receiving data from an external device; a memory configured to store at least one instruction; and a processor configured to execute at least one instruction stored in the memory, wherein the processor is configured to: predict an estimated arrival time at a waypoint in response to a vehicle route request including a waypoint; estimate a dwell time at a waypoint based on user information of the vehicle and planned usage information of the waypoint; and predict a final travel time to a destination based on the estimated dwell time.

[0020] According to another aspect, an electronic device is provided for estimating the travel time of a route including waypoints. The electronic device includes: a communication unit for transmitting data to and receiving data from an external device; a memory for storing at least one instruction; and a processor for executing the at least one instruction stored in the memory. The processor is configured to: predict the estimated arrival time of the waypoints in response to a vehicle route request including waypoints; estimate the dwell time at the waypoints based on user information of the vehicle and planned usage information of the waypoints; and predict the final travel time to the destination based on the estimated dwell time.

[0021] According to this disclosure, a non-transitory computer-readable medium includes program instructions executable by a processor, which, when executed, cause the processor to perform the following operations: predicting an estimated arrival time at a waypoint in response to a vehicle route request including waypoints; estimating the dwell time at a waypoint based on user information of the vehicle and planned usage information of the waypoint; and predicting the final travel time to the destination based on the estimated dwell time.

[0022] The features briefly summarized above for use in this disclosure are merely exemplary aspects of the detailed description of this disclosure that follows, and are not intended to limit the scope of this disclosure.

[0023] The technical problems solved by this disclosure are not limited to those described above, and other technical problems not described herein will be clearly understood by those skilled in the art to which this disclosure pertains (hereinafter referred to as "skilled technicians") from the following description. Attached Figure Description

[0024] Figure 1 This is a diagram illustrating a vehicle communicating with another device to send and receive data.

[0025] Figure 2 This is a diagram showing the modules that make up a vehicle.

[0026] Figure 3 This is a diagram illustrating the modules constituting an electronic device according to an embodiment of the present disclosure.

[0027] Figure 4 This is a schematic diagram illustrating a model used to estimate the final travel time.

[0028] Figure 5 This is a schematic diagram illustrating the structure of the dwell time estimation model.

[0029] Figures 6A-6B This is a schematic diagram illustrating the data used in the dwell time estimation model.

[0030] Figure 7 This is a diagram showing the actual dwell time.

[0031] Figure 8 This is a flowchart of a travel time estimation method according to another embodiment of the present disclosure.

[0032] Figure 9 This is a diagram comparing the travel time estimates based on conventional methods and this embodiment. Detailed Implementation

[0033] It should be understood that, as used herein, the terms “vehicle” or “of a vehicle” or other similar terms include motor vehicles in a broad sense, such as passenger cars, including sport utility vehicles (SUVs), buses, trucks, various commercial vehicles, vessels (including various ships and vessels), aircraft, etc., and include hybrid vehicles, electric vehicles, plug-in hybrid electric vehicles, hydrogen-powered vehicles, and other alternative fuel vehicles (e.g., fuels derived from resources other than petroleum). As mentioned herein, a hybrid vehicle is a vehicle with two or more power sources, such as a gasoline-powered vehicle and an electric vehicle.

[0034] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit this disclosure. As used herein, unless the context clearly indicates otherwise, the singular forms “a,” “an,” and “the” are intended to also include the plural forms. It should also be understood that when the terms “comprising” and / or “including” are used in this specification, they specify the presence of a feature, integral, step, operation, element, and / or component, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or combinations thereof. As used herein, the term “and / or” includes any and all combinations of one or more of the associated listed items. Throughout this specification, unless explicitly stated otherwise, the word “comprising” and variations such as “including” or “containing” will be understood to imply the inclusion of elements, but do not exclude any other elements. Furthermore, the terms “unit,” “device,” “instrument,” and “module” described in the specification mean a unit for performing at least one function and operation, and can be implemented by hardware components or software components and combinations of hardware and software components.

[0035] Furthermore, the control logic of this disclosure can be embodied in a non-transitory computer-readable medium containing executable program instructions that are executed by a processor, controller, etc. Examples of computer-readable media include, but are not limited to, ROM, RAM, optical disc (CD)-ROM, magnetic tape, floppy disk, flash drive, smart card, and optical data storage device. The computer-readable medium can also be distributed across a network-coupled computer system, enabling it to be stored and executed in a distributed manner, for example, via a telematics server or a controller area network (CAN).

[0036] In the following, exemplary embodiments of the present disclosure will be described in detail with reference to the accompanying drawings, enabling those skilled in the art to readily implement the present disclosure. However, the present disclosure can be implemented in various different ways and is not limited to the embodiments described herein.

[0037] In describing exemplary embodiments of this disclosure, well-known functions or structures will not be described in detail, as they may unnecessarily obscure the understanding of this disclosure. The same constituent elements in the drawings are indicated by the same reference numerals, and repeated descriptions of the same elements will be omitted.

[0038] In this disclosure, when an element is simply referred to as “connected to,” “coupled to,” or “linked to” another element, it may mean that the element is “directly connected to,” “directly coupled to,” or “directly linked to” another element, or is connected to, coupled to, or linked to another element in between other elements.

[0039] In this disclosure, unless specifically mentioned otherwise, the terms first, second, etc., are used only to distinguish one element from another and do not limit the order or importance of the elements. Thus, a first element in one embodiment may be referred to as a second element in another embodiment, and similarly, a second element in one embodiment may be referred to as a first element in another embodiment, without departing from the scope of this disclosure.

[0040] In this disclosure, elements are distinguished from each other for the purpose of clearly describing each feature, and do not necessarily mean that the elements are separate. That is, multiple elements may be integrated into a single hardware or software unit, or a single element may be distributed and formed in multiple hardware or software units. Therefore, such integrated or distributed implementations are included within the scope of this disclosure, unless otherwise stated.

[0041] In this disclosure, the elements described in the various embodiments are not necessarily essential elements, and some of them may be optional elements. Therefore, embodiments comprising a subset of the elements described in the embodiments are also included within the scope of this disclosure. Furthermore, embodiments including elements other than those described in the various embodiments are also included within the scope of this disclosure.

[0042] The advantages and features of this disclosure, as well as the ways in which they are implemented, will become apparent from the following detailed description of embodiments taken in conjunction with the accompanying drawings. However, embodiments may be embodied in many different forms and should not be construed as limited to the exemplary embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be complete and its scope will be fully conveyed to those skilled in the art.

[0043] In this disclosure, each phrase such as “A or B”, “at least one of A and B”, “at least one of A or B”, “A, B or C”, “at least one of A, B and C”, “at least one of A, B or C”, and “at least one of A, B, C” or combinations thereof may include any or all possible combinations of the items listed together in the corresponding phrase.

[0044] In this disclosure, for ease of explanation, expressions of positional relationships such as “up,” “down,” “left,” and “right” are used as in this specification, and the positional relationships described in this specification can be understood in reverse if the accompanying drawings shown in this specification are reversed.

[0045] In the following description, embodiments of the present disclosure will be described with reference to the accompanying drawings.

[0046] In the following text, reference will be made to Figure 1 and Figure 2Describes electronic devices and vehicles used to estimate the travel time of a route, including waypoints. Figure 1 This is a diagram illustrating a vehicle communicating with another device to send and receive data. Figure 2 This is a diagram showing the modules that make up a vehicle.

[0047] In this disclosure, an example of an electronic device processing a route request received from vehicle 100 is described. For example, the electronic device could be a server 200 implementing a navigation function that processes requests from vehicle 100 while communicating with it. Unlike the example described above, the electronic device may communicate with another type of electronic device besides the vehicle, and an electronic device such as a portable terminal (e.g., a smartphone) may send a route request to electronic device 200. The electronic device may also process requests from mobile terminals. Therefore, the following description primarily refers to the processing of user requests between vehicle 100 and the electronic device (server; 200), but can be substantially similarly applied to mobile terminals.

[0048] refer to Figure 1 The vehicle 100 can be powered by either electricity or fossil fuels. In the case of electricity, for example, the vehicle 100 can be a pure battery vehicle powered solely by a high-voltage battery or a gas-based fuel cell. Furthermore, the fuel cell can utilize various forms of gas capable of generating electricity, and for example, the gas can be filled into the vehicle 100 in a liquefied state. Here, the gas can be, for example, hydrogen. However, it is not limited to this, and various gases can be used. In the case of fossil fuels, the vehicle 100 can be equipped with an internal combustion engine that is fuel-based (such as gasoline, diesel, or liquefied petroleum gas) and drives the actuator 114 through the combustion of the fuel. As another example, the vehicle 100 can selectively utilize the energy of a fossil-based internal combustion engine and a battery to drive the actuator 114, which could be a hybrid vehicle.

[0049] Vehicle 100 can refer to a mobile device. Vehicle 100 is a ground vehicle that travels on the ground and can be a conventional passenger vehicle, commercial vehicle, or private commercial vehicle (PBV). Vehicle 100 can be a four-wheeled vehicle, such as a bus, SUV, or light truck, or a vehicle with more than four wheels, such as a bus, large truck, container truck, or heavy vehicle. Vehicle 100 can also be a robot in the broadest sense, such as a mobile device, and the robot can move using wheels, tracks, or other mobile modules. Vehicle 100 can be controlled and driven autonomously, and this autonomous driving can be semi-autonomous or fully autonomous.

[0050] Simultaneously, vehicle 100 can communicate with other devices 200, 300, or another vehicle 400. Other devices may include, for example, a server 200 supporting various controls, status management, and driving functions of vehicle 100; an Intelligent Transportation System (ITS) device 300 for receiving information from the ITS; and various types of user devices. Server 200 is, for example, an external device operated or provided by the vehicle manufacturer for servicing autonomous driving, and can receive connection data from vehicle 100 or send data required for autonomous driving. In response to requests and data sent from vehicle 100 and user devices, server 200 can send various information and software modules for controlling vehicle 100 to support vehicle 100's operation and various services.

[0051] Server 200 can process route requests submitted by vehicle 100 and provide them to vehicle 100. Here, a user can request a route that includes a destination and waypoints. A waypoint can be a location visited by the user of vehicle 100 while traveling to the destination. In this disclosure, because a waypoint is a point that a user intentionally visits and utilizes the services provided by the waypoint, a waypoint may be referred to herein as a point of interest. In this disclosure, waypoints and points of interest may be described interchangeably.

[0052] Waypoints and destinations can be locations specified by the user by entering a specific name in navigation unit 108, or locations output as related to a rough term by entering a rough term in navigation unit 108. A specific name is a unique name for a location or specific location, and can be, for example, AA Restaurant, BB Resort, CC Intersection, DD Avenue, etc. A rough term can be, for example, a service term or category that the user expects to use, and can be entered as, for example, a restaurant, a cafe, or a attraction in a specific area. When a user searches for points of interest using rough terms, the user can enter a service term or category used at the current location or another location in navigation unit 108.

[0053] The ITS device 300 is, for example, a roadside base station (Roadside Unit; RSU), and the ITS device 300 can exchange vehicle identification data, driving control and status data, and environmental data around the vehicle with vehicle 100 via V2I to help users drive their own vehicles or support autonomous driving of vehicle 100. Vehicle 100 can exchange the above-listed data with another vehicle 400 via V2V to support manual or autonomous driving.

[0054] Vehicle 100 can communicate with other vehicles or other devices based on cellular communication, in-vehicle wireless access (WAVE) communication, dedicated short-range communication (DSRC) or near-field communication, or other communication schemes.

[0055] For example, vehicle 100 can use cellular communication networks (such as LTE or 5G), WiFi communication networks, WAVE communication networks, etc., to communicate with server 200, ITS device 300, and another vehicle 400. As another example, DSRC or similar devices used in vehicle 100 can also be used for communication between vehicles. The communication methods between vehicle 100, server 200, ITS device 300, another vehicle 400, and user equipment are not limited to the aforementioned embodiments.

[0056] Figure 2 This is a diagram illustrating the modules constituting a vehicle according to an embodiment of the present disclosure.

[0057] The vehicle 100 may include a sensor unit 102, an operation unit 104, a display 106, a navigation unit 108, and a transceiver 110.

[0058] Sensor unit 102 may include various types of detectors for sensing various scenes and situations occurring in the external environment, internal systems, user operations, and passenger space of vehicle 100. Sensor unit 102 may include outward-facing cameras, lidar sensors, radar sensors, etc., to identify dynamic and static objects present outside vehicle 100. Sensor unit 102 may include positioning sensors, wheel sensors, attitude sensors, etc., to check the vehicle's own position, speed, driving posture, etc. Sensor unit 102 may also include sensing modules for sensing various situations not listed herein.

[0059] The operating unit 104 can be configured as a module for user navigation while driving. For example, the operating unit 104 may be a steering wheel for manual driving, an automatic or manual shift actuator, an accelerator pedal, a brake pedal, a transmission, etc. The operating unit 104 may also include an interface for using, releasing, and selecting detailed functions of autonomous driving modes requested by the user, enabling the user to use autonomous driving functions.

[0060] Display 106 can be used as a user interface. Display 106 can be displayed by controller 118 to output the operating status, control status, route / traffic information, remaining energy information, driver requests, etc. of vehicle 100. In addition, display 106 can be configured as a touch screen on which driver input can be detected to receive requests from the driver to instruct controller 118.

[0061] The navigation unit 108 can receive route requests related to waypoints and destinations from the user and send the route requests to the server 200. It can also receive driving trajectory data based on the route and the estimated travel time for each point from the server 200 and provide this data to the user. The driving trajectory data can be displayed on a map provided by the navigation unit 108. In this disclosure, the estimated travel time to the destination can be described in conjunction with the final travel time, and the estimated travel time to the waypoints can be described in conjunction with the planned arrival times of the waypoints. The navigation unit 108 can be implemented in a display 106 or in a separate device installed on the vehicle 100. For example, the separate device can be a module uniquely installed in the vehicle 100 or a user's electronic device connected to the vehicle 100 via wired or wireless means. The user's electronic device can be controlled to connect to the vehicle 100 to present route requests, route information, and congestion information to an output interface, such as the display 106.

[0062] Although this disclosure primarily describes Figure 2 The module according to this embodiment is included, but the vehicle 100 may also include a load device in addition to the navigation unit 108. The load device may be a type of non-drive electrical device other than a drive power system such as a wheel drive unit (not shown). The load device is an auxiliary device that receives power from the power supply unit 112, and may be, for example, an air conditioning system, a lighting system, a seat system, various devices installed in the vehicle 100, etc.

[0063] Transceiver 110 supports communication with server 200, ITS device 300, and surrounding vehicles 400. Transceiver 110 may include modules for processing, for example, cellular communication, WAVE, and DSRC communication. Transceiver 110 can also support communication with electronic devices carried by passengers inside vehicle 100.

[0064] The vehicle 100 may also include a power supply unit 112 and an execution unit 114.

[0065] Power unit 112 can generate and supply power and electricity for driving the powertrain and non-driving powertrains (such as actuator 114). The non-driving powertrain can be, for example, sensor unit 102, operating unit 104, display 106, load device, transceiver 110, etc. When the vehicle 100 is driven by electric energy, power unit 112 can be, for example, composed of an externally charged battery, or a combination of a battery and a fuel cell that charges the battery. When the vehicle 100 is driven by fossil fuels, power unit 112 can be configured as an internal combustion engine. Furthermore, when the vehicle 100 is a hybrid type, power unit 112 can be provided by a combination of an internal combustion engine and a battery.

[0066] The execution unit 114 includes at least one module for implementing driving operations and can perform at least one driving operation, such as longitudinal control (acceleration and deceleration) and lateral control (steering), according to a user request from the operation unit 104. For this purpose, the execution unit 114 may include multiple wheels, a drive force generation module for generating and providing drive force to the wheels or transmitting drive force, a braking module for decelerating the driving of the wheels, a steering module for implementing lateral control of the wheels, etc. When the vehicle 100 is driven by electric power, the drive force generation module is configured as a motor component, and the braking module may also have regenerative braking functionality.

[0067] The vehicle 100 may also include a storage unit 116 and a controller 118.

[0068] Storage unit 116 can store applications and various data used to control vehicle 100, to load applications, read data, or record data according to requests from controller 118. In this disclosure, storage unit 116 may have software modules for processing route guidance, such as navigation applications.

[0069] Controller 118 can perform overall control of vehicle 100. Controller 118 can be configured to execute applications and instructions stored in storage unit 116. Controller 118 can execute navigation applications to handle user requests. Specifically, controller 118 can receive route requests input by the user of vehicle 100, send the route requests to server 200, and provide the user with a response from server 200 that processed the request.

[0070] Figure 3 This is a diagram illustrating the modules constituting an electronic device according to an embodiment of the present disclosure. The electronic device in this disclosure that executes a request for a route including waypoints can be shown as a server 200 communicating with vehicle 100.

[0071] As described above, server 200 can perform various service functions and navigation functions in response to route requests from vehicle 100, including providing travel trajectories and final travel times for waypoints and destinations. Server 200 may include communication unit 202, memory 204, and processor 206.

[0072] The communication unit 202 sends data to and receives data from external devices. In this disclosure, the communication unit supports mutual communication with the vehicle 100 and can exchange data with the vehicle 100.

[0073] Memory 204 can store applications and various data used to run server 200, to load applications or read and record data when requested by processor 206. In this disclosure, memory 204 may have software modules, such as navigation applications, for processing requests received from vehicle 100, such as route requests. Memory 204 can manage various information used to process route requests. The managed information may include, for example, map information, user information of vehicle 100, location information associated with waypoints, and data used to train models to estimate final travel time and dwell time.

[0074] As provided herein, the term "dwell time" refers to the length of time a vehicle stays at a waypoint location along a route, and according to this disclosure, dwell time can be estimated based on user information of the vehicle and planned usage information of the waypoints.

[0075] User information may include user attribute data and driving data. For example, user attribute data may include at least one of the current user's age and gender. It is not limited to this; user attribute data may contain various data that identify user characteristics. Driving data may include distances to waypoints calculated based on a request for a route that includes waypoints. In addition to distance, driving data may include driving trajectory data to the route destination based on traffic conditions, planned arrival times at waypoints, event information on the route including waypoints, etc. In response to a route request, server 200 includes this driving data in the route information for the destination, and the route information containing this driving data can be sent to vehicle 100.

[0076] Vehicle 100 can combine user attribute data with the user information received and sent in connection with a route request. The user can command the sending of user attribute data while requesting a route through vehicle 100 and the user device. For example, the user can select a user identifier provided by navigation unit 108 or the user device to send user attribute data corresponding to the user identifier to server 200. The user identifier can be a user profile or user identification ID that can be visually verified by the user. Alternatively, when a primary user of vehicle 100 is specified, even if the user does not request the sending of user attribute data, the controller 118 of vehicle 100 can be configured to send user attribute data associated with the primary user to server 200 along with the route request.

[0077] In another example, user attribute data can be stored on server 200. A user identifier is selected by the user on navigation unit 108 or user device, and this identifier can be sent to server 200 along with a route request. Server 200 can then select user attribute data that matches the user identifier information.

[0078] For example, location information may include at least one of the following: location identifier, location type, location operational data, services offered at the stop, location size, and customer acceptance range. The location type may be a type of function or service unique to the stop. For example, the type may be categorized as a restaurant, tourist attraction, cafe, street, convenience / entertainment facility, etc. For example, location operational data may include the location's opening hours, reservation availability, and parking availability. The services offered at the location may be a detailed menu that constitutes the services. For example, these services may include the menu of a restaurant / cafe, or various menus offered by a convenience or entertainment facility. For example, the location size may include the size of the facility in question, customer turnover rate using the location, etc. For example, the location's customer acceptance range may include the maximum number of visitors, the number of seats, the maximum waiting capacity, etc.

[0079] The following describes the details of the data used to train the model.

[0080] Processor 206 can perform overall control of server 200. Server 200 can be configured to execute applications and instructions stored in memory 204. Processor 206 can execute navigation applications to process and respond to user requests sent from vehicle 100. In conjunction with this disclosure, processor 206 can perform a process of predicting the expected arrival time of waypoints in response to vehicle route requests including waypoints. Furthermore, processor 206 can perform a process of estimating the dwell time at waypoints based on user information of vehicle 100 and planned usage information of waypoints. Processor 206 can perform a process of predicting the final travel time to the destination based on the estimated dwell time.

[0081] In this disclosure, processor 206 consists of a single processing module. In another example, processor 206 may be distributed across multiple processing modules, and the above processing may be performed by a distributed processing model.

[0082] Simultaneously, a model for estimating the final travel time is embedded in memory 204 and can be loaded via a route request and executed in processor 206. Processor 206 can use this model to send the final travel time along the route, including waypoints, to the vehicle 100. The final travel time estimation model is executed in the navigation application, and the navigation application generates travel trajectory data, including but not limited to waypoints and destinations, as well as event information about the route. The navigation application can send the travel trajectory data and event information, along with the final travel time, to the vehicle 100.

[0083] like Figure 4 As shown, the estimation model for the final travel time can include a dwell time estimation model that takes into account waypoint visits. Figure 4This is a schematic diagram illustrating a model used to estimate the final travel time.

[0084] Specifically, the final travel time estimation model can include an estimator, a dwell time estimation model, and a combiner.

[0085] The estimator can respond to a route request that includes waypoints by generating the expected arrival time for each waypoint based on the travel trajectory. The travel trajectory for each waypoint is provided by the navigation application and can be generated based on factors such as traffic conditions and distance to the waypoint. The generated travel trajectory can then be sent to the estimator.

[0086] The estimator can generate the initial travel time to the destination based on a non-stop travel trajectory through waypoints. The initial travel time can be the planned arrival time at the destination based on the non-stop travel through waypoints. The travel trajectory to the destination can be generated by a navigation application. The travel trajectory to the destination can be generated, for example, based on the total distance via waypoints, traffic conditions at departure, and dwell time at waypoints. The estimator described above can be constructed using machine learning models or rule-based models. Furthermore, in navigation, travel trajectory data can also be generated using machine learning models or rule-based models.

[0087] The dwell time estimation model can estimate the dwell time at waypoints based on the user information of vehicle 100 and the planned usage information of waypoints. That is, the dwell time estimation model can generate dwell time as output data by using user information and planned usage information as input data. The user information is the same as described above, and its detailed description is omitted.

[0088] Planned usage information may include detailed data on waypoints used by the user, as well as various data related to the user's planned usage time of the waypoints. Planned usage information may include, for example, waypoint data, estimated time intervals for the use of waypoints, and date characteristics associated with the dates of use of waypoints.

[0089] Waypoint data may include waypoint identifiers, waypoint types, and waypoint operational data. Waypoint data can be obtained using location information that matches the waypoints specified in the route request. Vehicle 100 can send the waypoint identifiers to server 200, allowing server 200 to identify the identifiers of locations that match the sent waypoint identifiers. Waypoint identifiers can use specific names of waypoints entered by the user without additional processing. Waypoint types and operational data can be obtained from the type and operational data of the locations that match the waypoint identifiers.

[0090] The estimated time interval can be an estimate of the time it takes for a user to arrive at a waypoint and be able to use the services at that waypoint. The estimated time interval can be determined based on the estimated arrival times of the waypoints generated by the estimator. Date characteristics can indicate the type of date on which a waypoint is accessed. For example, date characteristics can be defined as any of weekdays, weekends, and holidays, and can be defined in various ways.

[0091] The combiner can add the estimated dwell time at the waypoints to the initial travel time to the destination to generate the final travel time to the destination, which reflects the dwell time at the waypoints.

[0092] Reference Figure 5 Describe the dwell time estimation model in detail. Figure 5 This is a schematic diagram illustrating the structure of the dwell time estimation model.

[0093] Dwell time estimation models can use deep learning-based learning models. For example... Figure 5 As shown, the dwell time estimation model can be configured as an autoencoder model based on a convolutional neural network. In this disclosure, the model is exemplified as a convolutional neural network as described below, but it can be constructed using various types of deep learning models.

[0094] The estimation model can include an encoder and a decoder. The encoder outputs latent features of the input data (hereinafter simply referred to as features) based on the input data, and the decoder infers the dwell time based on these features. The encoder and decoder can be configured to include multiple layers of various types. For example, the encoder can be configured to have convolutional layers, filters (or convolutional kernels), and pooling layers. For example, the decoder can be configured to have deconvolutional layers and upsampling layers.

[0095] Input data can be processed to suit the encoder's input format. User information and planned usage information can be processed into multidimensional data that the encoder can recognize.

[0096] Figures 6A-6B This is a schematic diagram illustrating the data used in the dwell time estimation model. The encoder can generate features defined for each detailed data point belonging to user information and planned usage information, such as... Figure 6A As shown. Figure 6A and Figure 6B The POIs shown represent points of interest, and in the following text, they can be understood to be located at essentially the same locations as waypoints. POI numbers can be numbers that identify each waypoint.

[0097] The output data could be, for example, an estimated dwell time at a user-requested waypoint within a predetermined time period. As another example, such as... Figure 6BAs shown, the output data can be the estimated dwell time of all waypoints managed by server 200 for each time period. Here, the estimated dwell time can be output as the dwell time of waypoints matching the user information of the route requesting user. The estimation model can be decoded or further processed to output only the dwell time corresponding to the user's waypoint among all the estimated dwell times of all waypoints.

[0098] The dwell time estimation model can be trained using the actual dwell time at waypoints and the corresponding learning input data.

[0099] The learning input data may include user information for multiple users accessing the route of vehicle 100 by requesting waypoints, as well as usage information for multiple waypoints. User attribute data in the user information may include at least one of the user's age and gender. Driving data in the user information may include the distance from the origin to the waypoint. The usage information for waypoints may have data similar to planned usage information. Usage information may include location information for multiple waypoints accessed by multiple users, the access time interval for each waypoint, and the access date characteristics for each waypoint. Location information includes location data corresponding to the waypoints, such as identifiers, types, operational data, and may also include other data belonging to the location information.

[0100] The actual dwell time at waypoints can be used as ground-based data for the estimation model to learn. Here, the waypoints described in the description of ground-based data can include not only intermediate destinations on a route that includes a waypoint, but also the final destination that is directly accessible without a waypoint. The final destination can be a point of interest associated with a location that provides a specific service to the user. In this disclosure, for ease of description, waypoints are used in the same sense as points of interest, and in a sense that includes both intermediate and final destinations; these terms are used interchangeably.

[0101] like Figure 6B As shown, ground-based real-world data can be provided as the actual dwell time at each of multiple waypoints visited by multiple users. The actual dwell time can be obtained using previous driving trajectory data for each waypoint visited by multiple users. The previous driving trajectory data can correspond to the previous driving data of the vehicles used by the users. That is, the user's actual dwell time can be the actual dwell time of the vehicle calculated for each waypoint. The actual dwell time can be generated based on the time data collected from the previous driving trajectory data of multiple vehicles at each waypoint. Here, the time data can include the arrival time and departure time of the waypoint. The actual dwell time can be the time each user spends at each waypoint within the usage time interval.

[0102] useFigure 7 The example details the process of collecting actual dwell time, which can be generated based on vehicle trajectory data for each usage time period at a point of interest (POI) m corresponding to a specific waypoint. Actual dwell time can be calculated as the average dwell time of vehicles at POI m. Furthermore, to facilitate examination of actual dwell time for each time period and reduce computational resources for the output data, actual dwell time can be calculated as the average of the cumulative values ​​of actual dwell time belonging to that time period. Therefore, the estimated dwell time output from the estimation model can be provided as an average dwell time derived from the analysis of user information and planned usage information.

[0103] Furthermore, actual dwell time can be generated based on hourly dwell times collected over a period of time. The average actual dwell time can be calculated by assigning higher weights to recently collected dwell times by time interval and lower weights to dwell times by past time intervals. That is, actual dwell time utilizes the accumulated dwell time of vehicles through previous waypoint usage and can be generated as a weighted average of the accumulated dwell times. The weighted average can assign relatively low weights to previously collected dwell times. Here, the use of a point of interest can have the same meaning as the use of a waypoint, and the dwell time of a point of interest can also be referred to as the waypoint dwell time.

[0104] like Figure 7 As shown, the actual dwell time at point of interest m is the minimum dwell time ( ) and extra stay time ( The sum of these values. Additional dwell time can be congestion dwell time. The minimum dwell time can be set for each waypoint based on the analysis of user and usage information. Therefore, the estimation model will not output excessively low and essentially ineffective dwell times, and can output dwell times equal to or longer than the effective minimum dwell time. That is, the dwell time output from the estimation model can be generated to be equal to or longer than the minimum dwell time derived from the analysis of user and planned usage information.

[0105] Server 200 can be trained using learning requirement data and actual dwell time. Figure 5 The learnable parameters of the dwell time estimation model are shown below, namely, the weights. The estimation model can be trained until the loss function between the estimated dwell time and the actual dwell time is less than or equal to a predetermined value, or the change in the value of the loss function converges to a predetermined range. The loss function uses, for example, mean squared error, but is not limited to this.

[0106] Based on the aforementioned training dwell time estimation model, server 200 can use this estimation model to estimate the dwell time at waypoints associated with route requests that include waypoints. In the following text, reference will be made to...Figures 1-8 The congestion estimation process of server 200, including the aforementioned processor 206, is described in detail.

[0107] Figure 8 This is a flowchart of a travel time estimation method according to another embodiment of the present disclosure.

[0108] In this disclosure, the electronic device requesting route guidance including waypoints is shown as vehicle 100, and the electronic device processing the request is shown as server 200. However, this disclosure is also substantially applicable to embodiments where the electronic device is a user's portable terminal. Furthermore, provided there are no technical inconsistencies, embodiments of this disclosure can also be applied to embodiments where a model embedded in server 200 is sent to vehicle 100 or a user's mobile terminal, causing vehicle 100 or the mobile terminal to generate travel trajectory data to the destination and estimate the final travel time to the destination using the model. For ease of description, processor 206 and controller 118 can be described interchangeably with server 200 and vehicle 100, respectively.

[0109] First, the user can request a route including waypoints and destinations via the navigation unit 108 of the vehicle 100, and send the route to the server 200 (S105).

[0110] Users can enter the points of interest and the destination in the navigation unit 108. Figure 3 The details of the waypoint and destination inputs are described in detail.

[0111] Next, the processor 206 of server 200 can predict the planned arrival time of the waypoints (S110).

[0112] Processor 206 can be used Figure 4 The estimator shown estimates the planned arrival time. For example, processor 206 can generate the planned arrival time of the waypoint and the driving trajectory data to the waypoint based on the time of the request and the expected traffic conditions to the waypoint. The driving trajectory data can be generated by a navigation application driven by processor 206.

[0113] Next, the processor 206 of the server 200 can obtain the user information of the vehicle user and the planned usage information of the waypoints (S115).

[0114] User information may include user attribute data and driving data. User attribute data may include at least one of the user's age and gender. For example, user attribute data can be received from vehicle 100. Driving data includes, but is not limited to, the distance from the starting point to the waypoints, and may also include the aforementioned data. Driving data can be obtained from the driving trajectory data of the waypoints described in step S110.

[0115] Planned usage information may include waypoint data, estimated time intervals for using waypoints, and date characteristics associated with the dates of use of waypoints. Waypoint data can be received from vehicle 100, which is input by the user. The estimated time interval is determined based on the planned arrival time, and the date characteristics can be any of weekdays, weekends, and holidays. Other details are the same as described above.

[0116] Next, the processor 206 of the server 200 can estimate the dwell time at the waypoints based on user information and planned usage information (S120).

[0117] The dwell time at waypoints can be estimated using a deep learning-based dwell time estimation model. The dwell time estimation model can be... Figure 5 The diagram shows an autoencoder model based on a convolutional neural network. The estimated dwell time can be an average dwell time derived from the analysis of user information and planned usage information. Furthermore, the estimated dwell time can be generated to be equal to or longer than a minimum dwell time derived from the analysis of user information and planned usage information. Figure 5 The other structures and operations of the estimation model are not described in the document.

[0118] Next, the processor 206 can predict the final travel time to the destination based on the estimated dwell time and send the route information to the destination to the vehicle 100 (S125).

[0119] Specifically, processor 206 can use an estimator to generate the preliminary travel time to the destination. The preliminary travel time can be the expected time to simply pass through waypoints without stopping at them and directly reach the destination. Processor 206 can generate preliminary travel trajectory data using expected traffic conditions based on at least one of the time of the route request and the expected dwell time at waypoints, as determined by a navigation application. The estimator can then reference the preliminary travel trajectory data to output the preliminary travel time to the destination.

[0120] Then, processor 206 can use a combiner to sum the initial travel time to the destination and the estimated dwell time at waypoints to estimate the final travel time to the destination. Processor 206 can then generate final travel trajectory data based on anticipated traffic conditions after the dwell time (not the expected dwell time at waypoints) using a navigation application. The final travel trajectory data reflecting the dwell time may differ from the travel trajectory data to the destination that does not reflect the dwell time. Furthermore, the final travel time can be generated by referring to the final travel trajectory data.

[0121] Figure 9 This is a diagram comparing the travel time estimates based on conventional methods and this embodiment.

[0122] Standard route guidance provides a route to the destination and a planned arrival time based on the assumption that the driver simply passes through the waypoints without stopping. This makes it difficult for drivers who actually stop and arrive at their destination to accurately determine their final planned arrival time. Using standard route guidance, users may experience inconvenience as they have to re-search for routes by estimating the stop times in the route request for their destination. Furthermore, because standard route guidance does not reflect traffic conditions after the stop times, it may result in inappropriate routes due to traffic congestion.

[0123] According to this embodiment, since the dwell time at different waypoints is estimated based on the characteristics and preferences of the user driving the vehicle, the estimated arrival time at the destination can reflect a personalized estimated dwell time. Furthermore, a route to the destination based on expected traffic conditions after the dwell time can be provided to the user. Therefore, the estimated arrival time at the destination can be customized and more accurate. The route to the destination can also be provided to the user more appropriately.

[0124] According to this disclosure, methods and apparatus for estimating travel time can be provided, which accurately predict the estimated arrival time of a destination in route guidance including waypoints.

[0125] Specifically, since the dwell time at waypoints varies depending on the vehicle user's preferences, providing the arrival time at the final destination based on the estimated dwell time at waypoints according to the user's preferences can enhance the convenience of using navigation.

[0126] The effects obtained in this disclosure are not limited to those described above, and those skilled in the art can clearly understand from the following description other effects not mentioned above.

[0127] Although the exemplary methods of this disclosure described above are represented as a series of operations for clarity of description, they are not intended to limit the order in which the steps are performed, and these steps may be performed simultaneously or in different orders if necessary. To implement the methods according to this disclosure, the described steps may also include other steps, including remaining steps in addition to some steps, or additional steps in addition to some steps.

[0128] The various embodiments of this disclosure are not a list of all possible combinations and are intended to describe representative aspects of this disclosure. The contents described in the various embodiments can be applied independently or in combination of two or more.

[0129] Furthermore, various embodiments of this disclosure can be implemented in hardware, firmware, software, or combinations thereof. When implementing this disclosure in hardware, it can be implemented using application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers, microprocessors, etc.

[0130] The scope of this disclosure includes software or machine-executable commands (e.g., operating systems, applications, firmware, programs, etc.) for enabling the operation of methods according to various embodiments to be executed on a device or computer, and a non-transitory computer-readable medium having such software or commands stored thereon and executable on a device or computer.

Claims

1. A method for estimating the travel time of a route including waypoints, the method comprising: A memory configured to store at least one instruction and a processor configured to execute the at least one instruction stored in the memory are provided; In response to a vehicle route request that includes the waypoint, the processor predicts the estimated arrival time of the waypoint; The processor estimates the dwell time at each waypoint based on the vehicle's user information and the planned usage information of the waypoints. as well as The processor predicts the final travel time to the destination based on the estimated dwell time.

2. The method according to claim 1, wherein, The user information includes user attribute data and driving data. The user attribute data includes at least one of the user's age and gender, and the driving data includes the distance to the waypoints.

3. The method according to claim 1, wherein, The planned usage information includes waypoint data, estimated time intervals for using the waypoints, and date characteristics associated with the usage dates of the waypoints. The waypoint data includes the identifier of the waypoint, the type of the waypoint, and the operational data of the waypoint, and the estimated time interval is determined based on the estimated arrival time.

4. The method according to claim 3, wherein, The date characteristic is defined as any one of weekdays, weekends, and holidays.

5. The method according to claim 1, wherein, Estimating the dwell time at the waypoints includes using a deep learning-based dwell time estimation model to estimate the dwell time.

6. The method according to claim 5, wherein, The dwell time estimation model uses an autoencoder model based on a convolutional neural network.

7. The method according to claim 5, wherein, The estimated dwell time is an average dwell time derived from the analysis of the user information and the planned usage information.

8. The method according to claim 5, wherein, The estimated dwell time is generated to be equal to or longer than the minimum dwell time derived from the analysis of the user information and the planned usage information.

9. The method according to claim 5, wherein, The actual dwell time used for learning the dwell time estimation model is generated based on time data from previous driving trajectory data of the waypoints, and the time data includes the arrival time and departure time of the waypoints.

10. The method according to claim 5, wherein, The actual dwell time used for learning the dwell time estimation model utilizes the dwell time accumulated through previous waypoint usage and is generated as a weighted average of the accumulated dwell times, with the weighted average assigning lower weights to dwell times collected relatively earlier.

11. An electronic device comprising: A communication unit for sending data to and receiving data from an external device; The memory is configured to store at least one instruction; as well as A processor is configured to execute the at least one instruction stored in the memory, wherein the processor is configured to: In response to a vehicle route request that includes waypoints, predict the estimated arrival time of the waypoints; The dwell time at each of the waypoints is estimated based on the vehicle's user information and the planned usage information of the waypoints. and The estimated dwell time is used to predict the final travel time to the destination.

12. The electronic device according to claim 11, wherein, The user information includes user attribute data and driving data. The user attribute data includes at least one of the user's age and gender, and the driving data includes the distance to the waypoints.

13. The electronic device according to claim 11, wherein, The planned usage information includes waypoint data, estimated time intervals for using the waypoints, and date characteristics associated with the usage dates of the waypoints. The waypoint data includes the identifier of the waypoint, the type of the waypoint, and the operational data of the waypoint, and the estimated time interval is determined based on the estimated arrival time.

14. The electronic device according to claim 13, wherein, The date characteristic is defined as any one of weekdays, weekends, and holidays.

15. The electronic device according to claim 11, wherein, Estimating the dwell time at the waypoints includes using a deep learning-based dwell time estimation model to estimate the dwell time.

16. The electronic device according to claim 15, wherein, The dwell time estimation model uses an autoencoder model based on a convolutional neural network.

17. The electronic device according to claim 15, wherein, The estimated dwell time is an average dwell time derived from the analysis of the user information and the planned usage information, or is equal to or longer than the minimum dwell time derived from the analysis of the user information and the planned usage information.

18. The electronic device according to claim 15, wherein, The actual dwell time used for learning the dwell time estimation model is generated based on time data from previous driving trajectory data of the waypoints, and the time data includes the arrival time and departure time of the waypoints.

19. The electronic device according to claim 15, wherein, The actual dwell time used for learning the dwell time estimation model utilizes the dwell time accumulated through previous waypoint usage and is generated as a weighted average of the accumulated dwell times, with the weighted average assigning lower weights to dwell times collected relatively earlier.

20. A non-transitory computer-readable medium comprising program instructions executable by a processor, the program instructions, when executed, causing the processor to perform the following operations: In response to a vehicle route request that includes waypoints, predict the estimated arrival time of the waypoints; Based on the vehicle's user information and the planned usage information of the waypoints, the dwell time at the waypoints is estimated; and The estimated dwell time is used to predict the final travel time to the destination.

Images