Driver side navigation switching management method and system

Abstract

The invention discloses a driver side navigation switching management method and system. The invention relates to the field of intelligent traffic and mobile application development. Passenger order information (such as new order generation and order state change) from a scheduling system is continuously monitored; acquiring the current navigation state (destination, route planning, driving state and the like) of the driver in real time; switching condition judgment is carried out; if the driver is in common navigation and receives a passenger order, calling a preset judgment table based on the order emergency degree and the predicted arrival time of the driver, and if judging that a switching condition is met, triggering a navigation switching process; according to the system, the navigation switching response time is compressed from the second level to the millisecond level through an active mechanism of order triggering and state sensing, and a driver can complete switching without manual operation. A map SDK asynchronous calling technology is adopted, parameter transmission and state cleaning are completed in the background, and the switching success rate is increased.

Description

Technical Field

[0001] This invention relates to the field of intelligent transportation and mobile application development, specifically driver-side applications for travel service platforms such as ride-hailing and taxis. It involves map navigation technology, order management technology, and optimization of the user interaction experience, aiming to improve driver efficiency in complex navigation scenarios and enhance passenger service quality. In particular, it relates to a driver-side navigation switching management method and system. Background Art

[0002] With the rapid development of mobile internet technology and the widespread adoption of smart mobile devices, the travel service industry, represented by online ride-hailing and taxi services, is undergoing profound changes and has become an indispensable component of modern urban residents' daily commutes. Leveraging mobile applications (apps) as a core platform, various travel service platforms have established efficient and convenient driver-passenger interaction systems, enabling precise order matching and real-time navigation services, significantly improving travel efficiency and service quality.

[0003] In actual operations, driver-side applications face complex and ever-changing navigation scenarios. On the one hand, there are standard navigation scenarios, where drivers independently choose to travel to specific areas based on their personal needs, such as commercial hotspots, restaurants, rest areas (restrooms), shopping malls, etc., to meet daily operations, living, or rest needs. On the other hand, passenger order navigation scenarios require drivers to quickly and accurately reach the passenger's designated location based on the order information assigned by the platform to complete the pick-up and drop-off service. These two navigation scenarios frequently alternate in drivers' daily work, posing a significant challenge to the navigation management functions of the driver-side application.

[0004] Currently, the driver-side app lacks a scientific, efficient, and orderly management mechanism for switching between passenger order navigation and standard navigation, resulting in a series of operational inconveniences and low service efficiency, as shown below:

[0005] (1) When a driver receives a new passenger order while performing normal navigation tasks, the system cannot automatically and instantly switch navigation modes. The driver is forced to manually interrupt the current navigation process and restart the passenger order navigation. This process not only increases the number of steps and distracts the driver's attention, but also may miss the best pick-up time due to switching delays, affecting service response speed.

[0006] (2) The management of multi-scenario navigation information is chaotic. In complex scenarios where passenger order navigation and general navigation coexist, the system fails to effectively integrate and prioritize various types of navigation information. Drivers may receive multiple navigation prompts on the navigation interface at the same time. These prompts lack a clear hierarchy and priority identification, resulting in information overload, increasing the driver's cognitive load and reducing the accuracy of navigation decisions.

[0007] To this end, the present invention proposes a driver-side navigation switching management method and system. Summary of the Invention

[0008] In view of this, the present invention aims to provide a driver-side navigation switching management method and system to solve or alleviate the technical problems existing in the prior art, namely, the technical problems of untimely navigation switching and confusing navigation information, and to provide at least a beneficial alternative. The technical solution of the present invention is achieved as follows:

[0009] First, the driver-side navigation switching management method:

[0010] (1) Overview:

[0011] This solution aims to optimize the navigation experience for online ride-hailing drivers, achieving efficient and accurate navigation services through four core modules: real-time monitoring, intelligent switching, priority management, and status feedback. The real-time monitoring module continuously monitors passenger orders and driver navigation status, providing data support for subsequent decision-making. The navigation switching mechanism, based on a preset judgment table, automatically and quickly interrupts normal navigation and switches to passenger order navigation, reducing the driver's manual operation. Status synchronization and cleanup ensure seamless navigation switching and avoid information confusion. Multi-scenario navigation priority management dynamically calculates and sorts navigation task priorities based on order type, urgency, and driver status, resolves conflicts, and ensures that high-priority tasks are processed first. At the same time, navigation prompt information is generated and displayed on the driver-side interface, supporting manual adjustment. Finally, the status update and feedback module synchronizes order and navigation status in real time, improving system transparency and driver operation convenience.

[0012] (2) Technical solution:

[0013] To achieve the above technical objectives, the present invention chooses to perform the following operating steps.

[0014] 2.1 Step S1, real-time monitoring module starts:

[0015] Continuously monitor passenger order information from the dispatch system (such as new order generation, order status changes, etc.); obtain the driver's current navigation status (destination, route planning, driving status, etc.) in real time.

[0016] 2.1.1 Step S100, monitoring passenger order information:

[0017] Subscribe to passenger order events in real time through the WebSocket or HTTP persistent connection interface provided by the dispatch system; event types include:

[0018] 1) New order: includes the passenger's origin, destination, estimated time of arrival (ETA), and urgency (normal / expedited).

