Network dynamic optimization and collaborative adaptation method, device, equipment and medium

Abstract

The invention discloses a network dynamic optimization and collaborative adaptation method and device, equipment and a medium, and relates to the technical field of robot network communication. According to the scheme, a unified network card adaptive abstraction layer is constructed for the robot by using the standardized network card application programming interface and the exclusive adapter, so that the function calling of the two network cards is standardized, and the software and hardware decoupling is realized, thereby shielding the hardware difference of different types and different network cards, enabling the installation and switching of the external network card to be free from repeatedly developing a bottom driver, and improving the reliability of the robot. And the adaptation period is shortened from week level to day level, so that the development cost is remarkably reduced. When the network optimization is executed on the basis, the current network health diagnosis result is determined according to the network data, the hardware and environment data and the task data, and the corresponding network optimization strategy is executed by using the standardized network card application programming interface, so that a faster and more accurate network optimization effect is achieved, and the network optimization efficiency is fundamentally improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of robot network communication, in particular to a network dynamic optimization and collaborative adaptation method and device, equipment and medium. BACKGROUND

[0002] With the large-scale deployment of humanoid robots, robotic dogs and other intelligent mobile entities in key scenarios such as finance, government affairs, exhibition halls and outdoor inspection, the stability and intelligence of their network communication modules have become a decisive factor in improving service quality and ensuring task success rate. Currently, these devices rely on efficient and reliable network connections to support real-time collaboration and autonomous operation in complex environments, but the bottleneck of network performance directly restricts the further optimization of application effect.

[0003] Specifically, the built-in and external network cards of robots are deeply bound to the hardware interface of a specific model, such as the foot chassis interface of a humanoid robot or the body waterproof power supply module of a robotic dog. When an external network card is installed to enhance network performance, a driver must be developed separately for different models, and complex power supply logic and interface protocol conflicts must be handled. The single adaptation cycle is long, and the manpower and material resources are huge. This situation seriously violates the industry trend of "soft and hard decoupling", hindering the rapid scenario landing and large-scale popularization and application of robots.

[0004] In view of the above, how to solve the problem that the network card of the current robot is deeply bound to the hardware interface, resulting in a long driver adaptation cycle and high cost, is a problem that technicians in the field need to solve. SUMMARY

[0005] The purpose of the present application is to provide a network dynamic optimization and collaborative adaptation method, device, equipment and medium to solve the problem that the network card of the current robot is deeply bound to the hardware interface, resulting in a long driver adaptation cycle and high cost.

[0006] To solve the above technical problems, the present application provides a network dynamic optimization and collaborative adaptation method applied to a robot; the robot includes a pre-configured standardized network card application programming interface and a corresponding model-specific adapter; the standardized network card application programming interface is used to provide a network service calling method for the upper layer, and the model-specific adapter is used to provide a dedicated hardware interface type, protocol and specification for the robot; the method comprises:

[0007] Obtain network data, hardware and environment data, and task data of a current execution task;

[0008] Determine a current network health diagnosis result according to the network data, the hardware and environment data, and the task data;

[0009] Based on the network health diagnosis results, the corresponding network optimization strategy is executed using the standardized network interface card (NIC) application programming interface.

[0010] On the one hand, it acquires network data, hardware and environment data, and task data for the currently executing task, including:

[0011] The network data is obtained by collecting latency, bandwidth, packet loss rate, signal strength, and network jitter of the built-in network card and the external network card.

[0012] Collect the connection status of the external network card, the interface power supply voltage, the real-time position of the robot, and the Wi-Fi frequency band occupancy rate to obtain the hardware and environmental data;

[0013] Obtain the priority tag of the currently executing task from the robot task management system to obtain the task data;

[0014] The priority tags include at least emergency shutdown, financial transactions, human-computer interaction, and data synchronization; the priority of emergency shutdown is higher than that of financial transactions, the priority of financial transactions is higher than that of human-computer interaction, and the priority of human-computer interaction is higher than that of data synchronization.

[0015] On the other hand, based on the network data, the hardware and environment data, and the task data, the current network health diagnosis result is determined, including:

[0016] Obtain the dynamic weights and network health thresholds of each network data point pre-configured for the task data;

[0017] The network health score is determined by weighted summation based on each network data and its corresponding dynamic weight.

[0018] The current network health diagnosis result is determined based on the network data, the hardware and environment data, the network health score, and the corresponding network health threshold.

[0019] On the other hand, based on the network data, the hardware and environment data, the network health score, and the corresponding network health threshold, the current network health diagnosis result is determined, including:

[0020] When the latency of the built-in network card is not less than a first latency threshold, the jitter is not less than a first jitter threshold, and the signal strength is not greater than a first signal strength threshold, the Wi-Fi band occupancy rate is not less than a first band occupancy rate threshold and there is interference in the same band, the priority label of the task data is financial transaction or human-computer interaction, and the network health score is less than the corresponding network health threshold, the network health diagnosis result is determined to indicate that the built-in network card band is congested.

[0021] When the fluctuation value of the signal strength of the external network card is not less than the signal strength fluctuation threshold and the packet loss rate is not less than the first packet loss rate threshold, the fluctuation value of the interface power supply voltage is not less than the voltage fluctuation threshold and there is a robot movement record, it is determined that the network health diagnosis result indicates that the physical connection of the external network card is loose.

[0022] When the network bandwidth utilization rate is not less than the network bandwidth utilization rate threshold, the real-time available bandwidth is not greater than the real-time available bandwidth threshold, the packet loss rate is not less than the second packet loss rate threshold and the latency continues to increase, the Wi-Fi band occupancy rate is not less than the first band occupancy rate threshold and network connection requests from other robots in the same network are detected, the priority label of the task data is financial transaction and the network health score is less than the corresponding network health threshold, the network health diagnosis result is determined to represent multi-robot bandwidth competition.

[0023] Wherein, the first packet loss rate threshold is greater than the second packet loss rate threshold.

[0024] On the other hand, based on the network health diagnosis results, corresponding network optimization strategies are executed using the standardized network interface card (NIC) application programming interface, including:

[0025] The network health diagnosis results are used as the root cause of network problems, and corresponding execution strategies are matched in a pre-built network interface card (NIC) optimization knowledge base. The NIC optimization knowledge base stores multiple sets of mapping relationships between scenarios, robot models, root causes of network problems, execution strategies, and optimization effect indicators.

[0026] Determine whether the execution strategy corresponding to the network health diagnosis result is matched;

[0027] If so, the execution strategy will be used as the network optimization strategy and executed.

[0028] If not, local inference is performed based on the network health diagnosis results to generate and execute the network optimization strategy.

[0029] On the other hand, the process of constructing the network interface card (NIC) optimization knowledge base includes:

[0030] Configure a standardized dictionary; wherein the standardized dictionary contains standardized definitions of scenarios, robot models, network problem root causes, execution strategies, and optimization performance indicators;

