A driver order acceptance willingness preset method and device based on route prediction
By collecting and predicting drivers' real-time driving trajectories on the driver's client and generating order acceptance intention data using a lightweight time series model, the problem of delayed intent perception and resource waste in the ride-hailing matching architecture is solved, achieving efficient and accurate order matching.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- BEIJING BAILONG MAYUN TECH CO LTD
- Filing Date
- 2026-05-28
- Publication Date
- 2026-07-24
AI Technical Summary
Under the existing centralized matching architecture of ride-hailing services, the perception of drivers' order acceptance intentions is delayed, the manual setting process is cumbersome, and the system resource utilization rate is low, resulting in low matching accuracy and timeliness, and the inability to identify the potential intentions of drivers' real-time driving behavior.
Real-time driving trajectory data is collected from the driver's client, and a lightweight time-series prediction model is used for second-level perception to generate order acceptance intention data and upload it to the backend server to achieve dynamic matching.
It achieves second-level response and accurate matching of driver intentions, reduces the risk of driver distraction, and improves the accuracy of order matching and the efficiency of system resource utilization.
Smart Images

Figure CN122452869A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of mobile travel and ride-hailing service technology, specifically to a method and apparatus for presetting driver willingness to accept orders based on route prediction. Background Technology
[0002] With the development of mobile internet technology, ride-hailing services have become an important supplement to urban public transportation. Currently, mainstream ride-hailing platforms generally adopt a centralized order matching architecture. Under this architecture, the backend server aggregates the real-time locations of all online drivers and all pending orders, and matches drivers with orders through a complex global optimization algorithm.
[0003] To better match orders with drivers' individual needs, current technologies typically require drivers to manually set static order-accepting preferences in the front-end (mobile application), such as setting fixed routes, pick-up radius, or destinations. The back-end order matching engine then uses these static preference settings as filtering conditions or weighting factors during the calculation. This approach has the following inherent drawbacks: First, there is the issue of delayed response. Existing technology cannot detect the dynamic changes in a driver's driving intentions. For example, a driver may be driving empty towards a popular area, but there is a significant time lag between the generation of the intention and the system's perception of that intention through the driver's manual settings. During this time window, the backend order matching engine still matches based on old preferences or default settings, resulting in orders that do not match the driver's actual needs, leading to low matching accuracy and timeliness.
[0004] Second, there are operational complexity and safety issues. To keep order preferences and real-time intentions synchronized, drivers need to frequently analyze and update the settings of the app while driving. This not only increases the complexity of the interaction process but also introduces driving safety risks.
[0005] Third, there is a waste of system resources. The backend server needs to handle a large number of invalid matching calculation requests caused by intent mismatch, resulting in an unnecessary waste of computing resources and network bandwidth.
[0006] Fourth, the problem of one-sided intent recognition. Existing technologies rely entirely on driver input and cannot identify or utilize the driver's potential and continuous driving intentions based on real-time driving behavior. This results in the loss of key information for optimal matching and a poor user experience.
[0007] Therefore, there is an urgent need for a technical solution that can bring the ability to perceive driving intentions and generate order-accepting strategies down to the driver's end, enabling real-time and automated expression of order-accepting intentions. Summary of the Invention
[0008] This invention aims to solve the technical problems of delayed perception of driver order acceptance intention, cumbersome manual setting operation, and low system resource utilization under the existing centralized matching architecture of ride-hailing services. In this regard, this invention provides a method and device for presetting driver order acceptance intention based on route prediction, which realizes the perception and response of driver intention in seconds and forms a collaboration with the backend server, fundamentally solving the problems of delayed response and one-sided intention recognition.
[0009] In a first aspect, the present invention provides a method for pre-setting driver willingness to accept orders based on route prediction, applied to a driver client, comprising: Collect real-time driving trajectory data of the driver, which includes at least a position coordinate sequence, a speed sequence, and a heading angle sequence; The real-time driving trajectory data is input into a trained lightweight time-series prediction model, which outputs the predicted destination and the corresponding path affinity. The path affinity represents the matching confidence between the current real-time driving trajectory and the predicted destination. When the path affinity exceeds a preset threshold, order acceptance intention data is dynamically generated based on the predicted destination. The order acceptance intention data includes destination preference coordinates and dynamic order acceptance radius. The order acceptance intention data is uploaded to the backend server, and the order push result returned by the backend server is received. The order push result is obtained by matching drivers and orders based on the order acceptance intention data.
[0010] Furthermore, it also includes processing the real-time driving trajectory data: The latitude and longitude coordinates of the position coordinate sequence are converted into offsets relative to the previous position to construct a position offset sequence; The velocity sequence is normalized. The heading angle sequence is periodically encoded. The position offset sequence, the normalized velocity sequence, and the encoded heading angle sequence are constructed as the input feature tensor.
[0011] Furthermore, the step of inputting the real-time driving trajectory data into the lightweight time-series prediction model and outputting the predicted destination and corresponding path affinity includes: The input feature tensor is input into the lightweight temporal prediction model, and the sequence feature extraction layer in the lightweight temporal prediction model extracts the latent feature vector representing the driver's continuous driving intention from the input feature tensor. Based on the latent feature vector, the predicted destination category and the path affinity are output through parallel classification and regression branches, respectively, wherein the predicted destination category is mapped to the corresponding coordinate in a preset high-frequency destination dictionary.
[0012] Furthermore, the high-frequency destination dictionary is set in the following way: Periodically or triggered, the system queries the local storage for the driver's historical destination list within a preset historical period, extracts the coordinates of destinations that are reached more than a preset threshold, generates a high-frequency destination dictionary, and caches it locally.
[0013] Furthermore, it also includes an automatic degradation prediction step: The system detects the running status of the lightweight time series prediction model. When the lightweight time series prediction model fails to load or the time taken for a single inference calculation exceeds a preset time threshold, it automatically switches to the calculation engine based on geometric rules. The geometry-based calculation engine extracts destination coordinates from the cached high-frequency destination dictionary to form a historical destination coordinate set, and determines the predicted destination by calculating the cosine similarity between the radial interval of the current driving heading angle and the historical destination coordinate set.
[0014] Secondly, the present invention provides a driver order acceptance intention pre-setting device based on route prediction, applied to a driver client, comprising: The data acquisition module is used to collect the driver's real-time driving trajectory data, which includes at least a position coordinate sequence, a speed sequence, and a heading angle sequence. The route prediction module is used to input the real-time driving trajectory data into the trained lightweight time series prediction model and output the predicted destination and the corresponding path affinity, wherein the path affinity represents the matching confidence between the current real-time driving trajectory and the predicted destination. The willingness preset module is used to dynamically generate order acceptance willingness data based on the predicted destination when the path affinity exceeds a preset threshold. The order acceptance willingness data includes destination preference coordinates and dynamic order acceptance radius. The data communication module is used to upload the order acceptance intention data to the backend server and receive the order push result returned by the backend server. The order push result is obtained by matching drivers and orders based on the order acceptance intention data.
[0015] Furthermore, it also includes a data preprocessing module for processing the real-time driving trajectory data: The latitude and longitude coordinates of the position coordinate sequence are converted into offsets relative to the previous position to construct a position offset sequence; The velocity sequence is normalized. The heading angle sequence is periodically encoded. The position offset sequence, the normalized velocity sequence, and the encoded heading angle sequence are constructed as the input feature tensor.
[0016] Furthermore, the route prediction module includes: The feature extraction unit is used to input the input feature tensor into the lightweight temporal prediction model, and extract the latent feature vector representing the driver's continuous driving intention from the input feature tensor through the sequence feature extraction layer in the lightweight temporal prediction model. The dual-branch prediction output unit is used to output the predicted destination category and the path affinity respectively through parallel classification and regression branches based on the latent feature vector, wherein the predicted destination category is mapped to the corresponding coordinate in a preset high-frequency destination dictionary.
[0017] Furthermore, the high-frequency destination dictionary is set in the following manner: Periodically or triggered, the system queries the local storage for the driver's historical destination list within a preset historical period, extracts the coordinates of destinations that are reached more than a preset threshold, generates a high-frequency destination dictionary, and caches it locally.
[0018] Furthermore, it also includes a degradation prediction module, which is used to detect the running status of the lightweight time series prediction model. When the lightweight time series prediction model fails to load or the time taken for a single inference calculation exceeds a preset time threshold, it automatically switches to the calculation engine based on geometric rules. The geometry-based calculation engine extracts destination coordinates from the cached high-frequency destination dictionary to form a historical destination coordinate set, and determines the predicted destination by calculating the cosine similarity between the radial interval of the current driving heading angle and the historical destination coordinate set.
[0019] This invention provides a method and apparatus for pre-setting driver order acceptance intention based on route prediction, which offloads the core capabilities of route prediction and intention generation from the backend to the frontend driver client. By collecting high-frequency trajectory data in real time on the frontend and running a lightweight time-series model for local inference, it achieves second-level perception and structured expression of the driver's dynamic driving intention. The order acceptance intention data automatically generated and uploaded by the frontend can guide the backend order matching engine to perform more accurate order matching. This solution not only frees drivers from tedious manual settings and significantly reduces the risk of driver distraction, but also fundamentally solves the problem of delayed intention response, effectively improving the accuracy of order matching, the driver's order acceptance experience, and the overall resource utilization efficiency of the platform. Attached Figure Description
[0020] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 This is a flowchart illustrating a method for pre-setting driver order acceptance intention based on route prediction, provided in one embodiment of this application. Figure 2 This is a schematic diagram of the structure of a driver order acceptance intention preset device based on route prediction provided in one embodiment of this application; Figure 3 This is a schematic diagram of the structure of an electronic device provided in one embodiment of this application. Detailed Implementation
[0021] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0022] I. Meaning of Key Technical Terms To facilitate understanding of this invention, the meanings of key technical terms involved in this application are explained.
[0023] Driver app: refers to the application running on the mobile smart terminal device used by ride-hailing drivers, such as a smartphone or in-vehicle tablet.
[0024] Real-time driving trajectory data: refers to a series of time-series data that reflect the driver's current driving status, collected at a preset high frequency through the driver's client. It includes at least a sequence of position coordinates composed of latitude and longitude, an instantaneous speed sequence, and a driving heading angle sequence.
[0025] Structured: Data is organized and expressed in a predefined format with explicit semantic fields and data type constraints.
[0026] Lightweight time-series prediction model: refers to a machine learning model that is pre-trained and converted into a model suitable for loading and inference in the driver's end environment. Its parameter count and model file size are kept to a small scale. It is used to predict the driver's most likely destination and confidence level based on the input real-time driving trajectory data.
[0027] Predicted destination: refers to the coordinates of the destination that the driver is most likely to go to under the current driving trend, inferred by the lightweight time-series prediction model based on the real-time driving trajectory.
[0028] Path affinity: Used to characterize the confidence level of the match between the current real-time driving trajectory and the predicted destination, and can be a value between 0 and 1.
[0029] Order acceptance willingness data: This refers to a structured data object generated locally by the driver's client, used to express the driver's dynamic order acceptance preferences to the backend server. This data includes at least one desired destination preference coordinate and a dynamically calculated acceptable order acceptance radius.
[0030] High-frequency destination dictionary: refers to a data structure that is pre-built and cached locally on the driver's end. It contains the coordinates of the destinations that the driver frequently arrives at within a specific historical period, such as the past 24 hours, and assigns a unique category index to each coordinate point for the predictive model to perform fast classification mapping.
[0031] Degradation prediction mechanism: refers to a backup plan that is automatically activated when a lightweight time series prediction model fails to function properly. It estimates the driver's possible destination based on geometric calculation rules.
[0032] II. Method Examples This embodiment details a method for pre-setting driver willingness to accept orders based on route prediction. For example... Figure 1 As shown, the method mainly includes the following steps.
[0033] Step S101: Collect the driver's real-time driving trajectory data, which includes at least a position coordinate sequence, a speed sequence, and a heading angle sequence.
[0034] This step aims to address the problem in existing technologies where the backend cannot acquire driver driving dynamics in real time and at high frequency, leading to delays in intent perception. This invention achieves high-precision, high-frequency trajectory data acquisition by directly accessing the underlying capabilities of the mobile terminal's operating system through the driver client.
[0035] Specifically, the driver client, based on a cross-platform development framework such as React Native, encapsulates and calls native operating system interfaces through its JSBridge capability. For example, the implementation for different platforms includes: on iOS, calling the precise positioning capabilities of the Core Location framework and setting a high-precision navigation mode such as kCLLocationAccuracyBestForNavigation; on Android, calling the FusedLocation Provider interface and setting a high-precision priority strategy such as PRIORITY_HIGH_ACCURACY. Raw data points are collected at a preset frequency, for example, every 3 seconds. Each data point includes at least: latitude and longitude coordinates, instantaneous speed (m / s), heading angle (degrees), and a corresponding timestamp. The collected data is encapsulated into a structured data object containing a time-series sequence, namely a position coordinate sequence, a speed sequence, and a heading angle sequence, providing the data foundation for subsequent steps as real-time driving trajectory data.
[0036] This step, through proactive and high-frequency data collection at the front end, obtains a detailed driver trajectory, providing a high-quality data foundation for subsequent accurate intent prediction. Compared to existing technologies that rely solely on intermittently acquired driver location points from the back end, this invention can capture continuous changes in the driver's heading and speed, enabling real-time intent recognition.
[0037] Step S102: Input the real-time driving trajectory data into the trained lightweight time series prediction model, and output the predicted destination and the corresponding path affinity, wherein the path affinity represents the matching confidence between the current real-time driving trajectory and the predicted destination.
[0038] The raw real-time driving trajectory data suffers from inconsistencies in units and abrupt numerical changes, making it unsuitable for direct input into lightweight prediction models for effective inference. Therefore, it requires preprocessing the data, such as data from the past 30 locations over approximately 1.5 minutes, to convert it into standardized feature tensors that the model can efficiently utilize. The specific processing steps include: The absolute latitude and longitude coordinates in the position coordinate sequence are converted into offsets relative to the previous position to construct a position offset sequence. This is intended to eliminate the spatial translation bias caused by absolute coordinates and make the model focus on the relative motion trend of the learning trajectory. The velocity sequence is normalized, for example, by dividing the velocity value by a preset reference maximum velocity such as 40 m / s, and scaling it to the range of [0, 1] or [-1, 1] to unify the feature units and accelerate model convergence; The heading angle sequence is periodically encoded. Since there is a numerical change in the heading angle between 0° and 360°, direct input will cause difficulties in model learning. Preferably, the heading angle is encoded in two channels using sine and cosine functions to convert the single angle value into a continuous and smooth two-dimensional vector. The position offset sequence, normalized velocity sequence, and encoded heading angle sequence after the above processing are combined to construct a multidimensional input feature tensor, which serves as the standardized input for subsequent models.
[0039] This solves the problem of mismatch between the original real-time driving trajectory data and the model input requirements, and improves the stability and accuracy of model prediction.
[0040] The driver client loads and runs a pre-trained, format-converted (e.g., TensorFlow.js) lightweight time-series prediction model adapted to the driver client's runtime environment within its built-in runtime environment, such as JavaScript. The input feature tensor constructed in the preceding steps is input into this lightweight time-series prediction model, which outputs the predicted destination and corresponding path affinity. Specific steps include: The constructed input feature tensor is input into the lightweight time series prediction model. The sequence feature extraction layer inside the model, such as the Long Short-Term Memory Network (LSTM) or its variant, extracts the latent feature vector representing the driver's continuous driving intention from the input feature tensor. This latent feature vector is a highly compressed representation of the temporal correlation characteristics between the collection points in the input sequence. Following the sequence feature extraction layer, two output branches are connected in parallel: a classification branch, consisting of a classifier (e.g., a fully connected layer connected to a Softmax function) that outputs the predicted destination category. This category index maps to the corresponding coordinates in a pre-defined, cached local high-frequency destination dictionary. For example, if the model outputs a category index of 5, the corresponding coordinates (e.g., the latitude and longitude of a train station) are retrieved from the dictionary as the predicted destination. The regression branch consists of a regressor (e.g., a fully connected layer connected to a Sigmoid function) that outputs a value between 0 and 1, namely the path affinity. This value represents the confidence level between the current driving trajectory and the predicted destination. For example, a path affinity of 0.85 indicates that the driver client has an 85% confidence level that the driver is heading towards the predicted destination.
[0041] This step achieves second-level inference of driver intent by running a lightweight model on the front end. Compared with the existing technology that relies on manual input from the driver and batch processing on the back end, this invention achieves low-latency and seamless intent perception. Moreover, the model inference is completed locally, without the need to upload the original trajectory, thus protecting user privacy.
[0042] In a preferred embodiment, to ensure that the classification branch can quickly map to the predicted destination, the method also includes a local construction and maintenance mechanism for a high-frequency destination dictionary.
[0043] The driver client periodically, or under specific triggering conditions, such as early morning each day or when the application starts, queries a list of the driver's historical destinations within a preset historical period, such as the past 24 hours or 7 days, from local storage, such as an SQLite database. Through statistical analysis, destination coordinates that are reached more than a preset threshold, such as 3 times, are extracted. These are then merged with globally distributed hotspot destinations from the cloud, deduplicated, and sorted. A unique category index is assigned to each coordinate, generating a high-frequency destination dictionary, which is then cached in local storage or memory.
[0044] Through this mechanism, the category index output by the model can always be mapped to the driver's latest and most frequently visited personalized location, achieving a personalized intent prediction effect.
[0045] Step S103: When the path affinity exceeds a preset threshold, order acceptance intention data is dynamically generated based on the predicted destination. The order acceptance intention data includes destination preference coordinates and dynamic order acceptance radius.
[0046] This step aims to transform the abstract prediction results output by the model into structured instructions that can be directly used by the backend order matching engine. First, it determines whether the path affinity output in step S103 exceeds a preset threshold, such as 0.65.
[0047] If the path affinity exceeds a preset threshold, indicating that the model prediction has high confidence, then a structured order acceptance intention data is dynamically generated based on the predicted destination. This order acceptance intention data includes at least: destination preference coordinates, i.e., the latitude and longitude of the destination predicted in step S102; and a dynamic order acceptance radius, which is a value dynamically calculated based on the current vehicle speed and a preset time window, calculated using the following formula: The dynamic order-accepting radius represents the maximum range of detours a driver is willing to accept while driving to the predicted destination.
[0048] If the route affinity does not exceed the preset threshold, the driver client can choose to keep the previously successfully preset order acceptance settings or use the default no preference settings.
[0049] Step S104: Upload the order acceptance intention data to the backend server, receive the order push result returned by the backend server, and obtain the order push result by matching drivers and orders based on the order acceptance intention data.
[0050] The driver's client actively pushes the order acceptance intention data generated in step S103 to the designated interface of the backend server through a secure communication protocol such as HTTPS. After receiving this data, the backend server's order matching engine uses it as a high-priority matching factor to guide the driver-order matching calculation. It prioritizes orders whose destinations are close to the driver's preferred destination coordinates in the driver's willingness-to-acceptance data and whose pick-up distance is within the dynamic pick-up radius, recommending these orders to the driver. For example, the order matching engine performs the following calculations for each candidate order based on the driver's uploaded willingness-to-acceptance data: 1. Calculate the spherical distance to the order's destination. Let the destination coordinates of the order be (lat_o, lon_o), and the destination preference coordinates in the order acceptance intention data be (lat_d, lon_d). Calculate the spherical distance d (in meters) between the two points using the following formula: Where 'a' represents the square of the semi-versus function between the two destinations; It is the difference in latitude between the two destinations, expressed in radians: ; It is the difference in longitude between the two destinations, expressed in radians: ; c represents the angular distance between the two destinations; R is the Earth's radius, usually taken as 6371 kilometers.
[0051] 2. Compliance determination of order acceptance radius Calculate a matching radius S_radius for each order. If d ≤ acceptable_radius, then S_radius = 1; If d > acceptable_radius, then S_radius decays proportionally to the excess, for example: Wherein, acceptable_radius represents the dynamic order acceptance radius; For example, the attenuation coefficient is set to 0.5, meaning that this score is zero when the dynamic order receiving radius exceeds 50%.
[0052] 3. Generate a willingness matching factor by combining path affinity. The path affinity (route_affinity) is directly combined with the order acceptance radius matching score to generate a willingness matching factor (M_intent): The value range of M_intent remains [0, 1], which comprehensively reflects the prediction confidence and the tolerance for order destination deviation.
[0053] 4. Integrate into the overall scoring For example, the willingness matching factor is included as a new, high-weighted additional item in the final driver-order composite score calculation, and the composite score is calculated according to the following formula. : Where S_global is the global efficiency factor, and S_order is the order urgency factor. , and The weights for each rating factor and the weights for the intention matching factor. The preferred setting is 0.5~0.8. , Based on experience, the settings are configured to reflect a strategy that prioritizes meeting the driver's real-time intentions.
[0054] The driver's client then receives the order push results returned by the backend server, which are matched based on the above comprehensive score.
[0055] This step replaces the traditional method of uploading massive amounts of raw GPS data or relying on static settings by proactively uploading highly refined order acceptance intention data from the front end. This not only significantly reduces network transmission load but also enables the backend order matching engine to perform more accurate matching calculations from the source, reducing invalid calculations and improving the overall system's resource utilization efficiency.
[0056] Considering the performance of mobile devices, network environment, or the complexity of model files, lightweight time series prediction models may face the risk of loading failure or excessively long inference times. Therefore, this method embodiment also includes an automatic degradation prediction step: The driver client continuously monitors the running status of the lightweight time series prediction model. When it detects that the lightweight time series prediction model fails to load or that the time taken for a single inference calculation exceeds a preset time threshold, the prediction task is automatically switched to a geometric rule-based computing engine for processing.
[0057] The workflow of this computing engine is as follows: Extract all destination coordinates from the preset and cached high-frequency destination dictionary to form a historical destination coordinate set; Calculate the radial interval of the current heading angle, for example, a sector area of ±30 degrees of heading angle; The system iterates through the historical destination coordinate set, calculates the azimuth angle of each coordinate point relative to the current location, and compares it with the cosine similarity of the radial intervals mentioned above. The destination coordinates with the highest cosine similarity (i.e., the most consistent direction and reasonable straight-line distance) are selected as the predicted output.
[0058] Through this automatic degradation prediction step, even when the core lightweight time-series prediction model is unavailable, the driver client can still provide a destination prediction based on common sense inference that has some reference value, ensuring the robustness and continuity of the overall service.
[0059] The following example demonstrates the complete process of the method of this invention, from data collection to strategy execution, through a real-world operational scenario.
[0060] Scenario Example: After dropping off passengers at Terminal 3 of Beijing Capital International Airport, driver Mr. Zhang drove his empty car away from the airport towards the city center.
[0061] Data collection: The driver's client continuously collects Mr. Zhang's driving trajectory at 3-second intervals. The data sequence shows that he is traveling south along the airport expressway at a speed of approximately 90 km / h, with a heading angle stable at around 180°.
[0062] Preprocessing and Prediction: The application preprocesses 30 trajectory points from the past 1.5 minutes, including coordinate offsetting, velocity normalization, and sine and cosine encoding of heading angles, constructing feature tensors to input into the local model. Model inference takes 45 milliseconds, and the output is: predicted destination is Beijing South Railway Station (coordinates 39.8651, 116.3783), with a path affinity of 0.82.
[0063] Willingness generation: Since 0.82 > preset threshold 0.65, a dynamic order-accepting radius of about 3 kilometers is dynamically calculated, and order-accepting willingness data containing the destination preference of Beijing South Railway Station and the dynamic order-accepting radius is generated.
[0064] Upload and Matching: The data is uploaded to the backend server in real time, and the backend order matching engine then calculates and prioritizes an order for Mr. Zhang with the origin located along the airport expressway and the destination being the business district near Beijing South Railway Station.
[0065] Result received: Mr. Zhang's mobile phone received the order push notification with extremely high route accuracy, achieving efficient empty driving order acceptance without any manual settings.
[0066] III. Device Examples See Figure 2 Another embodiment of the present invention provides a driver order acceptance intention preset device 200 based on route prediction. This device is configured on a driver client and includes a data acquisition module 201, a route prediction module 202, an intention preset module 203, and a data communication module 204. This device 200 is capable of executing the driver order acceptance intention preset method based on route prediction in the method embodiment.
[0067] Specifically, the device 200 includes: The data acquisition module 201 is used to call the native operating system interface through a cross-platform development framework to collect the driver's real-time driving trajectory data at a preset frequency. The real-time driving trajectory data includes at least a position coordinate sequence, a speed sequence, and a heading angle sequence.
[0068] The route prediction module 202 is used to load a pre-trained lightweight time series prediction model, input the input feature tensor into the lightweight time series prediction model, and output the predicted destination and the corresponding path affinity.
[0069] The intention preset module 203 is used to dynamically generate order acceptance intention data based on the predicted destination when the path affinity exceeds a preset threshold. The order acceptance intention data includes destination preference coordinates and dynamic order acceptance radius.
[0070] The data communication module 204 is used to upload the order acceptance intention data to the backend server and receive the order push result returned by the backend server. The order push result is obtained by the order matching engine of the backend server based on the order acceptance intention data to match drivers and orders.
[0071] It should be noted that the technical solutions corresponding to the route prediction-based driver order acceptance intention preset device 200 provided in this embodiment, which can be used to execute various method embodiments, have similar implementation principles and technical effects to the methods, and will not be repeated here.
[0072] Figure 3 This is a schematic diagram of an electronic device 300 provided in another embodiment of the present invention. The electronic device 300 is used to implement the driver order acceptance intention presetting method based on route prediction in the method embodiment. The electronic device 300 in the embodiments of the present invention may include, but is not limited to, smartphones, tablet computers, in-vehicle intelligent terminals, etc. Figure 3 The electronic device 300 shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments of the present invention.
[0073] like Figure 3 As shown, the electronic device 300 may include a processing device (e.g., a central processing unit, a graphics processing unit, etc.) 301, which can perform various appropriate actions and processes to implement the methods of the embodiments described herein, based on a program stored in a read-only memory (ROM) 302 or a program loaded from a storage device 308 into a random access memory (RAM) 303. The RAM 303 also stores various programs and data required for the operation of the electronic device 300. The processing device 301, ROM 302, and RAM 303 are interconnected via a bus 305. An input / output (I / O) interface 304 is also connected to the bus 305.
[0074] Typically, the following devices can be connected to I / O interface 304: input devices 306 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, GPS modules, etc.; output devices 307 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 308 including, for example, solid-state drives, flash memory, etc.; and communication devices 309. Communication device 309 allows electronic device 300 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 3 An electronic device 300 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively.
[0075] The above description is merely a preferred embodiment of the present invention. Those skilled in the art should understand that the scope of disclosure in this invention is not limited to the specific combination of the above-described technical features, but should also cover other technical solutions formed by any combination of the above-described technical features or their equivalents without departing from the above-described concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this invention.
Claims
1. A method for pre-setting driver willingness to accept orders based on route prediction, characterized in that... Applied to driver clients, including: Collect real-time driving trajectory data of the driver, which includes at least a position coordinate sequence, a speed sequence, and a heading angle sequence; The real-time driving trajectory data is input into a trained lightweight time-series prediction model, which outputs the predicted destination and the corresponding path affinity. The path affinity represents the matching confidence between the current real-time driving trajectory and the predicted destination. When the path affinity exceeds a preset threshold, order acceptance intention data is dynamically generated based on the predicted destination. The order acceptance intention data includes destination preference coordinates and dynamic order acceptance radius. The order acceptance intention data is uploaded to the backend server, and the order push result returned by the backend server is received. The order push result is obtained by matching drivers and orders based on the order acceptance intention data.
2. The method for pre-setting driver order acceptance intention based on route prediction according to claim 1, characterized in that, It also includes processing the real-time driving trajectory data: The latitude and longitude coordinates of the position coordinate sequence are converted into offsets relative to the previous position to construct a position offset sequence; The velocity sequence is normalized. The heading angle sequence is periodically encoded. The position offset sequence, the normalized velocity sequence, and the encoded heading angle sequence are constructed as the input feature tensor.
3. The method for pre-setting driver order acceptance intention based on route prediction according to claim 2, characterized in that, The step of inputting the real-time driving trajectory data into the lightweight time-series prediction model and outputting the predicted destination and corresponding path affinity includes: The input feature tensor is input into the lightweight temporal prediction model, and the sequence feature extraction layer in the lightweight temporal prediction model extracts the latent feature vector representing the driver's continuous driving intention from the input feature tensor. Based on the latent feature vector, the predicted destination category and the path affinity are output through parallel classification and regression branches, respectively, wherein the predicted destination category is mapped to the corresponding coordinate in a preset high-frequency destination dictionary.
4. The method for pre-setting driver order acceptance intention based on route prediction according to claim 3, characterized in that, The high-frequency destination dictionary is configured in the following way: Periodically or triggered, the system queries the local storage for the driver's historical destination list within a preset historical period, extracts the coordinates of destinations that are reached more than a preset threshold, generates a high-frequency destination dictionary, and caches it locally.
5. The method for pre-setting driver order acceptance intention based on route prediction according to claim 4, characterized in that, It also includes an automatic degradation prediction step: The system detects the running status of the lightweight time series prediction model. When the lightweight time series prediction model fails to load or the time taken for a single inference calculation exceeds a preset time threshold, it automatically switches to the calculation engine based on geometric rules. The geometry-based calculation engine extracts destination coordinates from the cached high-frequency destination dictionary to form a historical destination coordinate set, and determines the predicted destination by calculating the cosine similarity between the radial interval of the current driving heading angle and the historical destination coordinate set.
6. A driver order acceptance intention preset device based on route prediction, characterized in that... Applied to driver clients, including: The data acquisition module is used to collect the driver's real-time driving trajectory data, which includes at least a position coordinate sequence, a speed sequence, and a heading angle sequence. The route prediction module is used to input the real-time driving trajectory data into the trained lightweight time series prediction model and output the predicted destination and the corresponding path affinity, wherein the path affinity represents the matching confidence between the current real-time driving trajectory and the predicted destination. The willingness preset module is used to dynamically generate order acceptance willingness data based on the predicted destination when the path affinity exceeds a preset threshold. The order acceptance willingness data includes destination preference coordinates and dynamic order acceptance radius. The data communication module is used to upload the order acceptance intention data to the backend server and receive the order push result returned by the backend server. The order push result is obtained by matching drivers and orders based on the order acceptance intention data.
7. A driver order acceptance intention preset device based on route prediction according to claim 6, characterized in that, It also includes a data preprocessing module for processing the real-time driving trajectory data: The latitude and longitude coordinates of the position coordinate sequence are converted into offsets relative to the previous position to construct a position offset sequence; The velocity sequence is normalized. The heading angle sequence is periodically encoded. The position offset sequence, the normalized velocity sequence, and the encoded heading angle sequence are constructed as the input feature tensor.
8. A driver order acceptance intention preset device based on route prediction according to claim 7, characterized in that, The route prediction module includes: The feature extraction unit is used to input the input feature tensor into the lightweight temporal prediction model, and extract the latent feature vector representing the driver's continuous driving intention from the input feature tensor through the sequence feature extraction layer in the lightweight temporal prediction model. The dual-branch prediction output unit is used to output the predicted destination category and the path affinity respectively through parallel classification and regression branches based on the latent feature vector, wherein the predicted destination category is mapped to the corresponding coordinate in a preset high-frequency destination dictionary.
9. A driver order acceptance intention preset device based on route prediction according to claim 8, characterized in that, Furthermore, the high-frequency destination dictionary is set in the following manner: Periodically or triggered, the system queries the local storage for the driver's historical destination list within a preset historical period, extracts the coordinates of destinations that are reached more than a preset threshold, generates a high-frequency destination dictionary, and caches it locally.
10. A driver order acceptance intention preset device based on route prediction according to claim 8, characterized in that, It also includes a degradation prediction module, which is used to detect the running status of the lightweight time series prediction model. When the lightweight time series prediction model fails to load or the time taken for a single inference calculation exceeds a preset time threshold, it automatically switches to the calculation engine based on geometric rules. The geometry-based calculation engine extracts destination coordinates from the cached high-frequency destination dictionary to form a historical destination coordinate set, and determines the predicted destination by calculating the cosine similarity between the radial interval of the current driving heading angle and the historical destination coordinate set.