[0019] 2) Status changes: the order is accepted, the driver starts navigating, the passenger cancels the order, etc.

[0020] Parse the raw order data into structured information (such as JSON format) and extract key fields (such as order ID, passenger location, destination); automatically mark the priority based on the urgency of the order (such as expedited order priority +3, ordinary order +1).

[0021] If the scheduling system interface is interrupted, the system automatically retries the connection, with the interval increasing exponentially (e.g., 1 second, 2 seconds, 4 seconds).

[0022] Cache the order data within the last 5 minutes to ensure that data is not lost during disconnection.

[0023] 2.1.2 Step S101: Get the driver's current navigation status:

[0024] Real-time destination location of the current navigation task through the API provided by the map SDK (such as Amap / Baidu);

[0025] Calling the route planning algorithm: Calculating the current route details (such as waypoints, estimated travel time), as well as whether the driver is navigating, whether they have deviated from the route, and the current speed;

[0026] 2.1.3 Step S103, data fusion and decision making:

[0027] Associate passenger order information with the driver's navigation status to calculate the straight-line distance between the passenger's starting point and the driver's current location; determine whether the new order conflicts with existing navigation (for example, if the driver is already picking up a passenger);

[0028] If the driver has no vehicles available and the order distance is ≤5 kilometers, the system will automatically trigger the order acceptance process; if the order is expedited, the priority will automatically increase by 2 levels;

[0029] If the driver accepts the order, the system will automatically terminate the current navigation task and switch to the new order navigation; if the driver does not accept the order, the system will retain the current navigation task and wait for the driver to manually process it.

[0030] If the new order conflicts with the existing navigation, the system will pop up a window to prompt the driver "Do you want to overwrite the current navigation?" and record the operation log; if the dispatch system interface is unavailable, the system will automatically fall back to the local cached data and push an alarm to the operation and maintenance center.

[0031] 2.2 Step S2, navigation switching mechanism execution:

[0032] Perform switching condition judgment; if the driver is in normal navigation and receives a passenger order: call the preset judgment table based on the order urgency and the driver's estimated arrival time, and if the switching condition is met, trigger the navigation switching process; if no order is received or the switching condition is not met, continue the current navigation;

[0033] 2.2.1 Step S200, switching condition judgment:

[0034] Determine whether the driver is currently in normal navigation mode (i.e., non-passenger navigation, such as free navigation to go home, pick up friends, etc.); confirm whether the driver has received a new passenger order (obtained through the real-time monitoring module in step S1);

[0035] Based on the order type (regular / expedited) and the passenger's notes (e.g., "Pregnant woman urgently needs a car"), an urgency score (e.g., 1 for regular orders, 3 for expedited orders) is extracted. The route planning API of the map SDK is called to calculate the estimated time of arrival (ETA) from the driver's current location to the passenger's starting point.

[0036] 2.2.2 Step S201, call the preset judgment table:

[0037] Order urgency (1-3 points);

[0038] Driver ETA (minutes); Rules:

[0039] (1) High priority rule: If the urgency is ≥ 2 points and the ETA is ≤ 10 minutes, a forced handover is triggered.

[0040] (2) Medium priority rule: If the urgency level = 1 point and ETA ≤ 5 minutes, trigger the recommended switch (a pop-up window prompts the driver).

[0041] (3) Low priority rule: If ETA>10 minutes, no switching is triggered and the current navigation continues.

[0042] 2.2.3 Step S202: triggering the navigation switching process:

[0043] If high-priority rules are met (such as urgency ≥ 2 points and ETA ≤ 10 minutes), the current navigation task is terminated immediately; the route planning API of the map SDK is called to re-plan the route to the passenger's starting point.

[0044] 2.3 Step S3, state synchronization and cleanup:

[0045] Communicate with the map SDK to record the end point of the current normal navigation (such as current location, remaining route, etc.); pass the passenger order navigation parameters (starting point, end point, estimated time, etc.) to the map SDK; call the SDK to start the passenger order navigation, and the background automatically completes the navigation switch.

[0046] 2.3.1 Step S300: Record the end point of the current normal navigation:

[0047] Call the map SDK's positioning interface (such as getCurrentLocation) to obtain the driver's current latitude and longitude coordinates (such as {lat:31.2304,lng:121.4737});

[0048] Call the route planning interface (such as getRemainingRoute) to extract the remaining route information of the current navigation;

[0049] 2.3.2 Step S301: Passing passenger order navigation parameters:

[0050] Extract key parameters from the order data received in step S1:

[0051] Starting point: The longitude and latitude of the passenger boarding point (e.g. {lat:31.2310,lng:121.4740}).

[0052] Destination: The longitude and latitude of the passenger's drop-off point (e.g. {lat:31.2350,lng:121.4800}).

[0053] Estimated time: ETA calculated based on real-time traffic conditions (e.g. 12 minutes).

[0054] Encapsulate the order parameters into a format supported by the Map SDK (such as JSON):

[0055] 2.3.3 Step S302: Call the SDK to start the passenger order navigation:

[0056] Call the navigation start interface of the map SDK (such as startNavigation) and pass in the encapsulated order parameters;