[0031] Obtain complete optimization log packages uploaded by multiple robots; wherein, the complete optimization log package includes at least basic identification data, original state data at the time the problem occurred, task context data, root cause diagnosis results, execution strategy instructions, and strategy execution effect data;

[0032] Based on the standardized dictionary, data cleaning and standardization processing are performed on the data in each of the complete optimized log packages;

[0033] A mapping relationship is established based on the standardized data; wherein the mapping relationship includes at least a one-to-many mapping relationship between the scene and the robot model, a many-to-one mapping relationship between the scene, the robot model and the original state data and the root cause of the network problem, a one-to-many or many-to-one mapping relationship between the root cause of the network problem and the execution strategy, and a one-to-one mapping relationship between the execution strategy and the optimization effect index.

[0034] A database table is established based on the mapping relationships described above; wherein, the database table includes at least a case master table, a model scenario association table, a root cause strategy association table, and an effect indicator detail table;

[0035] Create indexes for the core fields and combined query indexes for each of the aforementioned database tables.

[0036] On the other hand, it also includes:

[0037] Obtain the complete optimization log package uploaded by each robot according to the preset cycle;

[0038] Based on the complete optimization log packages, the execution strategies in the network interface card optimization knowledge base are optimized and adjusted through statistical analysis and machine learning algorithms.

[0039] To address the aforementioned technical problems, this application also provides a network dynamic optimization and collaborative adaptation device for use in robots; the robot includes a pre-configured standardized network interface card (NIC) application programming interface and a dedicated adapter for the corresponding model; the standardized NIC application programming interface is used to provide network service invocation methods for the upper layer, and the dedicated adapter is used to provide the robot with dedicated hardware interface types, protocols, and specifications; the device includes:

[0040] The acquisition module is used to acquire network data, hardware and environment data, and task data of the currently executing task;

[0041] The determination module is used to determine the current network health diagnosis result based on the network data, the hardware and environment data, and the task data;

[0042] The optimization module is used to execute corresponding network optimization strategies based on the network health diagnosis results using the standardized network interface card application programming interface.

[0043] To address the aforementioned technical problems, this application also provides a network dynamic optimization and collaborative adaptation device, comprising:

[0044] Memory, used to store computer programs;

[0045] A processor is used to implement the above-described network dynamic optimization and cooperative adaptation method when executing the computer program.

[0046] To address the aforementioned technical problems, this application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the aforementioned network dynamic optimization and cooperative adaptation method.

[0047] The network dynamic optimization and collaborative adaptation method provided in this application is applied to robots that include standardized network interface card (NIC) application programming interfaces (APIs) and dedicated adapters. The standardized NIC APIs provide network service invocation methods, while the dedicated adapters provide specific hardware interface types, protocols, and specifications. This solution utilizes the standardized NIC APIs and dedicated adapters to construct a unified "NIC adaptation abstraction layer" for the robot, standardizing the function calls of the two types of NICs, achieving software-hardware decoupling, and thus shielding the hardware differences between different models and NICs. This eliminates the need for repeated development of underlying drivers when adding or switching external NICs, shortening the adaptation cycle from weeks to days and significantly reducing development costs. Based on this, when performing network optimization, the current network health diagnosis results are determined according to network data, hardware and environmental data, and task data. The corresponding network optimization strategy is then executed using the standardized NIC APIs, resulting in faster and more accurate network optimization effects, fundamentally improving network optimization efficiency.

[0048] In addition, this application also provides a network dynamic optimization and collaborative adaptation device, equipment and medium, with the same effect as above. Attached Figure Description

[0049] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0050] Figure 1 A flowchart illustrating a network dynamic optimization and cooperative adaptation method provided in this application embodiment;

[0051] Figure 2 A schematic diagram of a network dynamic optimization and collaborative adaptation device provided in an embodiment of this application;

[0052] Figure 3 This is a structural diagram of a network dynamic optimization and collaborative adaptation device provided in an embodiment of this application. Detailed Implementation

[0053] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0054] The core of this application is to provide a method, apparatus, device, and medium for dynamic network optimization and collaborative adaptation, so as to solve the problem that the deep binding between the network card and hardware interface of robots currently leads to long driver adaptation cycles and high costs.

[0055] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0056] Currently, the built-in and external network cards of robots are deeply bound to the hardware interfaces of specific models, such as the leg chassis interface of humanoid robots or the waterproof power supply module of robot dogs. When an external network card is added to enhance network performance, separate drivers must be developed for different models, and complex power supply logic and interface protocol conflicts must be handled. Each adaptation cycle is lengthy, requiring significant investment of manpower and resources. This situation severely violates the industry trend of "software-hardware decoupling" and hinders the rapid deployment and large-scale application of robots. Therefore, to solve the above problems, this application provides a method for dynamic network optimization and collaborative adaptation.

[0057] It is worth noting that the network dynamic optimization and collaborative adaptation method provided in this application is applied to a robot, which includes a pre-configured standardized network interface card (NIC) application programming interface (API) and a dedicated adapter for the corresponding model. This application utilizes the standardized NIC API and the dedicated adapter to build a unified "NIC adaptation abstraction layer" for the robot. This layer encapsulates the underlying hardware differences through standardized interfaces and is the engineering foundation for achieving rapid adaptation.

[0058] Specifically, the standardized network interface card (NIC) API provides a set of standardized APIs, offering a unified way to invoke network services to the upper-layer scheduling center. The core standardized NIC APIs include at least: `connect(type)`: performs internal / external NIC switching; `get_metrics()`: retrieves real-time performance metrics of the currently active NIC; `adjust_bandwidth(ratio)`: dynamically adjusts bandwidth allocation; and `set_frequency_band(band)`: sets the preferred frequency band. It's important to note that these core standardized NIC APIs do not belong to individual internal or external NICs, but rather to a unified abstraction interface for both. The upper-layer scheduling center does not need to distinguish hardware types; it can invoke the corresponding NIC's functions simply through API parameters. The underlying hardware differences are masked by the dedicated adapter for each device model.

[0059] Dedicated adapters, on the other hand, provide robots with specific hardware interface types, protocols, and specifications. For example, for humanoid robots, the corresponding dedicated adapter manages the power supply timing and protocol conversion of its USB-C interface; for secondary development models of robot dogs, the corresponding dedicated adapter drives its dedicated waterproof interface and can integrate simple motor control to fine-tune the orientation of the external network card. In other words, the core differences of dedicated adapters lie in three aspects: hardware interface characteristics, usage scenario requirements, and functional adaptation priorities, which directly determine the differentiated design of dedicated adapters.

[0060] In summary, this application constructs a unified "NIC adaptation abstraction layer" through standardized NIC APIs and dedicated adapters, shielding the hardware differences between different machine models and different NICs (internal / external). This eliminates the need for repeated development of underlying drivers when adding or switching external NICs, shortening the adaptation cycle from weeks to days and significantly reducing development costs. Based on the above structure, the method flow of this application is described in detail below:

[0061] Figure 1 This is a flowchart illustrating a network dynamic optimization and cooperative adaptation method provided in an embodiment of this application. Figure 1 As shown, the method includes:

[0062] S10: Obtain network data, hardware and environment data, and task data for the currently executing task.

[0063] In practical implementation, the robot locally accesses and collects three types of data in real time: network data, hardware and environmental data, and task data of the currently executing task. This embodiment does not limit the specific content of network data, hardware and environmental data, and task data. For example, it may include network data such as signal strength, latency, and bandwidth utilization; hardware and environmental data such as hardware status, ambient temperature, and humidity; and task data such as task instructions, task status, and task results, depending on the specific implementation.

[0064] S11: Determine the current network health diagnosis results based on network data, hardware and environment data, and task data.

[0065] Subsequently, a health check is performed on the robot's network interface card (NIC) based on network data, hardware and environmental data, and task data to determine the current network health check result. It should be noted that the network health check result here can be from an internal NIC, an external NIC, or both; there is no limitation here. Furthermore, the specific process for determining the network health check result is not limited in this embodiment and will depend on the specific implementation.

[0066] S12: Based on the network health diagnosis results, execute the corresponding network optimization strategy using the standardized network interface card (NIC) application programming interface.

[0067] Finally, to optimize the network and ensure the smooth completion of the robot's tasks, specific network optimization strategies are executed using standardized network interface card (NIC) APIs based on network health diagnostic results. This fundamentally solves the response lag problem through local autonomy, improving response speed by an order of magnitude compared to cloud-based solutions. In weak network scenarios such as outdoor inspections, this significantly increases the success rate of uploading critical data. This embodiment does not impose restrictions on the process of determining the network optimization strategy; it depends on the specific implementation situation.

[0068] In this embodiment, a unified "NIC adaptation abstraction layer" is constructed for the robot using a standardized NIC application programming interface (API) and a dedicated adapter. This standardizes the function calls of the two types of NICs, achieving hardware-software decoupling. This shields the hardware differences between different models and NICs, eliminating the need for repeated development of underlying drivers when adding or switching external NICs. The adaptation cycle is shortened from weeks to days, significantly reducing development costs. Based on this, when performing network optimization, the current network health diagnosis result is determined according to network data, hardware and environmental data, and task data. The corresponding network optimization strategy is then executed using the standardized NIC API, resulting in faster and more accurate network optimization effects, fundamentally improving network optimization efficiency.

[0069] To achieve complete robot data acquisition, based on the above embodiments, some embodiments acquire network data, hardware and environmental data, and task data of the currently executing task, including:

[0070] S101: Collects latency, bandwidth, packet loss rate, signal strength, and network jitter of the built-in and external network cards to obtain network data.

[0071] S102: Collects the connection status of the external network card, the interface power supply voltage, the robot's real-time position, and the Wi-Fi band occupancy rate to obtain hardware and environmental data.

[0072] S103: Obtain the priority tag of the currently executing task from the robot task management system to obtain task data.

[0073] Specifically, when collecting the three types of data, the latency, bandwidth, packet loss rate, signal strength, and network jitter of both the built-in and external network cards are collected to obtain network data. Latency is the time required for a data packet to travel from the sender to the receiver, typically measured in milliseconds; bandwidth is the maximum theoretical capacity of a network connection to transmit data per unit time; packet loss rate is the percentage of data packets lost during transmission out of the total number of transmitted data packets; signal strength measures the strength of the wireless network signal, with higher values ​​(or smaller negative values) indicating better signal strength; and network jitter is the variation in latency between consecutive data packets, reflecting the stability of network latency. Other network data may also be collected in specific implementations, but this embodiment does not impose any restrictions.

[0074] Secondly, the connection status of the external network card, the interface power supply voltage, the robot's real-time position, and the Wi-Fi frequency band occupancy rate obtained through sensors or local scanning are collected to obtain hardware and environmental data. Finally, the priority tags of the currently executing tasks are retrieved from the robot task management system to obtain task data. It should be noted that the priority tags include at least emergency stop P0, financial transaction P1, human-machine interaction P2, and data synchronization P3. Emergency stop P0 has a higher priority than financial transaction P1, financial transaction P1 has a higher priority than human-machine interaction P2, and human-machine interaction P2 has a higher priority than data synchronization P3. This achieves the collection of three types of robot data.

[0075] To determine the robot's current network health diagnostic result, based on the above embodiments, in some embodiments, the current network health diagnostic result is determined according to network data, hardware and environment data, and task data, including:

[0076] S111: Obtain the dynamic weights and network health thresholds of each network data that have been pre-configured for the task data.

[0077] S112: The network health score is determined by weighted summation based on each network data and its corresponding dynamic weight.

[0078] S113: Determine the current network health diagnosis result based on network data, hardware and environment data, network health score and corresponding network health threshold.

[0079] To determine network health diagnostic results, this embodiment innovatively introduces a task priority-driven dynamic weight allocation algorithm. Specifically, it obtains the dynamic weights and network health thresholds of each network data point pre-configured for the task data. As shown in the above embodiment, network data includes at least latency, bandwidth, packet loss rate, signal strength, and network jitter. The task data specifically comprises four different priority labels: emergency shutdown P0, financial transaction P1, human-computer interaction P2, and data synchronization P3. Therefore, this embodiment provides examples of the dynamic weights and network health thresholds for the following two sets of network data:

[0080] For the low latency and high stability requirements of financial transactions (P1), the specific weights are set as follows: latency 40%, jitter 30%, signal strength 20%, and bandwidth 10%; the corresponding network health threshold is set to 80. For the high bandwidth and tolerable latency requirements of human-computer interaction (P2), the specific weights are set as follows: bandwidth 40%, signal strength 30%, latency 20%, and jitter 10%; the corresponding network health threshold is set to 60.

[0081] It should be noted that since packet loss rate is strongly correlated with latency and jitter, the high weighting of latency / jitter in the financial transaction P1 task already covers the stability requirements. The human-computer interaction P2 task has a high tolerance for minor packet loss, so there is no need to repeatedly set a weight for packet loss rate. Furthermore, packet loss rate can be set as an independent hard threshold, with higher priority than the scoring threshold, accurately addressing extremely unstable scenarios. Simplifying the indicators reduces local computing power consumption, avoids weight dispersion, ensures millisecond-level decision response, and aligns with the low-latency requirements of the local scheduling center.

[0082] Furthermore, the core objective of the emergency shutdown P0 task is to "immediately stop the current action and ensure safety." It can be executed without network support and does not require network optimization; therefore, there is no need to configure health scoring rules. The data synchronization P3 task is a low-priority, non-real-time task with extremely low requirements for network stability and latency. It can reuse the basic weight configuration or directly adopt the lowest guaranteed fixed weights (e.g., 20% bandwidth, 30% signal strength, 30% latency, and 20% jitter), with a threshold set to 40. Only basic connectivity needs to be met.

[0083] After determining the dynamic weights of each network data point and the network health threshold, a weighted sum is calculated based on each network data point and its corresponding dynamic weight to determine the network health score. The specific formula is: Score = Σ(Network data i × Dynamic weight i). Finally, based on the network data, hardware and environment data, network health score, and corresponding network health threshold, the current network health diagnosis result is determined.

[0084] Therefore, this embodiment constructs a multimodal, quantifiable network health scoring model by integrating network data indicators, task criticality levels, hardware and environmental data. This ensures that high-priority tasks always receive matching high-quality network resources, fundamentally improving decision-making accuracy. The root cause reasoning process for network health diagnosis results is explained in detail below:

[0085] (a) Congestion in the frequency band of the built-in network card;

[0086] When the latency of the built-in network card's current operating frequency band (typically 2.4 GHz) is not less than a first latency threshold (e.g., 50 ms), the jitter is not less than a first jitter threshold (e.g., 20 ms), and the signal strength is not greater than a first signal strength threshold (e.g., -70 dBm), and Wi-Fi frequency band scanning shows that the Wi-Fi frequency band occupancy rate of the frequency band used by the built-in network card is not less than a first frequency band occupancy rate threshold (e.g., 85%) and there is interference from the same frequency band, and the priority label of the task data is financial transaction P2 or human-computer interaction P2, and the network health score is less than the corresponding network health threshold (e.g., P1 < 80, P2 < 60), the network health diagnosis result is determined to indicate that the built-in network card's frequency band is congested. It should be noted that this embodiment does not impose any restrictions on the above threshold values; they are determined based on the specific implementation.

[0087] (ii) Loose physical connection of the external network card;

[0088] When the signal strength fluctuation of the external network card is frequently alternating and is not less than the signal strength fluctuation threshold (e.g., 20dBm) and the packet loss rate is not less than the first packet loss rate threshold (e.g., 10%), the external network card connection status is intermittent, the interface power supply voltage fluctuation is not less than the voltage fluctuation threshold (e.g., 0.5V), and there are robot movement records, the network health diagnosis result indicates that the physical connection of the external network card is loose. It should be noted that this embodiment does not impose any restrictions on the above threshold values; they are determined based on the specific implementation.

[0089] (iii) Bandwidth contention among multiple robots;

[0090] When network bandwidth utilization is not less than the network bandwidth utilization threshold (e.g., 90%), real-time available bandwidth is not greater than the real-time available bandwidth threshold (e.g., 1 Mbps), packet loss rate is not less than the second packet loss rate threshold (e.g., 5%), and latency continues to increase; Wi-Fi band occupancy is not less than the first band occupancy threshold (e.g., 85%), and network connection requests from other robots in the same network are detected (e.g., multiple explanation robots in an exhibition hall, multiple inspection robots outdoors), and the priority label of the task data is financial transaction P1 and the network health score is less than the corresponding network health threshold (e.g., P1 < 80), the network health diagnosis result is determined to represent multi-robot bandwidth competition. It should be noted that in this embodiment, the above threshold values ​​are not limited and are determined according to the specific implementation. The first packet loss rate threshold is greater than the second packet loss rate threshold.

[0091] To accurately execute appropriate network optimization strategies, based on the above embodiments, in some embodiments, the corresponding network optimization strategies are executed using a standardized network interface card (NIC) application programming interface (API) based on network health diagnostic results, including:

[0092] S121: Use the network health diagnosis results as the root cause of network problems and match the corresponding execution strategy in the pre-built network card optimization knowledge base.

[0093] S122: Determine whether an execution strategy corresponding to the network health diagnosis result is matched; if yes, use the execution strategy as the network optimization strategy and execute it; if no, perform local inference based on the network health diagnosis result to generate a network optimization strategy and execute it.

[0094] Specifically, network health diagnostic results are used as the root cause of network problems, and corresponding execution strategies are matched with a pre-built network interface card (NIC) optimization knowledge base. It should be noted that the NIC optimization knowledge base stores structured, anonymized optimization case data. Its data model is a mapping relationship between multiple scenarios, robot models, network problem root causes, execution strategies, and optimization effect indicators. For example, the scenario is "Financial Branch - Corner," the robot model is "T5432," the network problem root cause is "2.4G band conflict & metal obstruction," the execution strategy is "Switch to external 5G NIC," and the optimization effect is "Latency reduced from 80ms to 30ms." Efficient retrieval is supported by multiple dimensions such as scenario and model. This embodiment does not limit the construction process of the NIC optimization knowledge base; it depends on the specific implementation.

[0095] Next, it is determined whether an execution strategy corresponding to the network health diagnostic result is matched. If a matching execution strategy is found, the strategy is used as the network optimization strategy and executed. If no matching execution strategy is found, local inference is performed based on the network health diagnostic result to generate and execute a network optimization strategy.

[0096] It's important to note that root cause reasoning and policy generation are the core of robot local intelligence. Based on multimodal data, they rapidly diagnose the root causes of health degradation and generate precise scheduling policies. For example, when the network health diagnosis indicates congestion in the built-in network card's frequency band, the generated policy is `Network.connect(type:"external")` and `set_band("5G")`. The core principle is "switching to a more interference-resistant external network card + locking the low-interference 5G frequency band," precisely resolving the built-in network card's frequency band congestion problem: `Network.connect(type:"external")`: disconnects the built-in network card and enables the external network card (which typically has better signal reception and interference resistance); `set_band("5G")`: specifies that the external network card prioritizes the use of the 5G frequency band, avoiding the high-load interference of the 2.4G frequency band, meeting the core requirements of low latency and high stability for the P1 task in financial transactions.

[0097] When a network health diagnostic indicates a loose physical connection of the external network card, the generated strategy is to trigger a local hardware alarm and execute `Network.connect(type:"internal")`, while simultaneously instructing the task module to degrade services (e.g., pausing video streaming and maintaining only command transmission). The core principle is to "ensure basic connectivity + prompt for hardware maintenance + reduce network load" to avoid service interruptions due to hardware failure. Triggering the local hardware alarm is specifically done through a robot's audio-visual module (indicator flashing and voice prompts) to inform maintenance personnel that the external network card interface needs to be checked for looseness or poor contact. `Network.connect(type:"internal")` indicates an immediate switch back to the internal network card, restoring a stable basic network connection and mitigating the risk of network outages caused by an unstable external network card. Commanding the task module to degrade services specifically involves pausing bandwidth-intensive services such as video streaming and large file synchronization, maintaining only minimal core communication such as command transmission, reducing network load, and ensuring the availability of basic functions.

[0098] When the network health diagnosis indicates bandwidth contention among multiple robots, the generated strategy dynamically adjusts the local bandwidth usage ratio using `Network.adjust_bandwidth(ratio)` to ensure the success of the financial transaction P1 task. Its core principle is "dynamically allocating bandwidth according to task priority, prioritizing core business," maximizing business success rate in a bandwidth-constrained competitive environment. `Network.adjust_bandwidth(ratio)` sets the bandwidth allocation ratio based on task priority; for example, allocating 80%-100% of the local available bandwidth to the P1 task, while allocating less than 20% to lower-priority tasks like P2 / P3. The underlying logic sacrifices the non-core network requirements of lower-priority tasks to ensure that high-priority tasks (such as financial transactions) meet latency and stability standards, preventing core tasks from failing due to multiple robots competing for bandwidth.