[0057] 2.3.4 Step S303, status cleanup and subsequent processing:

[0058] Stop real-time monitoring of the current normal navigation (such as location updates, route updates); close the old navigation session with the map SDK; mark the end point information of the old navigation as "archived" for subsequent query.

[0059] 2.4 Step S4, multi-scenario navigation priority management:

[0060] Dynamically calculate navigation task priority based on order type (passenger order / non-order navigation), urgency, and driver status parameters; call priority sorting to generate a navigation task priority list;

[0061] Real-time monitoring of navigation task priority conflicts (multiple high-priority orders arriving at the same time);

[0062] Select the best navigation task for processing and update the priority list;

[0063] Generate navigation prompt information (such as route planning, estimated arrival time, etc.) based on the priority list;

[0064] The current navigation task is displayed on the driver's interface, and manual adjustments (such as temporary cancellation, re-planning, etc.) are supported.

[0065] 2.4.1 Step S400, dynamically calculating navigation task priority:

[0066] Passenger orders (such as instant orders, reservation orders, and carpooling orders), and non-order navigation (such as drivers planning their own routes and returning empty trips).

[0067] Passenger orders are assigned an urgency value based on the order type (e.g., instant order = 5, scheduled order = 3); the default urgency value for non-order navigation is 1.

[0068] 2.4.2 Step S401: Generate a navigation task priority list:

[0069] Sort tasks from high to low priority to generate a task list; use a priority queue to store tasks to ensure efficient sorting and updating;

[0070] 2.4.3 Step S402: Real-time monitoring of navigation task priority conflicts:

[0071] Multiple high-priority orders arrive at the same time (e.g., three instant orders are assigned at the same time); if the priority difference is less than a threshold (e.g., 0.5), it is considered a conflict.

[0072] 2.4.4 Step S403: Select the optimal navigation task and update the list:

[0073] Take the highest priority task from the priority queue and mark it as "current task"; remove the selected task from the queue and recalculate the priority of the remaining tasks (such as the distance weighting changes due to the change of the driver's position).

[0074] 2.4.5 Step S404: Generate navigation prompt information:

[0075] Call the map SDK to generate the optimal route and return route details (passing roads or turn prompts).

[0076] 2.4.6 Step S405: Driver-side interface display and interaction

[0077] Display route map, ETA, order details (such as passenger name and contact information); display pending tasks in list format, support sliding switching; drivers can cancel the current task, and the system will automatically assign the next task; support drivers to manually adjust the route (such as avoiding congested sections) and call the SDK for re-planning.

[0078] 2.5 Step S5, status update and feedback:

[0079] Real-time synchronization of passenger order status (such as accepted, arrived, completed, etc.) to the dispatch system;

[0080] Regularly provide navigation status feedback to the driver app (e.g., driving, arrived, off-route, etc.);

[0081] (3) Mechanisms for resolving technical issues:

[0082] 3.1 Solution to the problem of untimely navigation switching:

[0083] The system monitors passenger orders (pushed by the dispatch system) and driver navigation status (feedback from the map SDK) in real time through dual channels. When a new order is detected and the driver is in normal navigation, it immediately initiates a switch condition assessment. This proactive "order trigger + status sensing" mechanism reduces switch response time to milliseconds, eliminating delays caused by manual driver operation.

[0084] Based on the preset judgment table (including parameters such as the urgency of the order, the driver's estimated arrival time, the remaining distance of the current navigation, etc.), accurate decision-making is achieved through a dynamic threshold algorithm (such as "the switch is triggered when the urgent order is ≤1km away from the driver and the remaining navigation time is >5 minutes"). Reduce misjudgments (such as frequent switching simply because the distance is short) and ensure that navigation switching is triggered only in reasonable scenarios. Using the map SDK asynchronous call technology, the parameter transfer (such as starting point, end point, route planning) and status cleanup (such as termination of the current navigation task) of the navigation switch are completed in the background. The driver only needs to confirm to complete the switch. Avoid switching failures due to network delays or interface freezes, and increase the switching success rate to more than 99%.

[0085] 3.2 Solution mechanism for navigation information confusion problem:

[0086] Before switching, the system records the current navigation's end point (e.g., current location, remaining route) through the Maps SDK and clears old navigation data (e.g., route cache, navigation prompts) to ensure that the new navigation data does not interfere with it. This prevents confusion caused by overlapping old navigation prompts with the new route. For example, the driver will not hear conflicting prompts such as "Turn right ahead" and "Continue straight" at the same time.

[0087] A prioritization algorithm dynamically calculates navigation task priorities based on parameters such as order type (passenger order / non-order), urgency (e.g., expedited orders receive a +30% weight), and driver status (e.g., orders currently carrying passengers receive a -20% weight), generating a single, highest-priority task. This ensures only one active navigation task exists at a time. For example, if a driver receives a new order while en route, the system automatically determines and retains the high-priority order, preventing multiple navigation prompts from appearing simultaneously.

[0088] The system synchronizes passenger order status (e.g., accepted, arrived) with the dispatch system in real time and pushes navigation status updates (e.g., "Deviated from route, re-planning") to the driver, ensuring they always have the latest information. This prevents operational confusion caused by information misalignment. For example, a driver will not continue navigating to the wrong destination if they haven't received an "order canceled" notification.

[0089] 3.3 Summary Table:

[0090]

[0091] Secondly, the driver-side navigation switching management system:

[0092] like Figure 3 As shown, the system is used to implement the driver-side navigation switching management method described above, which includes:

[0093] (1) Driver side: When an order is generated, the system automatically triggers navigation switching based on the driver's current navigation status (e.g., "Loading Passengers" or "Empty Vehicle"). The task list is sorted by priority (e.g., "Expedited Orders > Regular Orders > Non-Order Navigation").

[0094] Navigation status (e.g., "Deviated from route" or "Destination reached") is pushed to the driver in real time via WebSocket. Navigation records from the last seven days are saved and can be searched by date or order number.

[0095] Technical Implementation: Calling the navigation API of the AutoNavi / Baidu Map SDK to implement map SDK integrated functions such as route planning, real-time navigation, and voice broadcast. Caching the current navigation route and order information to ensure normal navigation in weak network environments.

[0096] (2) Passenger side: After the passenger enters the starting point and destination, the system automatically generates an order and pushes it to nearby drivers. Passengers can choose levels such as "normal" and "expedited" to affect navigation priority.

[0097] The passenger app displays the driver's current location and estimated time of arrival (ETA). Driver status changes, such as accepting orders, arriving, and starting navigation, are synchronized to the passenger app in real time.

[0098] If the driver doesn't accept the order within 10 minutes, the system will automatically prompt the passenger to "re-order" or "contact customer service." If the driver's navigation deviates from the route, the passenger's app will pop up a prompt saying "The driver may be lost" and display an option to re-route.

[0099] Technical Implementation: Based on WebSocket or persistent connection technology, real-time push notification of order status is achieved. Passenger location and order information are transmitted using AES encryption to ensure privacy and security.

[0100] (3) Map SDK: Supports multiple strategies such as "fastest route", "shortest route", and "avoid congestion". It monitors traffic conditions in real time and automatically replans routes.

[0101] Using GPS+Wi-Fi+Bluetooth hybrid positioning technology, the positioning accuracy is ≤ 5 meters. It supports setting virtual fences (such as schools and hospitals) and automatically triggers silent navigation.

[0102] Technical implementation: Cloud-based route calculation engine supports offline map downloads to ensure navigation capabilities in offline environments.

[0103] Compared with the prior art, the present invention has the following beneficial effects:

[0104] 1. Significantly improve navigation switching efficiency: The system uses a proactive "order trigger + state perception" mechanism to reduce navigation switching response time from seconds to milliseconds, enabling drivers to complete switching without manual intervention. Using map SDK asynchronous call technology, parameter transfer and state cleanup are completed in the background, improving switching success rates.

[0105] Second, completely resolve navigation information confusion: By prioritizing, only one active navigation task is retained at a time, avoiding the overlap of multiple navigation prompts (such as "Turn right ahead" and "Continue straight" playing simultaneously). The system synchronizes passenger order status (such as "Accepted" and "Arrived") with the dispatch system in real time and pushes navigation status updates (such as "Deviated from route, re-planning") to the driver to ensure information consistency.

[0106] 3. Enhance the driver's operating experience: According to the urgency of the order (such as the weight of expedited orders

[0107] Priority is dynamically adjusted based on parameters such as the driver's status (e.g., a -20% weighted order weight for a passenger in progress) to ensure that high-priority tasks are processed first. When a driver receives a new order while en route, the system automatically identifies and retains the high-priority order, avoiding the loss of efficiency caused by manual switching. The driver interface supports manual adjustment of navigation tasks (e.g., temporary cancellation or rescheduling), enhancing operational flexibility.

[0108] 4. Reduce operating costs and complaint rates: High success rate switching and information synchronization reduce idle mileage caused by navigation errors and reduce operating costs. BRIEF DESCRIPTION OF THE DRAWINGS

[0109] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or technical descriptions. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0110] Figure 1 Schematic diagram of the method steps of the present invention;

[0111] Figure 2 Schematic diagram of the method flow of the present invention;

[0112] Figure 3 Schematic diagram of the system composition of the present invention. DETAILED DESCRIPTION

[0113] To make the above-mentioned objects, features, and advantages of the present invention more clearly understood, the following detailed description of the specific embodiments of the present invention is given in conjunction with the accompanying drawings. The following description sets forth many specific details to facilitate a full understanding of the present invention. However, the present invention can be implemented in many other ways than those described herein, and those skilled in the art can make similar improvements without violating the scope of the present invention. Therefore, the present invention is not limited to the specific embodiments disclosed below.

[0114] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Reference can be made to the common and similar parts between the various embodiments. For the devices disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the description is relatively simple, and the relevant parts can be referred to the method description.

[0115] Explanation of relevant terms:

[0116] (1) Passenger order information: Details of the taxi request initiated by the passenger, such as starting point, end point, time, etc.

[0117] (2) Driver’s current navigation status: information about the driver’s ongoing navigation activities, such as destination, route, and driving status.

[0118] (3) Switching conditions: criteria for determining whether it is necessary to switch from normal navigation to passenger order navigation.

[0119] (4) Ordinary navigation: navigation activities not related to passenger orders, such as routes planned by the driver himself.

[0120] (5) Preset judgment table: a set of pre-set rules or standards used to decide whether to switch navigation.

[0121] (6) Navigation switching process: a series of operating steps to switch from normal navigation to passenger order navigation.

[0122] (7) End point of normal navigation: the location or status information at the end of normal navigation.

[0123] (8) Passenger order navigation parameters: Specific information required for passenger order navigation, such as starting point, end point, and estimated time.

[0124] (9) Map SDK: A software development kit that provides map display, route planning and other functions.

[0125] (10) Order type: the type or attributes of the order, such as passenger order, non-order navigation, etc.

[0126] (11) Urgency: The urgency or importance of the order may affect the priority of navigation switching.

[0127] (12) Driver status: The driver’s current status, such as idle, carrying passengers, resting, etc.

[0128] (13) Navigation task priority: The importance or urgency of the navigation task, used to determine the processing order.

[0129] (14) Prioritization: The process of sorting navigation tasks according to their priorities.

[0130] (15) Passenger order status: the current status of the passenger order, such as accepted, completed, etc.

[0131] Example: In ride-hailing, taxi, and other travel service scenarios, when a driver receives a passenger order while performing standard navigation (e.g., to a hotspot or restaurant), the system cannot automatically and quickly interrupt the current navigation and switch to the passenger order navigation. This forces the driver to manually operate, increasing operational complexity and easily missing the optimal pickup opportunity. Furthermore, when multiple navigation scenarios (passenger order navigation and standard navigation) coexist, the system lacks an effective information management mechanism, resulting in navigation prompt information overload and unclear priorities. This makes it difficult for drivers to make quick and accurate decisions, affecting service efficiency and quality.

[0132] For this reason, Figures 1-2 As shown, this embodiment provides a driver-side navigation switching management method to solve the above technical problems, including:

[0133] In this embodiment, regarding step S1, the real-time monitoring module is started:

[0134] Continuously monitor passenger order information from the dispatch system (such as new order generation, order status changes, etc.); obtain the driver's current navigation status (destination, route planning, driving status, etc.) in real time.

[0135] Specifically, step S100 monitors passenger order information: subscribe to passenger order events in real time through the WebSocket or HTTP persistent connection interface provided by the dispatch system; event types include:

[0136] 1) New order: includes the passenger's origin, destination, estimated time of arrival (ETA), and urgency (normal / expedited).