[0099] Therefore, this embodiment combines knowledge base matching with local reasoning, giving the local end complete autonomous decision-making and scheduling capabilities, and constructing a "local scenario scheduling hub" with root cause reasoning capabilities. This enables it to independently and quickly diagnose the root cause of the problem and generate and execute optimization strategies when there are network anomalies (including disconnection from the cloud), ensuring the continuity of core business in extreme scenarios.

[0100] Based on the above embodiments, in some embodiments, the process of constructing the network interface card (NIC) optimization knowledge base includes:

[0101] S131: Configure a standardized dictionary.

[0102] S132: Obtain the complete optimization log package uploaded by multiple robots.

[0103] S133: Perform data cleaning and standardization on the data in each complete optimized log package based on a standardized dictionary.

[0104] S134: Establish a mapping relationship based on the standardized data.

[0105] S135: Establish database tables based on each mapping relationship.

[0106] S136: Create indexes for the core fields and combined query indexes for each database table.

[0107] The core of the network interface card (NIC) optimization knowledge base is to establish a structured mapping relationship of "scenario - robot model - root cause of network problem - execution strategy - optimization effect". Before building this knowledge base, a unified standardized dictionary must first be developed to avoid data ambiguity and lay the foundation for establishing the mapping relationship.

[0108] Table 1. Contents of the Standardized Dictionary

[0109]

[0110] As shown in Table 1, the standardized dictionary contains standardized definitions of scenarios, robot models, root causes of network problems, execution strategies, and optimization performance metrics.

[0111] Furthermore, obtain complete optimization log packages (after anonymization) uploaded by multiple robots. The complete optimization log package includes at least basic identification data, original state data at the time the problem occurred, task context data, root cause diagnosis results, execution strategy instructions, and strategy execution effect data. Specifically, the basic identification data includes the robot's unique model code (e.g., T502), deployment scenario registration information (e.g., "financial branch - business hall"), and real-time location coordinates (latitude and longitude + relative location description); the original state data at the time of the problem includes network data: latency, bandwidth, packet loss rate, signal strength, frequency band occupancy rate, etc. (1 second / sample) in the 30 seconds before the problem occurred, including hardware and environmental data: external network card connection status, interface power supply voltage, and the type of obstruction detected by the sensor (e.g., metal / wall); the task context data includes the priority label of the currently executing task (e.g., P1) and the task type (e.g., financial transfer guidance); the root cause diagnosis result is the original diagnosis conclusion output by the local root cause inference module (e.g., "2.4G frequency band occupancy rate 92% + metal counter obstruction"); the execution strategy instruction is the original API instruction issued by the local scheduling center (e.g., Network.connect(type:"external") + set_band("5G")); the strategy execution effect data includes network indicators (1 second / sample) in the 30 seconds after the strategy is executed and an indicator of whether the task is completed normally.

[0112] Subsequently, data cleaning and standardization processing were performed on the data in each complete optimized log package based on a standardized dictionary.

[0113] Table 2 Data Cleaning and Standardization Processing Rules

[0114]

[0115] As shown in Table 2, the collected raw data is processed by "denoising-normalization-structuring" to convert non-standard data into a format that conforms to a standardized dictionary.

[0116] Furthermore, a mapping relationship is established based on the standardized data through a combination of rule matching and manual verification. This mapping relationship includes at least the following types:

[0117] (a) A one-to-many mapping relationship between scenarios and robot models;

[0118] The logic of this mapping relationship is that the same device model can be adapted to multiple scenarios, and the same scenario can contain multiple device models. When executing the mapping, the "device model code" is used as the index to associate it with the "standardized scenario" in its uploaded log, forming a "device model-scenario association table" (e.g., "T201" → ["financial outlet - business hall - behind the metal counter" "showroom - central exhibition area - next to the pillar"]); the purpose is to provide a basic association for subsequent "scenario + device model search".

[0119] (ii) The many-to-one mapping relationship between the scenario, robot model, and raw state data and the root causes of network problems;

[0120] The logic of this mapping relationship is that under the same "scenario + device model", different raw state data (network + hardware + environment) correspond to a unique standardized root cause. When performing the mapping, "scenario + device model" is used as the key to aggregate all raw state data under that combination; the "root cause classification tree" is referenced, and rule matching is performed (e.g., "2.4G band occupancy > 85%" and "metal obstruction exists" → root cause "2.4G band conflict & metal obstruction"); difficult cases are manually verified (e.g., unclear raw data leading to uncertain root causes), and then labeled and stored in the database. For example, scenario "financial branch - business hall - behind metal counter" + device model "T201" + raw data (2.4G occupancy 92% + RSSI = -75dBm + metal obstruction) → root cause "2.4G band conflict & metal obstruction".

[0121] (iii) The one-to-many or many-to-one mapping relationship between the root causes of network problems and their implementation strategies;

[0122] The logic of this mapping relationship is that one root cause can correspond to multiple effective strategies (e.g., "frequency band congestion" can correspond to "switching to 5G" or "adjusting the channel"), and one strategy can solve multiple root causes of the same kind (e.g., "switching to an external 5G network card" can solve "2.4G congestion" and "metal blockage attenuation"). When executing the mapping, the "standardized root cause" is used as an index to associate all "standardized strategies" executed under that root cause; the "applicable conditions" of the strategy are marked (e.g., the applicable condition for "switching to an external 5G network card" is "the external network card is connected and has normal power supply"); for multiple strategies under the same root cause, they are sorted according to "optimization effect score" (the one with the best effect is ranked first). For example, root cause "2.4G frequency band conflict & metal blockage" → strategy "switch to external 5G network card" (applicable condition: external 5G network card is normal).

[0123] (iv) The one-to-one mapping relationship between execution strategies and optimization performance indicators;

[0124] The logic of this mapping relationship is that the execution result of a strategy under a specific "scenario + device model + root cause" corresponds to a unique standardized effect data. During the mapping process, "scenario + device model + root cause + execution strategy" is used as the unique key to associate the "standardized effect data" under that combination; an "effect score" is calculated (e.g., a 30ms reduction in latency earns 8 points, a 10Mbps increase in bandwidth earns 2 points, for a total of 10 points), which serves as the basis for subsequent strategy iterations. For example, the strategy "switch to external 5G network card" → effect "latency -42ms, health score +55 points, task success rate 100%, effect score 9.2 points".

[0125] After establishing the mapping relationships, database tables are created based on each mapping relationship.

[0126] Table 3 Database Tables

[0127]

[0128] As shown in Table 3, the database tables include at least the case master table, the model and scenario association table, the root cause strategy association table, and the effect indicator detail table.

[0129] Finally, to support retrieval, core field indexes and combined query indexes are established for each database table. Specifically, the core field indexes include scenario (full-text index), robot model (normal index), network problem root cause (normal index), and performance score (sorting index); the combined query indexes include "scenario + model", "scenario + root cause", and "model + root cause", ensuring that the retrieval response time is ≤100ms (meeting the efficiency requirements of the robot's local preloading strategy).

[0130] In summary, by constructing a network interface card (NIC) optimization knowledge base, we support ecosystem-wide reuse. Locally validated optimization strategies are stored in a cloud-based knowledge base in the form of "scenario-root cause-strategy-effect," and continuously optimized through iterative algorithms. This forms a common capability that can be quickly retrieved and reused by the entire product line and secondary development teams, accelerating the deployment of new scenarios and empowering the Robots as a Service (RAAS) ecosystem.

[0131] To ensure the network interface card (NIC) optimization knowledge base continues to evolve with real-world application scenarios, in some embodiments, the method further includes, based on the above embodiments:

[0132] S141: Obtain the complete optimization log package uploaded by each robot according to the preset cycle.

[0133] S142: Based on each complete optimization log packet, optimize and adjust each execution strategy in the network interface card optimization knowledge base through statistical analysis and machine learning algorithms.

[0134] To achieve iterative optimization of the network interface card (NIC) optimization knowledge base, this embodiment specifically acquires complete optimization log packages uploaded by each robot according to a preset period (e.g., every 24 hours). From the logs uploaded by each robot, valid cases with consistent "scenario + device model + root cause" are selected (excluding invalid logs due to policy execution failure or missing data). For example, all cases related to "financial branch - T502 device model - 2.4G frequency band conflict" are focused on. Further, key fields are extracted and core fields are retained. Core fields include at least policy parameters (such as the original threshold "latency > 50ms", frequency band selection "5G"), pre- and post-execution metrics (latency, bandwidth, packet loss rate, health score), and effect tags (task success rate, resource utilization, switching frequency). Finally, effect tags are assigned to the cases; for example, a latency reduction of ≥30% with no frequent switching corresponds to the tag "excellent," while excessive switching (≥3 times / minute) corresponds to the tag "poor."

[0135] Furthermore, based on the preprocessed data, statistical analysis and machine learning algorithms are used to optimize and adjust the execution strategies in the network card optimization knowledge base. Specifically, A / B testing is conducted first, which involves analyzing the differences in parameters within the same scenario. Cases under the same "scenario + device model + root cause" are divided into two groups based on parameters (e.g., Group 1 latency threshold 50ms, Group 2 threshold 60ms), and the core performance indicators of the two groups are compared.

[0136] Table 4. Rules for Indicator Calculation and Comparison

[0137]

[0138] As shown in Table 4, the comparison dimensions in the A / B test performance comparison include the performance achievement rate, over-optimization rate, and stability score. Taking a latency threshold of 50ms for Group 1 and 60ms for Group 2 as an example, after the above calculations, if the performance achievement rate (85%) of Group 2 (threshold 60ms) is greater than that of Group 1 (70%), and the over-optimization rate (5%) is less than that of Group 1 (15%), then it is preliminarily determined that the threshold can be adjusted upwards.

[0139] Then, distribution statistics are performed, which is essentially a parameter rationality check. Specifically, the statistical distribution of network indicators in this scenario (such as mean latency, median latency, and 95th percentile) is calculated. For example, if in the "Financial Branch - T502" scenario, 95% of normal network latency is ≤58ms, and the original threshold of 50ms is below the 95th percentile, resulting in "false triggering of switching," further verifying that "the threshold needs to be adjusted upwards."

[0140] Further machine learning modeling is performed to accurately calculate the optimal parameters. Specifically, scene encoding, device encoding, root cause type, environmental data (such as frequency band occupancy), and task priority are used as input features (X), and the optimal parameter value (such as latency threshold) or performance score (0-10, higher scores indicate better performance) is used as the output label (Y). Appropriate machine learning algorithms are selected; for example, Gradient Boosted Regression Trees (GBRT) are used for parameter regression (suitable for numerical parameter prediction); logistic regression is used to determine parameter validity (classifying "suitable / unsuitable"). During training, the training set (70% of log data) and test set (30% of log data) are first divided. The training set is used to fit the model, aiming for the highest performance score, learning the mapping relationship between features and optimal parameters. The test set is used to validate the model (e.g., prediction error ≤ 5ms), iteratively tuning the model hyperparameters (e.g., learning rate, tree depth). After model training is complete, the features of the current scene (e.g., "financial branch + T502 + 2.4G conflict + P1 task") are input, and the model outputs the optimal latency threshold (e.g., 60ms). Finally, perform constraint checks to ensure that the parameters comply with hardware / business limitations (such as the threshold not being lower than 30ms to avoid insufficient protection for core tasks).

[0141] Furthermore, to verify the effectiveness of the parameter adjustments in the network interface card (NIC) optimization knowledge base, the adjusted parameters (e.g., the optimal latency threshold of 60ms) can be distributed on a small scale, for example, to some T502 models, and continuously monitored for 72 hours to establish a gray-scale group. The effects of the gray-scale group and the original parameter group are compared. If the core task success rate is the same as the original group, and the percentage decrease in over-optimization rate and the percentage decrease in switching frequency are both greater than the corresponding thresholds, then the adjustment is considered effective. At this point, the verified effective new parameters can be updated to the corresponding strategy in the knowledge base, and a "parameter adjustment log" (original parameters, new parameters, adjustment basis, and effects) can be recorded simultaneously, forming an iterative closed loop.

[0142] Therefore, this embodiment takes "statistical analysis to determine direction, machine learning to calculate accurate values, and gray-scale verification to control risks" as its core, and can achieve adaptive adjustment of knowledge base strategy parameters without manual intervention, so that the knowledge base can continuously evolve with actual application scenarios.

[0143] In the above embodiments, the network dynamic optimization and cooperative adaptation method has been described in detail. This application also provides embodiments of the network dynamic optimization and cooperative adaptation device.

[0144] Figure 2This is a schematic diagram of a network dynamic optimization and collaborative adaptation device provided in an embodiment of this application. The device is applied to a robot; the robot includes a pre-configured standardized network interface card (NIC) application programming interface and a dedicated adapter for the corresponding model; the standardized NIC application programming interface is used to provide network service invocation methods for the upper layer, and the dedicated adapter is used to provide the robot with dedicated hardware interface types, protocols, and specifications; such as Figure 2 As shown, the device includes:

[0145] The acquisition module 10 is used to acquire network data, hardware and environment data, and task data of the currently executing task.

[0146] Module 11 is used to determine the current network health diagnosis result based on network data, hardware and environment data, and task data.

[0147] The optimization module 12 is used to execute corresponding network optimization strategies based on network health diagnosis results using a standardized network interface card (NIC) application programming interface.

[0148] In some embodiments, the acquisition module 10 includes:

[0149] The first acquisition module is used to collect latency, bandwidth, packet loss rate, signal strength and network jitter of the built-in network card and the external network card to obtain network data;

[0150] The second acquisition module is used to collect the connection status of the external network card, the interface power supply voltage, the real-time position of the robot, and the Wi-Fi frequency band occupancy rate to obtain hardware and environmental data.

[0151] The first acquisition submodule is used to obtain the priority tag of the currently executing task from the robot task management system in order to obtain task data;

[0152] The priority labels include at least emergency shutdown, financial transactions, human-computer interaction, and data synchronization; emergency shutdown has a higher priority than financial transactions, financial transactions have a higher priority than human-computer interaction, and human-computer interaction has a higher priority than data synchronization.

[0153] In some embodiments, the determining module 11 includes:

[0154] The second acquisition submodule is used to acquire the dynamic weights and network health thresholds of each network data that are pre-configured for the task data;

[0155] The first calculation module is used to perform weighted summation based on each network data and its corresponding dynamic weights to determine the network health score.

[0156] The Network Health Diagnosis Result Determination Submodule is used to determine the current network health diagnosis result based on network data, hardware and environment data, network health score, and corresponding network health threshold.

[0157] In some embodiments, the network health diagnostic result determination submodule includes:

[0158] The first determining submodule is used to determine the network health diagnosis result characterizing the built-in network card frequency band congestion when the latency of the built-in network card is not less than the first latency threshold, the jitter is not less than the first jitter threshold and the signal strength is not greater than the first signal strength threshold, the Wi-Fi frequency band occupancy rate is not less than the first frequency band occupancy rate threshold and there is interference in the same frequency band, the priority label of the task data is financial transaction or human-computer interaction and the network health score is less than the corresponding network health threshold.

[0159] The second determining submodule is used to determine the network health diagnosis result indicating that the physical connection of the external network card is loose when the fluctuation value of the signal strength of the external network card is not less than the signal strength fluctuation threshold and the packet loss rate is not less than the first packet loss rate threshold, the fluctuation value of the interface power supply voltage is not less than the voltage fluctuation threshold and there is a robot movement record.

[0160] The third determination submodule is used to determine the network health diagnosis result characterizing multi-robot bandwidth competition when the network bandwidth utilization rate is not less than the network bandwidth utilization rate threshold, the real-time available bandwidth is not greater than the real-time available bandwidth threshold, the packet loss rate is not less than the second packet loss rate threshold and the latency continues to increase, the Wi-Fi band occupancy rate is not less than the first band occupancy rate threshold and network connection requests from other robots in the same network are detected, the priority label of the task data is financial transaction and the network health score is less than the corresponding network health threshold.

[0161] Among them, the first packet loss rate threshold is greater than the second packet loss rate threshold.

[0162] In some embodiments, the optimization module 12 includes:

[0163] The matching module is used to use network health diagnosis results as the root cause of network problems and match the corresponding execution strategies in a pre-built network interface card (NIC) optimization knowledge base. The NIC optimization knowledge base stores multiple sets of mapping relationships between scenarios, robot models, network problem root causes, execution strategies, and optimization effect indicators.

[0164] The judgment and execution module is used to determine whether the execution strategy corresponding to the network health diagnosis result is matched; if so, the execution strategy is used as the network optimization strategy and executed; if not, local inference is performed based on the network health diagnosis result to generate the network optimization strategy and execute it.

[0165] In some embodiments, the process of constructing a network interface card (NIC) optimization knowledge base includes:

[0166] Configure a standardized dictionary, which includes standardized definitions of scenarios, robot models, network problem root causes, execution strategies, and optimization performance metrics. Obtain complete optimization log packages uploaded by multiple robots. Each complete optimization log package includes at least basic identifier data, original state data at the time of the problem, task context data, root cause diagnosis results, execution strategy instructions, and strategy execution performance data. Perform data cleaning and standardization on the data in each complete optimization log package based on the standardized dictionary. Establish mapping relationships based on the standardized data. These mapping relationships include at least a one-to-many mapping between scenarios and robot models, a many-to-one mapping between scenarios, robot models, and original state data and network problem root causes, a one-to-many or many-to-one mapping between network problem root causes and execution strategies, and a one-to-one mapping between execution strategies and optimization performance metrics. Establish database tables based on these mapping relationships. These database tables include at least a main case table, a model / scenario association table, a root cause / strategy association table, and a performance metric details table. Establish core field indexes and combined query indexes for each database table.

[0167] In some embodiments, it also includes:

[0168] The log acquisition module is used to acquire complete optimized log packages uploaded by each robot according to a preset period.

[0169] The iterative update module is used to optimize and adjust the execution strategies in the network interface card optimization knowledge base based on each complete optimization log package, through statistical analysis and machine learning algorithms.

[0170] Since the embodiments of the apparatus and the embodiments of the method correspond to each other, please refer to the description of the embodiments of the method for the embodiments of the apparatus, which will not be repeated here.

[0171] Figure 3 This is a structural diagram of a network dynamic optimization and collaborative adaptation device provided in an embodiment of this application. Figure 3 As shown, the network dynamic optimization and collaborative adaptation equipment includes:

[0172] Memory 20 is used to store computer programs;

[0173] The processor 21 is used to implement the steps of the network dynamic optimization and cooperative adaptation method mentioned in the above embodiments when executing a computer program.

[0174] The network dynamic optimization and collaborative adaptation devices provided in this embodiment may include, but are not limited to, smartphones, tablets, laptops, or desktop computers.

[0175] The processor 21 may include one or more processing cores, such as a quad-core processor or an octa-core processor. The processor 21 may be implemented using at least one of the following hardware forms: Digital Signal Processor (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 21 may also include a main processor and a coprocessor. The main processor, also known as the Central Processing Unit (CPU), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor 21 may integrate a Graphics Processing Unit (GPU), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, the processor 21 may also include an Artificial Intelligence (AI) processor, which handles computational operations related to machine learning.

[0176] The memory 20 may include one or more computer-readable storage media, which may be non-transitory. The memory 20 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In this embodiment, the memory 20 is used to store at least the following computer program 201, which, after being loaded and executed by the processor 21, is capable of implementing the relevant steps of the network dynamic optimization and cooperative adaptation method disclosed in any of the foregoing embodiments. In addition, the resources stored in the memory 20 may also include an operating system 202 and data 203, and the storage method may be temporary or permanent storage. The operating system 202 may include Windows, Unix, Linux, etc. The data 203 may include, but is not limited to, the data involved in the network dynamic optimization and cooperative adaptation method.

[0177] In some embodiments, the network dynamic optimization and collaborative adaptation device may further include a display screen 22, an input / output interface 23, a communication interface 24, a power supply 25, and a communication bus 26.

[0178] Those skilled in the art will understand that Figure 3 The structure shown does not constitute a limitation on network dynamic optimization and collaborative adaptation devices, and may include more or fewer components than shown.

[0179] Finally, this application also provides an embodiment corresponding to a computer-readable storage medium. The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the steps described in the above method embodiments.

[0180] It is understood that if the methods in the above embodiments are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and executes all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0181] The foregoing provides a detailed description of a network dynamic optimization and cooperative adaptation method, apparatus, device, and medium provided in this application. The various embodiments in the specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section. It should be noted that those skilled in the art can make several improvements and modifications to this application without departing from the principles of this application, and these improvements and modifications also fall within the protection scope of this application.

[0182] It should also be noted that, in this specification, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

Claims

1. A method for dynamic network optimization and cooperative adaptation, characterized in that, The method is applied to robots; the robot includes a pre-configured standardized network interface card (NIC) application programming interface and a dedicated adapter for the corresponding model; the standardized NIC application programming interface is used to provide network service invocation methods for the upper layer, and the dedicated adapter is used to provide the robot with dedicated hardware interface types, protocols, and specifications; the method includes: Acquire network data, hardware and environment data, and task data for the currently executing task; Based on the network data, the hardware and environment data, and the task data, determine the current network health diagnosis result; Based on the network health diagnosis results, the corresponding network optimization strategy is executed using the standardized network interface card (NIC) application programming interface.

2. The network dynamic optimization and cooperative adaptation method according to claim 1, characterized in that, Acquire network data, hardware and environment data, and task data for the currently executing task, including: The network data is obtained by collecting latency, bandwidth, packet loss rate, signal strength, and network jitter of the built-in network card and the external network card. Collect the connection status of the external network card, the interface power supply voltage, the real-time position of the robot, and the Wi-Fi frequency band occupancy rate to obtain the hardware and environmental data; Obtain the priority tag of the currently executing task from the robot task management system to obtain the task data; The priority tags include at least emergency shutdown, financial transactions, human-computer interaction, and data synchronization; the priority of emergency shutdown is higher than that of financial transactions, the priority of financial transactions is higher than that of human-computer interaction, and the priority of human-computer interaction is higher than that of data synchronization.

3. The network dynamic optimization and cooperative adaptation method according to claim 2, characterized in that, Based on the network data, the hardware and environment data, and the task data, determine the current network health diagnosis result, including: Obtain the dynamic weights and network health thresholds of each network data point pre-configured for the task data; The network health score is determined by weighted summation based on each network data and its corresponding dynamic weight. The current network health diagnosis result is determined based on the network data, the hardware and environment data, the network health score, and the corresponding network health threshold.

4. The network dynamic optimization and cooperative adaptation method according to claim 3, characterized in that, Based on the network data, the hardware and environment data, the network health score, and the corresponding network health threshold, the current network health diagnosis result is determined, including: When the latency of the built-in network card is not less than a first latency threshold, the jitter is not less than a first jitter threshold, and the signal strength is not greater than a first signal strength threshold, the Wi-Fi band occupancy rate is not less than a first band occupancy rate threshold and there is interference in the same band, the priority label of the task data is financial transaction or human-computer interaction, and the network health score is less than the corresponding network health threshold, the network health diagnosis result is determined to indicate that the built-in network card band is congested. When the fluctuation value of the signal strength of the external network card is not less than the signal strength fluctuation threshold and the packet loss rate is not less than the first packet loss rate threshold, the fluctuation value of the interface power supply voltage is not less than the voltage fluctuation threshold and there is a robot movement record, it is determined that the network health diagnosis result indicates that the physical connection of the external network card is loose. When the network bandwidth utilization rate is not less than the network bandwidth utilization rate threshold, the real-time available bandwidth is not greater than the real-time available bandwidth threshold, the packet loss rate is not less than the second packet loss rate threshold and the latency continues to increase, the Wi-Fi band occupancy rate is not less than the first band occupancy rate threshold and network connection requests from other robots in the same network are detected, the priority label of the task data is financial transaction and the network health score is less than the corresponding network health threshold, the network health diagnosis result is determined to represent multi-robot bandwidth competition. Wherein, the first packet loss rate threshold is greater than the second packet loss rate threshold.

5. The network dynamic optimization and cooperative adaptation method according to claim 4, characterized in that, Based on the network health diagnosis results, the corresponding network optimization strategy is executed using the standardized network interface card (NIC) application programming interface, including: The network health diagnosis results are used as the root cause of network problems, and corresponding execution strategies are matched in a pre-built network interface card (NIC) optimization knowledge base. The NIC optimization knowledge base stores multiple sets of mapping relationships between scenarios, robot models, root causes of network problems, execution strategies, and optimization effect indicators. Determine whether the execution strategy corresponding to the network health diagnosis result is matched; If so, the execution strategy will be used as the network optimization strategy and executed. If not, local inference is performed based on the network health diagnosis results to generate and execute the network optimization strategy.

6. The network dynamic optimization and cooperative adaptation method according to claim 5, characterized in that, The construction process of the network interface card (NIC) optimization knowledge base includes: Configure a standardized dictionary; wherein the standardized dictionary contains standardized definitions of scenarios, robot models, network problem root causes, execution strategies, and optimization performance indicators; Obtain complete optimization log packages uploaded by multiple robots; wherein, the complete optimization log package includes at least basic identification data, original state data at the time the problem occurred, task context data, root cause diagnosis results, execution strategy instructions, and strategy execution effect data; Based on the standardized dictionary, data cleaning and standardization processing are performed on the data in each of the complete optimized log packages; A mapping relationship is established based on the standardized data; wherein the mapping relationship includes at least a one-to-many mapping relationship between the scene and the robot model, a many-to-one mapping relationship between the scene, the robot model and the original state data and the root cause of the network problem, a one-to-many or many-to-one mapping relationship between the root cause of the network problem and the execution strategy, and a one-to-one mapping relationship between the execution strategy and the optimization effect index. A database table is established based on the mapping relationships described above; wherein, the database table includes at least a case master table, a model scenario association table, a root cause strategy association table, and an effect indicator detail table; Create indexes for the core fields and combined query indexes for each of the aforementioned database tables.

7. The network dynamic optimization and cooperative adaptation method according to claim 5 or 6, characterized in that, Also includes: Obtain the complete optimization log package uploaded by each robot according to the preset cycle; Based on the complete optimization log packages, the execution strategies in the network interface card optimization knowledge base are optimized and adjusted through statistical analysis and machine learning algorithms.

8. A network dynamic optimization and cooperative adaptation device, characterized in that, Applied to robots; the robot includes a pre-configured standardized network interface card (NIC) application programming interface and a dedicated adapter for the corresponding model; the standardized NIC application programming interface is used to provide network service invocation methods for the upper layer, and the dedicated adapter is used to provide the robot with a dedicated hardware interface type, protocol, and specification; the device includes: The acquisition module is used to acquire network data, hardware and environment data, and task data of the currently executing task; The determination module is used to determine the current network health diagnosis result based on the network data, the hardware and environment data, and the task data; The optimization module is used to execute corresponding network optimization strategies based on the network health diagnosis results using the standardized network interface card application programming interface.

9. A network dynamic optimization and collaborative adaptation device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the network dynamic optimization and cooperative adaptation method as described in any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the network dynamic optimization and cooperative adaptation method as described in any one of claims 1 to 7.

Images