[0137] 2) Status changes: the order is accepted, the driver starts navigating, the passenger cancels the order, etc.

[0138] Parse the raw order data into structured information (such as JSON format) and extract key fields (such as order ID, passenger location, destination); automatically mark the priority based on the urgency of the order (such as expedited order priority +3, ordinary order +1).

[0139] If the scheduling system interface is interrupted, the system automatically retries the connection, with the interval increasing exponentially (e.g., 1 second, 2 seconds, 4 seconds).

[0140] Cache the order data within the last 5 minutes to ensure that data is not lost during disconnection.

[0141] Specifically, in step S101, the driver's current navigation status is obtained: the destination location of the current navigation task is obtained in real time through the API provided by the map SDK (such as Amap / Baidu);

[0142] Calling the route planning algorithm to calculate the current route details (such as waypoints, estimated travel time); as well as whether the driver is navigating, whether he has deviated from the route, and the current speed;

[0143] Navigation status classification:

[0144] 1) Empty vehicle navigation: Free navigation when the driver has no orders (such as going home or picking up friends).

[0145] 2) Passenger navigation: The driver is executing order navigation.

[0146] 3) Driving status:

[0147] 3.1) Stationary: Vehicle speed ≤ 5 km / h for ≥ 1 minute.

[0148] 3.2) Driving: Vehicle speed > 5km / h.

[0149] The driver's navigation status is cached in the local database to ensure fast query in a weak network environment; the cached data is valid for 2 minutes and will be automatically refreshed after expiration.

[0150] Specifically, step S103, data fusion and decision making:

[0151] Associate passenger order information with the driver's navigation status to calculate the straight-line distance between the passenger's starting point and the driver's current location; determine whether the new order conflicts with existing navigation (for example, if the driver is already picking up a passenger);

[0152] If the driver has no vehicles available and the order distance is ≤5 kilometers, the system will automatically trigger the order acceptance process; if the order is expedited, the priority will automatically increase by 2 levels;

[0153] If the driver accepts the order, the system will automatically terminate the current navigation task and switch to the new order navigation; if the driver does not accept the order, the system will retain the current navigation task and wait for the driver to manually process it.

[0154] If the new order conflicts with the existing navigation, the system will pop up a window to prompt the driver "Do you want to overwrite the current navigation?" and record the operation log; if the dispatch system interface is unavailable, the system will automatically fall back to the local cached data and push an alarm to the operation and maintenance center.

[0155] In this embodiment, regarding step S2, the navigation switching mechanism performs:

[0156] Perform switching condition judgment; if the driver is in normal navigation and receives a passenger order: call the preset judgment table based on the order urgency and the driver's estimated arrival time, and if the switching condition is met, trigger the navigation switching process; if no order is received or the switching condition is not met, continue the current navigation;

[0157] Specifically, in step S200, the switching condition is judged:

[0158] Determine whether the driver is currently in normal navigation mode (i.e., non-passenger navigation, such as free navigation to go home, pick up friends, etc.); confirm whether the driver has received a new passenger order (obtained through the real-time monitoring module in step S1);

[0159] Based on the order type (regular / expedited) and the passenger's notes (e.g., "Pregnant woman urgently needs a car"), an urgency score (e.g., 1 for regular orders, 3 for expedited orders) is extracted. The route planning API of the map SDK is called to calculate the estimated time of arrival (ETA) from the driver's current location to the passenger's starting point.

[0160] Specifically, in step S201, a preset judgment table is called:

[0161] Order urgency (1-3 points);

[0162] Driver ETA (minutes); Rules:

[0163] (1) High priority rule: If the urgency is ≥ 2 points and the ETA is ≤ 10 minutes, a forced handover is triggered.

[0164] (2) Medium priority rule: If the urgency level = 1 point and ETA ≤ 5 minutes, trigger the recommended switch (a pop-up window prompts the driver).

[0165] (3) Low priority rule: If ETA>10 minutes, no switching is triggered and the current navigation continues.

[0166] Urgency ETA (minutes) Switching suggestions 3 ≤10 Forced Switch 2 ≤10 Forced Switch 1 ≤5 Recommended switch 1 >5 Do not switch 0 Any Do not switch

[0167] Specifically, step S202 triggers the navigation switching process:

[0168] If high-priority rules are met (such as urgency ≥ 2 points and ETA ≤ 10 minutes), the current navigation task is terminated immediately; the route planning API of the map SDK is called to re-plan the route to the passenger's starting point.

[0169] The voice announcement reminds the driver: "You have a new order. Navigation has switched to the passenger's starting point."

[0170] Recommended switch: Meet the medium priority rule (e.g., urgency = 1 and ETA ≤ 5 minutes). A pop-up window will prompt the driver: "You have a new order. Estimated arrival time: 5 minutes. Do you want to switch navigation?"

[0171] The driver can choose to "accept" or "reject": accepting triggers the navigation switching process; rejecting retains the current navigation and the system records the driver's operation log.

[0172] Do not switch: None of the switching rules are met (e.g., low urgency and long ETA); the current navigation task remains unchanged; a prompt is displayed on the driver's side: "You have a new order, but the current navigation task is not affected."

[0173] In this embodiment, regarding step S3, state synchronization and cleanup:

[0174] Communicate with the map SDK to record the end point of the current normal navigation (such as current location, remaining route, etc.); pass the passenger order navigation parameters (starting point, end point, estimated time, etc.) to the map SDK; call the SDK to start the passenger order navigation, and the background automatically completes the navigation switch.

[0175] Specifically, in step S300, the end point of the current normal navigation is recorded:

[0176] Call the map SDK's positioning interface (such as getCurrentLocation) to obtain the driver's current latitude and longitude coordinates (such as {lat:31.2304,lng:121.4737});

[0177] Call the route planning interface (such as getRemainingRoute) to extract the remaining route information of the current navigation:

[0178] (1) Remaining distance (e.g. 2.3 km).

[0179] (2) Remaining time (e.g. 5 minutes).

[0180] (3) List of passing points (such as [Point A, Point B]).

[0181] Store the end point information (location, remaining route) in a local database (such as SQLite). The fields are designed as follows:

[0182]

[0183] Specifically, step S301, passing passenger order navigation parameters:

[0184] Extract key parameters from the order data received in step S1:

[0185] Starting point: The longitude and latitude of the passenger boarding point (e.g. {lat:31.2310,lng:121.4740}).

[0186] Destination: The longitude and latitude of the passenger's drop-off point (e.g. {lat:31.2350,lng:121.4800}).

[0187] Estimated time: ETA calculated based on real-time traffic conditions (e.g. 12 minutes).

[0188] Encapsulate the order parameters into a format supported by the Map SDK (such as JSON):

[0189] Specifically, in step S302, the SDK is called to start the passenger order navigation:

[0190] Call the navigation start interface of the map SDK (such as startNavigation) and pass in the encapsulated order parameters;

[0191] After the navigation is successfully started, the SDK automatically closes the current normal navigation and switches to the passenger order navigation;

[0192] Call the speech synthesis API to prompt the driver: "You have switched to the passenger order navigation, estimated arrival time: 12 minutes."

[0193] Specifically, step S303, status cleanup and subsequent processing:

[0194] Stop real-time monitoring of the current normal navigation (such as location updates, route updates); close the old navigation session with the map SDK; mark the end point information of the old navigation as "archived" for subsequent query.

[0195] If the SDK returns an error (such as "route planning failed"), the system will automatically retry 3 times and push an alarm to the operation and maintenance center if it fails; if the driver manually cancels the order during the navigation switching process, the system will automatically return to the normal navigation state.

[0196] In this embodiment, regarding step S4, multi-scenario navigation priority management:

[0197] Dynamically calculate navigation task priority based on order type (passenger order / non-order navigation), urgency, and driver status parameters; call priority sorting to generate a navigation task priority list;

[0198] Real-time monitoring of navigation task priority conflicts (multiple high-priority orders arriving at the same time);

[0199] Select the best navigation task for processing and update the priority list;

[0200] Generate navigation prompt information (such as route planning, estimated arrival time, etc.) based on the priority list;

[0201] The current navigation task is displayed on the driver's interface, and manual adjustments (such as temporary cancellation, re-planning, etc.) are supported.

[0202] Specifically, in step S400, the navigation task priority is dynamically calculated:

[0203] Passenger orders (such as instant orders, reservation orders, and carpooling orders), and non-order navigation (such as drivers planning their own routes and returning empty trips).

[0204] Passenger orders are assigned an urgency value based on the order type (e.g., instant order = 5, scheduled order = 3); the default urgency value for non-order navigation is 1.

[0205] Driver status parameters include:

[0206] (1) The distance between the current location and the order starting point (if < 1 km, weighted 2 points).

[0207] (2) Whether the driver is available (idle drivers are given priority in allocating orders).

[0208] (3) Driver rating (drivers with high ratings are given priority in allocating high-quality orders).

[0209] Specifically, in step S401, a navigation task priority list is generated:

[0210] Sort tasks from high to low priority to generate a task list; use a priority queue to store tasks to ensure efficient sorting and updating;

[0211] Specifically, in step S402, the priority conflicts of navigation tasks are monitored in real time:

[0212] Multiple high-priority orders arrive at the same time (e.g., three instant orders are assigned at the same time); if the priority difference is less than a threshold (e.g., 0.5), it is considered a conflict.

[0213] Conflict resolution strategies include:

[0214] (1) Distance priority: select the task closest to the driver.

[0215] (2) Time window: Allocate according to the estimated time of arrival (ETA) of the order to avoid time overlap.

[0216] (3) Driver selection: Push conflicting tasks to the driver side, and the driver manually selects.

[0217] Specifically, in step S403, the optimal navigation task is selected and the list is updated:

[0218] Take the highest priority task from the priority queue and mark it as "current task"; remove the selected task from the queue and recalculate the priority of the remaining tasks (such as the distance weighting changes due to the change of the driver's position).

[0219] Specifically, in step S404, navigation prompt information is generated:

[0220] Call the map SDK to generate the optimal route and return route details (passing roads or turn prompts).

[0221] Specifically, step S405, driver-side interface display and interaction

[0222] Display route map, ETA, order details (such as passenger name and contact information); display pending tasks in list format, support sliding switching; drivers can cancel the current task, and the system will automatically assign the next task; support drivers to manually adjust the route (such as avoiding congested sections) and call the SDK for re-planning.

[0223] In this embodiment, regarding step S5, status update and feedback:

[0224] Real-time synchronization of passenger order status (such as accepted, arrived, completed, etc.) to the dispatch system;

[0225] Regularly provide navigation status feedback to the driver app (e.g., driving, arrived, off-route, etc.);

[0226] Specifically, step S500 is to synchronize the passenger order status to the dispatch system in real time:

[0227] Order status definitions and triggering conditions include:

[0228] (1) Status list:

[0229] (1.1) Order Accepted: Triggered when the driver clicks the "Accept Order" button.

[0230] (1.2) Arrived: After the driver arrives at the passenger pick-up point, click the "Arrived" button to trigger.

[0231] (1.3) In service: After the passenger gets on the car, the driver clicks the "Start Trip" button to trigger.

[0232] (1.4) Completed: Triggered when the passenger arrives at the destination and the driver clicks the "End Trip" button.

[0233] (1.5) Cancelled: Triggered when the passenger or driver cancels the order.

[0234] (2) Synchronization mechanism: Use WebSocket or MQTT protocol to push order status changes to the scheduling system in real time.

[0235] Specifically, in step S501, the navigation status is regularly fed back to the driver application:

[0236] Navigation state definition and trigger conditions:

[0237] (1) Status list:

[0238] (1.1) Driving: After the driver starts navigating, the system is triggered when it determines that the vehicle is moving based on GPS data.

[0239] (1.2) Arrived: Automatically triggered when the vehicle arrives at the destination.

[0240] (1.3) Off-route: Triggered when the vehicle deviates from the planned route by more than a threshold (e.g. 500 meters).

[0241] (1.4) Navigation end: triggered when the driver manually closes the navigation or reaches the destination.

[0242] (2) Feedback mechanism: Navigation status is pushed to the driver every 10 seconds through long polling or WebSocket.

[0243] Driver-side interaction: Display navigation status in a pop-up window or status bar on the driver-side interface; provide a re-route option when the route is deviated; and prompt the driver to click "End Navigation" when the destination is reached.

[0244] All of the above embodiments merely represent implementation methods of the present invention in practical applications. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that a person skilled in the art could make various modifications and improvements without departing from the scope of the present invention, all of which fall within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be based on the appended claims.

[0245] For those skilled in the art, it can be further appreciated that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in terms of function in the above description. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present invention.

[0246] At the same time, those skilled in the art will understand that all or part of the processes in all the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media provided in this application and used in the embodiments may include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double-speed data rate SDRAM (SSRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

Claims

1. The driver-side navigation switching management method is characterized by: The following steps are included: S1, continuously monitors passenger order information from the dispatch system and obtains the driver's current navigation status in real time; S2, determine the switching conditions; if the driver is in normal navigation and receives a passenger order: call the preset judgment table based on the urgency of the order and the driver's estimated arrival time, and if the switching conditions are met, trigger the navigation switching process; If no order is received or the switching conditions are not met, continue the current navigation; S3 communicates with the map SDK to record the end point of the current normal navigation and pass the passenger order navigation parameters to the map SDK; Call the SDK to start the passenger order navigation, and the background will automatically complete the navigation switch; S4, dynamically calculates the navigation task priority based on the order type, urgency and driver status parameters, and generates a navigation task priority list.

2. The management method according to claim 1, characterized in that: In said S1, the following steps are included: S100 subscribes to passenger order events in real time through the WebSocket or HTTP persistent connection interface provided by the dispatch system; parses the raw order data into structured information and extracts key fields; Automatically mark order priorities based on urgency; S101, through the API provided by the map SDK, the end point location of the current navigation task is obtained in real time; Calling the route planning algorithm: Calculating the current route details, as well as whether the driver is navigating, whether they have deviated from the route, and the current speed; S103, associating the passenger's order information with the driver's navigation status, and calculating the straight-line distance between the passenger's starting point and the driver's current location; Determine whether the new order conflicts with the existing navigation; If the driver has no vehicles available and the order distance is ≤5 kilometers, the system will automatically trigger the order acceptance process; If the order is expedited, the priority will automatically increase by 2 levels; if the driver accepts the order, the system will automatically terminate the current navigation task and switch to the new order navigation; if the driver does not accept the order, the system will retain the current navigation task and wait for the driver to manually process it.

3. The management method according to claim 1, characterized in that: In said S2, Step S200: Determine whether the driver is currently in normal navigation mode; confirm whether the driver has received a new passenger order; extract the urgency score based on the order type and passenger notes; call the map SDK's route planning API to calculate the estimated arrival time from the driver's current location to the passenger's starting point; S201, calling a preset judgment table; S202: If the high priority rule is met, the current navigation task is terminated immediately.

4. The management method according to claim 1, characterized in that: In said S3, S300: Call the positioning interface of the map SDK to obtain the latitude and longitude coordinates of the driver's current location; call the route planning interface to extract the remaining route information of the current navigation: remaining distance, remaining time, and a list of waypoints; Store the end point information in the local database S301, extracting key parameters from the order data received in step S1: including the starting point, the end point, and the estimated time; S302, calling the navigation start interface of the map SDK and passing in the packaged order parameters; After the navigation is successfully started, the SDK automatically closes the current normal navigation and switches to the passenger order navigation; S303: Stop the real-time monitoring of the current normal navigation; close the old navigation session with the map SDK.

5. The management method according to claim 1, characterized in that: In the S4, the navigation task priority conflicts are monitored in real time, the optimal navigation task is selected for processing, and the priority list is updated; navigation prompt information is generated according to the priority list; the current navigation task is displayed on the driver-side interface, and manual adjustment is supported.

6. The management method according to claim 5, characterized in that: In said S4, S400, dynamically calculates navigation task priorities, including passenger-ordered and non-ordered navigation; Passenger orders are assigned an urgency value based on the order type; Non-order navigation default urgency value = 1; S401, sorting by priority from high to low to generate a task list; Use priority queues to store tasks to ensure efficient sorting and updating; S402: When multiple high-priority orders arrive at the same time, if the priority difference is less than the threshold, it is determined to be a conflict; conflict resolution strategies include distance priority, time window, and driver selection; S403, taking out the highest priority task from the priority queue and marking it as "current task"; Remove the selected tasks from the queue and recalculate the priorities of the remaining tasks; S404: Call the map SDK to generate the optimal route and return the route details.

7. The management method according to claim 1, characterized in that: Also includes S5, status updates and feedback: Synchronize passenger order status to the dispatch system in real time; Regularly report navigation status to the driver app.

8. The management method according to claim 7, characterized in that: In S5, the order status definition and triggering conditions include: Status list: Accepted, Arrived, In Service, Completed, and Cancelled: triggered when the passenger or driver cancels the order; the synchronization mechanism uses WebSocket or MQTT protocol to push order status changes to the dispatch system in real time.

9. A system for implementing the management method according to any one of claims 1 to 8, characterized in that: The system comprises: Driver side: When an order is generated, the system automatically triggers navigation switching based on the driver's current navigation status; the task list is sorted by priority; and the navigation status is pushed to the driver side in real time via WebSocket; Passenger side: After the passenger enters the starting and ending points, the order is automatically generated and pushed to the nearby driver; the passenger side displays the driver's current location and estimated arrival time; the driver's status changes are synchronized to the passenger side in real time; Map SDK: monitors changes in road conditions in real time and automatically replans routes; uses GPS+Wi-Fi+Bluetooth hybrid positioning technology, supports setting virtual fences, and automatically triggers silent navigation.

10. The system according to claim 9, characterized in that: The driver calls the navigation API of the Amap / Baidu Map SDK; The passenger side uses WebSocket or persistent connection technology to push order status in real time; passenger location and order information are transmitted using AES encryption; The map SDK is based on a cloud-based route calculation engine and supports offline map downloads.

Images