Method of initializing a controller area network interface, electronic device and robot

Abstract

Disclosed are a method for initializing a controller area network interface, an electronic device, and a robot. The method for initializing a controller area network interface provided by the present disclosure is suitable for interface initialization in the CAN bus communication scenario of an industrial robot. By adopting a multi-source hierarchical configuration analysis mechanism, the priority of configuration sources such as environment variables and command line parameters is determined, CAN interface zero-configuration deployment is achieved, and the configuration flexibility and environment adaptation capability are greatly improved. By introducing a state-aware redundant configuration skipping mechanism, the current state of the interface is queried during initialization, unnecessary repeated operations are skipped, hardware loss and initialization delay are reduced, and system startup efficiency is improved. The method has a graceful degradation strategy, and in a multi-interface scenario, the failure of partial interface initialization does not block the overall service startup, thereby improving the system fault tolerance and operation stability. Meanwhile, by adopting an initialization strategy with fixed interval retries, the method avoids the endless loop caused by the failure of initialization due to temporary faults.

Description

Technical Field

[0001] This application relates to the field of dexterous hand control technology, and more specifically, various exemplary embodiments relate to methods for initializing controller area network interfaces, electronic devices, and robots. Background Technology

[0002] Controller Area Network (CAN) bus, as a mature and reliable fieldbus technology in the industrial field, uses a dedicated standardized communication interface to achieve stable and efficient physical connection and real-time data interaction with various actuators, servo drive modules, and high-precision sensing units mounted on industrial robots. This establishes a backbone link for field control throughout the entire robot, providing a solid communication foundation for robot motion posture control, precise execution of work actions, and comprehensive operational status monitoring. It enables centralized and integrated management of the entire robot by the main control system. This dedicated communication interface, as the core switching hub between the CAN bus signal and the robot's underlying hardware, undertakes critical signal adaptation and electrical protection functions. It not only performs level conversion between different electrical specifications but also achieves strong and weak electrical signal isolation through opto-isolation and electromagnetic isolation technologies. Simultaneously, it enhances bus driving capabilities, expands the effective communication distance and the number of nodes, ensuring that the CAN bus standard communication protocol can be accurately parsed, recognized, and smoothly executed by the robot control system. This provides an indispensable underlying hardware support, establishing a safe and reliable hardware channel for the efficient issuance of upper-level control commands and the real-time feedback of underlying device operating data. Through this standardized communication interface, the CAN bus can seamlessly connect and efficiently collaborate with various robot peripherals. This significantly simplifies the overall wiring design of the control system, reduces hardware deployment and subsequent maintenance costs, and greatly improves the real-time performance, accuracy, and stability of control signal transmission, effectively reducing data transmission latency and error rate. This enables the robot's main control unit to quickly receive feedback information, promptly issue control commands, and precisely coordinate the synchronous and orderly operation of various mechanical components and drive modules. This ensures continuous, uninterrupted, high-precision, and high-reliability operation of the robot under complex industrial conditions such as welding, handling, assembly, and sorting, fully meeting the efficient and stable automated control requirements of industrial robots in intelligent manufacturing scenarios. Summary of the Invention

[0003] The subject matter of the independent claims is provided according to several aspects. Further aspects are defined in the dependent claims. Embodiments that do not fall within the scope of the claims should be interpreted as examples that aid in understanding this disclosure.

[0004] According to a first aspect of this disclosure, a method for initializing a controller local area network (Controller Area Network) interface is provided, which may include: querying the current state and current configuration information of the Controller Area Network interface to be initialized; when the current state is in a startup state and the current configuration information is the same as the target configuration information, determining that the Controller Area Network interface initialization is complete and terminating the initialization method; when the current state is in a startup state and the current configuration information is different from the target configuration information, initializing the Controller Area Network interface based on the target configuration information; determining whether the configuration information of the initialized Controller Area Network interface is the same as the target configuration information; when the configuration information of the initialized Controller Area Network interface is different from the target configuration information, determining that the initialization is abnormal and judging whether the number of initialization retries is less than a predetermined threshold; when the number of retries is less than the predetermined threshold, re-initializing the Controller Area Network interface; when the number of retries is not less than the predetermined threshold, determining that the Controller Area Network interface initialization has failed.

[0005] According to a second aspect of this disclosure, an electronic device is provided, which may include: at least one processor; and at least one memory storing instructions, wherein when executed by the at least one processor, the electronic device performs at least one operation, the operation including: querying the current state and current configuration information of a controller local area network (Controller Area Network) interface to be initialized; when the current state is a startup state and the current configuration information is the same as target configuration information, determining that the Controller Area Network interface initialization is complete and terminating the initialization method; when the current state is a startup state and the current configuration information is different from the target configuration information, initializing the Controller Area Network interface based on the target configuration information; determining whether the configuration information of the initialized Controller Area Network interface is the same as the target configuration information; when the configuration information of the initialized Controller Area Network interface is different from the target configuration information, determining that the initialization is abnormal and judging whether the number of initialization retries is less than a predetermined threshold; when the number of retries is less than the predetermined threshold, re-initializing the Controller Area Network interface; when the number of retries is not less than the predetermined threshold, determining that the Controller Area Network interface initialization has failed.

[0006] According to a third aspect of this disclosure, an electronic device is provided, which may include means for performing the method according to the first aspect described above.

[0007] According to a fourth aspect of this disclosure, a computer-readable medium is provided that may include program instructions, when executed, to implement the method described in accordance with the first aspect above.

[0008] According to a fifth aspect of this disclosure, a computer program product is provided that may include instructions, which, when executed by a processor, perform the method described in accordance with the first aspect above.

[0009] According to a sixth aspect of this disclosure, a robot is provided, which may include: a robotic arm and an actuator disposed at the end of the robotic arm; and a controller electrically connected to the robotic arm and the actuator, respectively, the controller being configured to perform the method according to the first aspect described above.

[0010] The computer program product may include or be embodied in a computer-readable (storage) medium, on which computer-executable computer program instructions and / or programs that can be directly loaded into the internal memory of a computer or its processor are stored.

[0011] It should be understood that the above general description and the following specific embodiments are merely exemplary and illustrative, and do not limit the scope of the invention.

[0012] It should be understood that the above general description and the following specific embodiments are merely exemplary and illustrative, and do not limit the scope of the invention. Attached Figure Description

[0013] The above and other objects, features, and advantages of this application will become more apparent from the more detailed description of the embodiments of this application in conjunction with the accompanying drawings. The drawings are provided to further illustrate the embodiments of this application and form part of the specification. They are used together with the embodiments of this application to explain this application and do not constitute a limitation thereof. In the drawings, the same reference numerals generally represent the same components or steps.

[0014] Figure 1 A schematic diagram of a dexterous hand control system that can implement exemplary embodiments of the present disclosure is shown;

[0015] Figure 2 A schematic diagram illustrating the overall architecture of a cross-platform CAN bus bridging service according to exemplary embodiments of the present disclosure is shown.

[0016] Figure 3 A schematic diagram illustrating a multi-source hierarchical configuration resolution process according to an exemplary embodiment of the present disclosure is shown.

[0017] Figure 4 This diagram illustrates an interface initialization and step-by-step startup process with retry backoff according to an exemplary embodiment of the present disclosure;

[0018] Figure 5 A schematic diagram showing the structure of a calibrated annular buffer according to an exemplary embodiment of the present disclosure;

[0019] Figure 6 A schematic diagram illustrating a two-layer health monitoring and automatic recovery process according to an exemplary embodiment of the present disclosure is shown.

[0020] Figure 7A flowchart illustrating an exemplary method according to an exemplary embodiment of the present disclosure;

[0021] Figure 8 A flowchart illustrating an exemplary method according to an exemplary embodiment of the present disclosure;

[0022] Figure 9 A flowchart illustrating an exemplary method according to an exemplary embodiment of the present disclosure;

[0023] Figure 10 An example block diagram of an example device according to an exemplary embodiment of the present disclosure is shown;

[0024] Figure 11 An example block diagram of an example device according to an exemplary embodiment of the present disclosure is shown;

[0025] Figure 12 An example block diagram of an example device according to an exemplary embodiment of the present disclosure is shown;

[0026] Figure 13 An example block diagram of an example device according to an exemplary embodiment of the present disclosure is shown. Detailed Implementation

[0027] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the spirit of the contents disclosed in the present invention will be clearly explained below with reference to the accompanying drawings and detailed description. After understanding the embodiments of the present invention, any person skilled in the art can make changes and modifications based on the technology taught in the present invention without departing from the spirit and scope of the present invention.

[0028] The illustrative embodiments and descriptions of the present invention are used to explain the invention, but are not intended to limit the invention. Furthermore, elements / components using the same or similar reference numerals in the drawings and embodiments are used to represent the same or similar parts.

[0029] The terms "first," "second," etc., used in this document are not intended to specifically refer to order or sequence, nor are they intended to limit the invention. They are merely used to distinguish elements or operations described using the same technical terms.

[0030] The directional terms used in this article, such as up, down, left, right, front, or back, are for reference only when referring to the accompanying drawings. Therefore, the use of directional terms is for illustrative purposes and not to limit this work.

[0031] The terms “include,” “including,” “have,” “contain,” etc., used in this article are all open-ended terms, meaning that they include but are not limited to.

[0032] The term "and / or" as used herein includes any or all of the things mentioned.

[0033] The term "multiple" in this article includes "two" and "more than two"; the term "multiple groups" in this article includes "two groups" and "more than two groups".

[0034] The terms "approximately," "about," etc., used herein are intended to modify any quantity or error that may vary slightly, but these slight variations or errors do not change the essence of the quantity or error. Generally, the range of slight variations or errors modified by such terms may be 20% in some embodiments, 10% in others, 5% in still others, or other values. Those skilled in the art should understand that the aforementioned values ​​can be adjusted according to actual needs and are not limited thereto.

[0035] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0036] When expressions such as "at least one of A, B, and C" are used, they should generally be interpreted in accordance with the meaning commonly understood by a person skilled in the art (e.g., "a system having at least one of A, B, and C" should include, but is not limited to, systems having A alone, having B alone, having C alone, having A and B, having A and C, having B and C, and / or having A, B, and C, etc.). When expressions such as "at least one of A, B, or C" are used, they should generally be interpreted in accordance with the meaning commonly understood by a person skilled in the art (e.g., "a system having at least one of A, B, or C" should include, but is not limited to, systems having A alone, having B alone, having C alone, having A and B, having A and C, having B and C, and / or having A, B, and C, etc.). A person skilled in the art should also understand that any conjunction and / or phrase that substantially arbitrarily indicates two or more optional items, whether in the specification, claims, or drawings, should be understood to indicate the possibility of including one of these items, either of these items, or both items. For example, the phrase “A or B” should be understood as including the possibility of “A” or “B”, or “A and B”.

[0037] The following embodiments are exemplary. Although the specification refers to "a," "an," or "some" embodiments in various places, this does not necessarily mean that each reference refers to the same embodiment, or that a specific feature applies only to a single embodiment. Individual features of different embodiments may also be combined to provide other embodiments. Moreover, when specific features, structures, or characteristics are described in conjunction with embodiments, whether explicitly described or not, such features, structures, or characteristics will be applied to other embodiments to the extent that those skilled in the art possess the knowledge to do so. It should be understood that although terms such as "first" and "second" may be used to describe various elements, these elements should not be limited by these terms. These terms are merely used to distinguish one element from another.

[0038] Figure 1 An example of a dexterous hand control system 100 is shown, in which exemplary embodiments disclosed herein may be implemented. See also Figure 1 The dexterous hand control system 100 may include a host control terminal 110, a control device 120, multiple robotic arms 130 and 132, and multiple dexterous hands 140 and 142 connected to the robotic arms 130 and 132.

[0039] Dexterous hands 140 and 142 can be mounted at the ends of robotic arms 130 and 132, respectively, to enable direct interaction between the robot and the work object, such as precise grasping, posture adjustment, and accurate manipulation. Dexterous hands 140 and 142 can adopt a multi-joint modular design, including components such as finger units and hand units. Robotic arms 130 and 132 can drive dexterous hands 140 and 142 to achieve spatial position movement and posture adjustment, and can also facilitate the connection between dexterous hands 140 and 142 and the control device 120. Robotic arms 130 and 132 can adopt a serial multi-joint structure, with each joint equipped with components such as motors to control joint movement. Dexterous hands 140 and 142, as well as robotic arms 130 and 132, can use a bus interface to connect to the bus architecture of the control device 120 and receive commands issued by the control device 120.

[0040] The dexterous hands 140 and 142 can be connected to the robotic arms 130 and 132 via rigid or extended connections. A rigid connection involves the robotic arms 130 and 132 connecting to their base interfaces via adapter flanges. An extended connection involves adding other devices between the robotic arms 130 and 132 and the dexterous hands 140 and 142, such as a six-dimensional wrist force sensor. The robotic arms 130 and 132 can connect to one end of the force sensor, while the other end connects to the dexterous hands 140 and 142, enabling real-time acquisition and transmission of force / torque information.

[0041] Control device 120 is used to schedule the actions of the dexterous hand system in real time, enabling coordinated operation of dexterous hands 140, 142 and robotic arms 130, 132 by issuing commands. Control device 120 can issue work commands to robotic arms 130, 132 and dexterous hands 140, 142 based on the work tasks issued by the host control terminal 110. It can also perform real-time calculations on the work parameters fed back by robotic arms 130, 132 and dexterous hands 140, 142 to generate and issue control commands. Control device 120 can adopt an embedded architecture, such as a combination of a Field Programmable Gate Array (FPGA) and an Advanced Reduced Instruction Set Machine (ARM) processor. At least a portion of control device 120 can be implemented as a controller for executing, or via a processor, the processes or methods described in this disclosure.

[0042] The control device 120 can integrate bus interfaces, such as Ethernet for Control Automation Technology (EtherCAT) and CANopen (a high-level industrial communication protocol for Controller Area Networks), to enable signal interaction with the robotic arm joint drive units, dexterous hands, and various optional sensors. This includes issuing motion commands and receiving operating status feedback from the robotic arm joint drive units 130 and 132, as well as the dexterous hands 140 and 142. The control device 120 can supply power to the servo motors of each joint of the robotic arm 130 and 132, as well as to the dexterous hands 140 and 142, via power cables.

[0043] The host control terminal 110 serves as a platform for operators to interact with the robot control system, providing the dexterous hand control system 100 with functions such as human-machine interaction and task management, including job programming, parameter configuration, task assignment, overall machine operation status monitoring, and data management. The host control terminal 110 can be a touch-screen tablet, mobile phone, or desktop computer, and may have corresponding control software. A bidirectional communication connection can be established between the host control terminal 110 and the control device 120 via Ethernet, and long-distance communication can be achieved using protocols such as TCP / IP.

[0044] In industrial robot CAN bus communication scenarios, the CAN interface configuration lacks sufficient flexibility. This deficiency is not limited to the fixed timing of configuration but also gives rise to a series of problems affecting system performance, adaptability, and operational efficiency, failing to meet the complex and ever-changing operational needs and scenario adaptation requirements of industrial robots. On the one hand, existing CAN interface configuration methods lack a multi-source configuration fusion mechanism. Most existing solutions rely on a single configuration method (such as a fixed configuration file or compile-time parameters), which cannot utilize environment variables to achieve rapid adaptation to different deployment environments, nor can it achieve temporary on-site configuration adjustments through command-line parameters, and it lacks automatic system detection capabilities, forcing interface configuration to rely on manual settings. This not only increases the cost of manual configuration but also easily leads to configuration errors due to human error, thereby causing CAN bus communication failures and affecting the stability of the robot control system. In addition, existing solutions lack optimized design in the interface initialization and shutdown processes, further amplifying the drawbacks caused by inflexible configuration. During the interface initialization phase, regardless of whether the current interface is already in a correctly configured startup state, the system repeatedly executes the complete initialization process. Numerous unnecessary hardware operations not only increase initialization latency but also accelerate the wear and tear on the interface hardware, shortening the equipment's lifespan. Furthermore, in multi-interface deployment scenarios, if some interfaces fail to initialize, existing solutions often directly block the startup of the entire robot's CAN bus communication service, leading to system-wide paralysis and extremely poor fault tolerance. During the system shutdown phase, the lack of an orderly resource release mechanism often results in improper socket closure, resource leaks, or forced interruptions of ongoing requests. This can lead to data loss and affect the stability of subsequent system restarts, increasing maintenance complexity. Existing CAN interface configuration schemes, lacking runtime dynamic adjustment capabilities, multi-source configuration fusion mechanisms, and optimized initialization and shutdown strategies, cannot adapt to the complex and ever-changing operating scenarios of industrial robots. They suffer from numerous defects such as low configuration efficiency, poor fault tolerance, high maintenance costs, and insufficient system stability, making it difficult to meet the high-precision, high-continuity, and high-reliability communication control requirements of industrial robots.

[0045] Furthermore, in the complex and harsh operating environment of industrial sites, existing CAN bus communication solutions have weak fault response capabilities and are difficult to adapt to the complex fault scenarios in industrial sites. Various sudden faults such as unexpected equipment disconnection, CAN interface bus errors (Bus-Off), and electromagnetic interference (EMI) are common in industrial sites. These faults may be caused by a variety of factors such as equipment vibration, aging of lines, external electromagnetic radiation, and unstable power supply. When faced with such faults, existing solutions lack effective automatic detection and intelligent recovery mechanisms. Once the CAN interface fails, manual intervention is required to reconfigure, initialize, and troubleshoot the interface. In unattended industrial deployment scenarios, this can lead to a long downtime of the system, which not only affects production progress but may also cause serious economic losses and even trigger a chain of problems such as equipment damage. On the other hand, the lack of a runtime health monitoring mechanism prevents early warning and proactive prevention of faults. It lacks the ability to continuously and in real-time monitor the CAN interface's operational status and cannot collect and analyze key indicators during interface operation. This results in maintenance personnel being unable to promptly grasp the interface's health status and identify potential faults in advance, forcing them to react passively after a fault occurs, further exacerbating its impact. Simultaneously, fault recovery efficiency is extremely low. Whether it's interface anomalies caused by bus errors or communication interruptions due to USB device disconnections, existing solutions lack a systematic automatic detection and recovery mechanism. After a fault occurs, manual troubleshooting and handling are required, a cumbersome and time-consuming process that fails to meet the high requirements of industrial systems for communication continuity and reliability. Especially in high-frequency, high-precision industrial robot operations, even a brief communication interruption can lead to serious consequences such as operational deviations and equipment downtime.

[0046] To address the technical problems of strong platform coupling and lack of standardized remote interfaces in existing CAN bus communication solutions, this disclosure proposes a cross-platform HTTP bridging service method suitable for CAN bus communication scenarios in industrial robots, enabling remote invocation of the CAN interface. This method, on the one hand, constructs a platform abstraction layer to shield the underlying differences between different operating systems and CAN hardware drivers, decoupling the upper-layer CAN communication logic from the operating system platform, thereby achieving the goal of "develop once, deploy on multiple platforms" and significantly reducing development and maintenance costs. On the other hand, by providing a standardized HTTP-based remote access interface, it simplifies the interface process between upper-layer applications and the CAN bus, breaking down interface barriers in existing solutions and improving system integration and scalability. The proposed solution enables a unified cross-platform CAN bus communication service, allowing for stable deployment and operation on different operating system platforms without any modification to the upper-layer application code, effectively solving the problems existing in the prior art.

[0047] To address the core shortcomings of existing CAN interface technologies, such as inflexible configuration, weak fault tolerance, and low operational efficiency, this disclosure proposes an interface initialization and configuration method suitable for CAN bus communication scenarios in industrial robots. By employing a multi-source hierarchical configuration parsing mechanism, the priority of configuration sources such as environment variables and command-line parameters is clearly defined, enabling zero-configuration deployment of the CAN interface and significantly improving configuration flexibility and environmental adaptability. By introducing a state-aware redundant configuration skipping mechanism, the current state of the interface is queried during initialization, skipping unnecessary repetitive operations, reducing hardware wear and initialization delays, and improving system startup efficiency. It also features graceful degradation and hierarchical orderly shutdown strategies, ensuring that the failure of initialization of some interfaces in multi-interface scenarios does not block the overall service startup, and resources are released in an orderly manner during shutdown, improving system fault tolerance and operational stability.

[0048] Addressing the core issues of existing CAN bus communication solutions, such as reliance on manual fault recovery, lack of runtime health monitoring, and insufficient system stability, this disclosure proposes a health monitoring and automatic recovery method suitable for CAN bus communication scenarios in industrial robots. Firstly, it employs a fixed-capacity ring buffer management system to ensure constant system memory usage, enabling safe concurrent access by multiple threads and improving system stability. Secondly, it adopts a dual-layer health monitoring and automatic recovery mechanism, balancing monitoring accuracy with bus resource utilization, enabling automatic fault self-healing and significantly shortening fault recovery time. Thirdly, its scientifically designed limited-number automatic recovery strategy avoids resource waste caused by permanent hardware failures while ensuring effective recovery from intermittent faults. Finally, it combines an adaptive batch reception strategy to achieve a balance between throughput and CPU usage, further enhancing system high availability and adapting to the communication needs of industrial robots.

[0049] Figure 2 A schematic diagram of a cross-platform CAN bus bridging service overall architecture 200 according to an exemplary embodiment of this disclosure is shown. Figure 2 As shown, the service architecture 200 may include a bridging service requester 270 and a bridging service provider 280. The bridging service requester 270 can initiate various requests to start CAN interface-related services. These requests can be real-time data transmission requirements or management operations such as interface configuration and status queries. The bridging service provider 280 can parse the requester 270's business requests, start the corresponding CAN interface service, and send back detailed results, real-time data, and status feedback during service execution to the requester 270. In some specific implementations, the bridging service requester 270 may be... Figure 1 The upper control terminal 110 carries the bridging service, while the bridging service provider 280 can be... Figure 1 The control equipment 120 is implemented.

[0050] See Figure 2 The bridging service requester 270 may include an upper-layer application 210, which can cover multiple scenarios such as industrial control and automated operation and maintenance. Examples include motion control applications for robot joint control, vision-guided applications based on machine vision, debugging tools for equipment debugging and troubleshooting, and various other web front-end applications that support remote operation and monitoring. The upper-layer application 210 can provide diverse services to users through graphical interfaces, command-line commands, or program calls. Users can trigger corresponding CAN service requests through the upper-layer application 210.

[0051] Once the upper-layer application 210 selects a specific service, the execution of that service can be achieved through the general API 215. The general API 215 encapsulates complex CAN bus communication functions and exposes them to the upper-layer application via an API. This allows users to avoid worrying about the underlying communication protocol of the CAN bus, hardware driver details, and platform differences of the operating system. They only need to call the API interface to send general business requests applicable to any operating system platform, thereby completing the corresponding CAN communication operation. In some implementations, the general API 215 can use a HyperText Transfer Protocol (HTTP) RESTful API as a standardized remote interface, mapping various CAN bus operations (such as message sending and receiving, status queries) to standardized HTTP requests. The general business requests sent are then either HTTP-based or Remote Procedure Call (RPC)-based business requests. This design allows the upper-layer application 210 to complete CAN bus communication by relying solely on a general standard HTTP client library. In alternative implementations, a CAN bus bridging service based on the Remote Procedure Call (RPC) protocol can be used instead of the HTTP RESTful API to implement the bridging service. The general business requests sent are then business requests based on the Remote Procedure Call protocol. For clarity, this disclosure uses HTTP as an example to illustrate the technical solution of this disclosure.

[0052] In some specific implementations, the general API 215 may include:

[0053] The API for message transmission and reception services is used to perform CAN message transmission and reception operations. In some implementations, the general service request constructed through the message transmission and reception API may include the target interface name (used to specify the CAN physical interface for data transmission), the CAN identifier (used to identify the message priority and the receiving object), the data payload (i.e., the specific service data to be transmitted), and optional extended frame flags (used to distinguish between standard frames and extended frames), etc.

[0054] APIs used for status monitoring are employed to obtain the operational status of robot or dexterous hand systems, providing decision-making support for maintenance personnel and upper-layer applications. In some implementations, the status information returned by the status monitoring API may include the overall system operational status (e.g., normal, warning, fault), health summaries (e.g., availability percentage of each interface, number of recent faults), detailed operational metrics for specified interfaces (e.g., bit rate, sampling points, number of error frames), and performance metrics conforming to the Prometheus format (e.g., message transmission / reception rate, average latency, interface occupancy). In some implementations, these metrics can be integrated with a monitoring platform to achieve visualized monitoring and alerting.

[0055] The API used for interface management can be used to manage the entire lifecycle of the CAN interface and ensure its normal operation. In some implementations, the functions provided by the interface management API may include initializing a specified CAN interface (allocating hardware resources and loading drivers for the interface), shutting down idle or faulty interfaces (releasing hardware resources and avoiding resource waste), resetting abnormal interfaces (clearing the error state of the interface and restoring normal communication capabilities), and updating configuration parameters at runtime (such as dynamically adjusting key parameters such as bit rate and sampling points without restarting the service).

[0056] The API for message listening services can be used to obtain CAN message information in a specified CAN interface buffer in real time. In some implementations, the message listening API can obtain historical CAN message records, detailed data of the most recent N (N is a natural number) messages, and message reception statistics (such as total number of messages received and number of invalid messages filtered out) in the specified interface buffer. In some implementations, the message listening API can also perform filtering operations by CAN identifier to facilitate users in quickly locating target messages.

[0057] The bridging service requester 270 can establish a communication connection with the bridging service provider 280 and initiate a service request through the aforementioned API interfaces, thereby obtaining the service response. In some implementations with high real-time requirements, the server (i.e., the bridging service provider 280) can actively push the service results and data to the bridging service requester 270 in real time, for example, by using a real-time push scheme based on web sockets.

[0058] In implementations that use HTTP RESTful APIs as a common interface, the HTTP server can also integrate various enhanced middleware to improve service stability, compatibility, and maintainability. This middleware may include:

[0059] Cross-domain middleware allows browsers from different origins (different domains, ports, or protocols) to directly call the bridging service API without the need to deploy a reverse proxy server for cross-domain forwarding, greatly simplifying the deployment process of web front-end applications, while also supporting concurrent access from multiple domains and ports.

[0060] Exception recovery middleware can capture various unexpected exceptions (such as null pointer exceptions, network interruption exceptions, hardware failure exceptions, etc.) in real time during business processing, and record complete exception stack information in the log (such as the location of the exception, call chain, parameter information, etc.). Simultaneously, it returns a simplified error log to the client to help developers quickly locate the problem. In some implementations, exception recovery middleware can be used to limit the impact of a single request exception, preventing the exception from spreading to the entire HTTP service process, thereby effectively reducing the risk of a single request failure escalating into a complete service outage.

[0061] Request logging middleware can be used to record detailed information about each HTTP request, such as: request timestamp, request method (e.g., GET / POST / PUT / DELETE), request path, response status code (e.g., 200 Success, 400 Parameter Error, 500 Internal Server Error), response time, and optional client IP address. In some implementations, this log information can be output to standard log files or log collection systems in real time, thereby providing auditability for HTTP services. This allows operations personnel to clearly trace the complete chain of "who made what request to which interface at what time, and what the response result was," facilitating post-incident review of faults or security incidents.

[0062] In some alternative implementations, the bridging service requester 270 may also pass the service start request via shared memory inter-process communication, without relying on the general API 215.

[0063] In some optional implementations, the bridging service requester 270 may also include a UDP discovery mechanism 220. The bridging service provider 280 (e.g., a CAN bridging service node) may send UDP broadcast packets at fixed intervals (e.g., once per second) to a broadcast address in the local area network (i.e., the address corresponding to the broadcast port of the UDP discovery mechanism 220). The broadcast packets contain device and address information, such as the CAN bridging service node's device name, model, hardware version, IP address, port number, number of supported CAN interfaces, and service status. In this way, the upper-layer application 210 does not need to manually configure the service node's IP address; it can automatically discover all running CAN bridging service nodes in the local area network simply by listening to the broadcast port, quickly obtaining key information such as "which bridging service nodes are running in the network and what their respective configuration information is," and then automatically establish an HTTP connection with the bridging service provider 280.

[0064] See Figure 2The bridging service provider 280 may include multiple collaborative business components. Specifically, it may include: a message sender 225, used to encapsulate the request data of the bridging service requester 270 into CAN frames and send them to the CAN bus; a message listener 230, used to monitor the message data of the CAN bus in real time and provide feedback to the requester 270; a watchdog 235, used for system health monitoring and automatic recovery; and an interface manager 240, used to connect business logic and underlying interfaces. On the one hand, it can directly respond to the service requests of the bridging service requester 270 and perform operations such as interface initialization, configuration, startup, and shutdown; on the other hand, it can provide interfaces for the message sender 225, message listener 230, watchdog 235, etc., that need to communicate with the CAN bus. The business components communicating via the CAN interface provide the necessary runtime environment, such as interface handles, communication parameters, and status flags, ensuring that each component can access the CAN interface normally. Configuration parser 245 provides necessary configuration information support for interface initialization, such as key parameters like the CAN interface bit rate, sampling points, interface name, and buffer size, ensuring that the interface manager 240 can correctly perform initialization operations on the CAN interface. Platform abstraction layer 250 provides a unified platform abstraction layer foundation for other components of the bridging service requester 270 and bridging service provider 280, shielding them from the underlying differences between different operating system platforms. Specifically, business requests from the bridging service requester 270 can be passed to the platform abstraction layer 250 through business components such as message sender 225, message listener 230, and watchdog 235. Business components can call the standardized interfaces provided by the platform abstraction layer 250, which then maps these standardized interfaces to the native interfaces of the current operating system, thereby achieving cross-platform business implementation. Through the cooperation of the above business components, various services requested by the bridging service requester 270 can be implemented. In some implementations, the supported operating system platform may be Linux 255 or Windows 260. Those skilled in the art will understand that this disclosure uses Linux and Windows as examples only for illustrative purposes and not as a limitation on the counting scheme. The scheme of this disclosure can also be implemented on other operating system platforms, such as macOS, real-time operating systems (RTOS), etc., by extending the interface mapping logic of the platform abstraction layer.

[0065] When the bridging service starts, the platform abstraction layer 250 can first instantiate the Controller Area Network (CAN) service interface, then determine the currently running operating system platform, and establish a mapping relationship between the CAN service interface methods and the native interfaces of the currently running operating system platform. In some implementations, the platform abstraction layer 250 defines two sets of abstract CAN service interfaces: a socket provider interface and a command executor interface. Those skilled in the art will understand that the interface names are for illustrative purposes only and not as a limitation of the scheme; any other interface with similar functionality and a different name can be considered as an interface provided in this disclosure. The socket provider interface can define various operation methods for CAN sockets, such as:

[0066] The creation method allows you to create a socket object for CAN communication and allocate the corresponding system resources.

[0067] The enumeration method can iterate through all connected CAN physical interfaces in the current system and return information such as interface name and status.

[0068] The interface index acquisition method can convert the CAN interface name (such as can0, can1) that is easy for users to understand into an integer index number that the operating system kernel can recognize, making it convenient for the underlying driver to call;

[0069] The binding method can associate an existing socket with a specified CAN physical interface, ensuring that data can be transmitted through that interface;

[0070] The transmission method allows data in the CAN frame buffer to be sent to the CAN bus via a bound socket;

[0071] The receiving method can receive message data from the CAN bus through the CAN interface and store it in a specified buffer;

[0072] The close method can release system resources occupied by the socket and close the association with the CAN interface.

[0073] In some implementations, the methods of the socket provider interface can be mapped to the native interfaces of the operating system platform to enable the execution of corresponding CAN operations through the socket provider interface methods on different operating systems. For example, if the platform abstraction layer 250 detects that the currently running operating system platform is Linux, the methods of the socket provider interface can be mapped to the relevant functions of Unix sockets; if the currently running operating system platform is Windows, the methods of the socket provider interface can be implemented by calling the controller area network (CAN) driver interface provided by a third-party vendor, so that the socket provider methods can be converted into hardware call instructions that the Windows system can recognize, thereby realizing the CAN communication function. In some implementations, the CAN driver interface provided by the third-party vendor can be a PCAN driver.

[0074] The CommandExecutor interface is used to define the execution operations of system commands. In some implementations, the execution operations can include normal execution and execution with timeout. Normal execution can directly call native operating system commands or driver-provided tool instructions to complete operations such as CAN interface configuration and status query. Execution with timeout adds a time limit (e.g., 5 seconds) to normal execution; if the command execution time reaches this limit but is not completed, the command process will be forcibly terminated to prevent the entire service from stalling due to command blocking. In some implementations, the methods of the CommandExecutor interface can be mapped to the native interfaces of the operating system platform to enable the execution of corresponding CAN operations through the methods of the CommandExecutor interface on different operating systems. In some implementations, if the operating system platform is determined to be Linux, the CommandExecutor interface methods can be implemented by calling the Linux system's own command executor or system tool commands to complete the corresponding operations; if the operating system platform is determined to be Windows, the various methods provided by the CommandExecutor interface can be implemented by calling the vendor-provided Controller Area Network (CLAN) driver interface (e.g., the aforementioned PCAN driver) and utilizing the driver's built-in tool functions or command-line tools.

[0075] In some implementations, when bridging services are enabled, the components of the bridging service provider 280 can use the Controller Area Network (CAN) service interfaces provided by the platform abstraction layer 250—namely, the socket provider interface and the command executor interface—to call the native interfaces of the currently running operating system platform to initialize the CAN service runtime environment, thereby collaboratively completing the initialization of the CAN service runtime environment. In some implementations, the initialization process may include: the configuration parser 245 component loading and parsing configuration information; the interface manager 240 calling the command executor interface to configure CAN interface parameters based on the configuration information; then creating and binding sockets through the socket provider interface; the message sender 225 and message listener 230 initializing buffers and thread resources; and the watchdog 235 starting a health monitoring cycle. Once all components of the bridging service provider 280 have completed initialization and entered a ready state, the bridging service requester 270 can issue specific CAN service requests (such as message sending, status query, interface reset, etc.) through the general API 215. After receiving the general service request (i.e., the aforementioned CAN service request) applicable to any operating system platform for starting Controller Area Network (CAN) services, the bridging service provider 280 can invoke the CAN service interface method based on the requested CAN service; and further, based on the invoked CAN service interface method and the mapping relationship, invoke the native interface corresponding to the currently running operating system platform to start the CAN service. In some embodiments, the bridging service provider 280 can schedule corresponding service components (e.g., message sender 225, message listener 230, etc.) and complete the actual execution of the service in the robot system or dexterous hand system through the interface mapping logic of the platform abstraction layer 250. The operations performed by other components of the bridging service provider 280 will be discussed in detail later in this disclosure.

[0076] In summary, by defining the socket provider interface and command executor interface in this disclosure, the differences in operating system platforms of the bridging service provider 280 are shielded, ensuring that the initialization process of the CAN service runtime environment remains consistent across different platforms. Developers do not need to write differentiated code for different platforms. Furthermore, by uniformly converting the service requests of the bridging service requester 270 into commands or operations implementable by the local operating system platform, the upper-layer application 210 only needs to rely on a standard HTTP client library to complete CAN bus communication. Users do not need to install any CAN drivers or platform-specific runtime environments, nor do they need to require the client and the bridging service provider 280 to use the same operating system platform. This design achieves complete decoupling between the CAN communication logic and the operating system platform implementation, thereby achieving a dual cross-platform service mechanism for deployment and business. This allows the solution disclosed in this disclosure to be used on any operating system platform, providing a unified and efficient bridging service for CAN bus communication in different scenarios and with different devices.

[0077] Figure 3 This diagram illustrates a multi-source hierarchical configuration parsing process 300 according to an exemplary embodiment of this disclosure. This multi-source hierarchical configuration parsing process 300 can be used for configuration parsing and automatic discovery of CAN interfaces. It is typically executed after the platform abstraction layer 250 has completed the instantiation and method configuration of the CAN service interface. It can determine the list of CAN interfaces that need to be managed in the current system and their parameter configurations (such as bit rate, sampling points, automatic restart timeout, etc.), providing accurate configuration basis for subsequent interface initialization. Process 300 can be... Figure 1 Control device 120 or Figure 2 The configuration is parsed using component 245.

[0078] See Figure 3 In operation 310, the multi-source hierarchical configuration resolution process 300 can be started.

[0079] In operation 315, the first step is to check whether the system environment variables are set. In this disclosure, the environment variable can be a source of the highest priority list of interfaces, allowing the deployer to explicitly specify the list of CAN interfaces to be managed via environment variables when the service starts. As an example, this disclosure defines the environment variable as CAN_PORTS for clarity; those skilled in the art can use other names to set the environment variable according to actual needs, as long as the configuration resolution component can correctly recognize it. In some implementations, the CAN_PORTS environment variable can be set using containerized deployment (such as Docker containers) and multi-instance deployment, for example, by setting it in the Dockerfile using the ENV instruction, or dynamically specifying it using the -e parameter when the container starts. The value format of CAN_PORTS can be a list of interface names separated by commas, for example, CAN_PORTS=can0,can1 indicates that two interfaces, can0 and can1, need to be managed; if multiple interfaces need to be managed, it can be expanded in a similar format, such as CAN_PORTS=can0,can1,can2. In some implementations, if the current operating system platform is Linux, CAN_PORTS can be temporarily set by entering `export CAN_PORTS=can0,can1` in the command line, or the command can be added to the configuration file to make the setting permanent. If the current operating system platform is Windows, CAN_PORTS can be temporarily set by entering `set CAN_PORTS=can0,can1` in the command prompt, or the CAN_PORTS variable can be added to the system environment variables panel and the corresponding value can be set to make the setting permanent.

[0080] If it is determined in operation 315 that the environment variable has been set (i.e., the CAN_PORTS variable exists and has a valid value), operation 320 can be entered. The set environment variable is used to obtain the CAN interface list, and subsequent command-line parameter checks and system automatic detection are skipped, directly executing parameter verification operation 350. In some implementations, the environment variable parsing process can be as follows: first, the original string of the environment variable (e.g., "can0, can1, can2") is read; then, the original string is split into several string items using commas ","; next, leading and trailing whitespace characters are removed from each string item; finally, empty elements are removed (e.g., empty strings generated after splitting), thus obtaining the final interface name array. For example, if the original value of CAN_PORTS is "can0,can1", the parsed interface name list can be [can0,can1]; if the original value of CAN_PORTS is "can0, can1, can2", the parsed interface name list can be [can0, can1, can2].

[0081] If it is determined in operation 315 that the environment variable is not set (e.g., the CAN_PORTS variable does not exist or has an empty value), then operation 325 can be entered to further determine whether the command line specifies the CAN interface-related parameters. Command line parameters can be used to flexibly specify interface configurations when the service starts. If it is determined that the command line has specified the relevant parameters, then operation 330 is entered to check and use the command line parameters to obtain the CAN interface list, and then the subsequent parameter verification operation 350 is executed. In some implementations, the command line parameters can include two types: the first type can be a command line parameter that directly specifies the interface name, such as -can-ports. When it is necessary to specify the interface list [can0, can1], the parameter -can-ports=can0,can1 can be added to the command to start the service (the parameter format may vary slightly in different programming languages); the second type is a command line parameter that specifies the number of interfaces, such as -can-count. When it is necessary to specify the interface list [can0, can1], the parameter -can-count=2 can be added, and the system can automatically generate the corresponding interface list, i.e., can0, can1, according to the template can{i} (where i starts from 0 and increments). In some implementations, if two command-line arguments are used simultaneously (e.g., both -can-ports and -can-count are specified), the system can prioritize the -can-ports command-line argument and ignore the -can-count parameter configuration to ensure the accuracy of the interface list.

[0082] If, in operation 325, it is determined that the command line did not specify relevant parameters (i.e., the `-can-ports` or `-can-count` parameters were not detected), then operation 335 can be initiated, triggering the system's automatic detection process. This process calls relevant interface methods to automatically discover the currently connected CAN interfaces in the system. In some implementations, if the current operating system platform is Linux, system commands such as `ip link show` and `ls / sys / class / net` can be executed via the command executor interface to obtain a list of registered network interfaces in the system. Then, interfaces of type CAN can be filtered out as the automatically discovered CAN interface list. If the current operating system platform is Windows, the enumeration method provided by the socket provider interface can be called to obtain a list of connected PCAN-USB devices (including device ID, channel number, etc.), and these physical channel names can be mapped to unified logical names to form the final CAN interface list. If a CAN interface is successfully discovered through automatic system detection in operation 335, then in operation 340, the parameter verification in operation 350 can be performed using the CAN interface list from the detection results. If no CAN interface is found, then operation 345 can be initiated, reverting to the default values. In some implementations, the default value may include a default interface name (such as can0). The default value is designed to deal with empty environment scenarios where environment variables are not set, command line parameters are not given, and automatic detection does not find the device. This allows the system to retain a deterministic configuration target even without any explicit configuration or hardware connection, preventing the service from directly exiting due to blank configuration, and also providing convenience for development and testing.

[0083] In operation 350, communication parameter verification can be performed on each CAN interface in the CAN interface list obtained through any of the aforementioned operation methods (environment variables, command-line arguments, system auto-detection, default values). In some implementations, parameter verification may include:

[0084] Bit rate verification checks whether the bit rate of the interface belongs to the standard CAN rate set {10000, 20000, 50000, 100000, 125000, 250000, 500000, 1000000}bps. If the configured bit rate is not in this set (e.g., 300000bps), the verification fails.

[0085] The sampling point is checked to see if the value of the sampling point is within the open interval (0, 1) (such as 0.8, 0.875, etc.). If the value of the sampling point is 0, 1, or greater than 1 or less than 0, the check fails.

[0086] In some implementations, parameter validation can be extended to other rules, such as requiring the automatic restart timeout to be a non-negative integer and requiring the interface name to conform to the system naming conventions.

[0087] Finally, in operation 355, the final interface configuration list after parameter verification can be output. This list contains the name of each interface and its corresponding communication parameters (such as bit rate, sampling point, automatic restart timeout, etc.), and the configuration list is passed to the interface manager 240 as the basis for subsequent interface initialization.

[0088] This disclosed multi-source hierarchical configuration parsing process 300 prioritizes environment variables, command-line parameters, system automatic detection, and default values. Specifically, it first determines the target configuration information based on environment variables; if environment variables are not set, it determines the target configuration information based on command-line parameters; if command-line parameters are not set, it calls the platform's automatic detection function to determine the target configuration information; if the automatic detection function does not find the controller LAN interface, it determines the target configuration information as the default target configuration information, thus constructing a flexible and reliable configuration source system. This design allows the system deployer to provide explicit configuration through environment variables or command-line parameters according to actual operational needs, achieving precise interface management; and to rely on the system's automatic detection function to discover and configure connected CAN hardware devices without needing or requiring explicit configuration, even using default values ​​to ensure normal service startup when there is no hardware connection. This achieves zero-configuration deployment of the CAN interface, greatly reducing system deployment complexity and maintenance costs.

[0089] Figure 4 This diagram illustrates an interface initialization and step-by-step startup process 400 with retry backoff according to an exemplary embodiment of this disclosure. Process 400 can be executed after configuration parsing is completed in process 300, and is used to initialize the configured CAN interfaces one by one to a usable state, providing a stable hardware foundation for subsequent CAN communication. In some embodiments, process 400 can be... Figure 1 Control device 120 or Figure 2 The interface manager 240 is used for implementation.

[0090] See Figure 4 The execution of process 400 begins with operation 410, which can receive the final interface configuration list from the multi-source hierarchical configuration parsing process 300.

[0091] In operation 415, an interface existence verification can be performed first, i.e., checking whether the controller LAN interface exists, to intercept deterministic errors such as "interface does not exist" in advance and avoid wasting time on subsequent initialization operations. Interface existence verification can be performed by calling native commands or driver interfaces of the operating system through the aforementioned command executor interface to verify whether the target CAN interface is registered in the operating system. In some implementations, the verification process can be implemented by looking up a table: the system maintains a CAN interface mapping table, recording the correspondence between connected CAN hardware devices and logical interface names. By querying this mapping table, it can be confirmed whether the logical channel name of the target interface (e.g., can0) has a corresponding physical device; if it exists, the verification passes; if it does not exist, the interface is determined to be non-existent. If the verification result of operation 415 indicates that the interface does not exist, operation 420 is executed, immediately returning initialization error information and terminating the subsequent initialization process of the interface, while recording an error log for maintenance personnel to troubleshoot. In some implementations, the error information may include the non-existent interface name.

[0092] If the verification result of operation 415 indicates that the interface exists, operation 425 can be initiated to perform a state-aware redundant configuration skip check. This involves querying the current state and configuration information of the Controller Area Network (CAN) interface to be initialized. If the current state is "started" and the current configuration information matches the target configuration information, the CAN interface initialization is complete, and the initialization method is terminated. If the current state is "started" and the current configuration information differs from the target configuration information, the CAN interface can be initialized based on the target configuration information. The redundant configuration skip check avoids repeated shutdown-configuration-start operations on correctly configured interfaces, thereby reducing unnecessary hardware operations and initialization delays and improving system startup efficiency. In some implementations, the current running state of the target interface (including whether it is started and current configuration information such as current bit rate and sampling points) can be queried through the command executor interface and compared with the target state obtained from configuration parsing (e.g., target bit rate, target sampling points, and other target configuration information). When the query result shows that the current state is completely consistent with the target state (i.e., the interface has been started and the parameter configuration meets the requirements), the subsequent steps of closing the interface, configuring parameters, and starting the interface are skipped, and operation 430 is executed directly, returning the result that the interface initialization is successful, and the interface initialization process ends. For example, if the target configuration of the device connected to can0 is a bit rate of 1Mbps and a sampling point of 0.875, and the redundancy configuration check determines that interface can0 is currently started, with a bit rate of 1Mbps and a sampling point of 0.875, consistent with the target configuration, then the initialization is directly determined to be successful; if the query result shows that the current interface is not started or the current state is inconsistent with the target state, the subsequent initialization process of the interface is entered. Specifically:

[0093] If, in operation 425, it is determined that the interface is currently in an active state but the configuration is inconsistent, the interface can first be shut down in operation 435. This involves closing the corresponding Controller Area Network (CAN) interface to release related resources and prepare for subsequent reconfiguration. In some implementations, to improve the compatibility and reliability of the shutdown operation, a double-shutdown method can be used to perform the interface shutdown: first, the main method is used to attempt to shut down the interface; if the main method fails (e.g., returns an error such as command not found, call timeout, insufficient permissions), the interface is automatically shut down using a backup method. In some implementations, the main method can be an efficient shutdown method supported by a newer version of the operating system platform (e.g., the `iplink set can0 down` command in Linux), and the backup method can be a compatible shutdown method supported by all versions of the operating system platform (e.g., the `ifconfig can0 down` command in Linux). In some implementations, the specific process of the double-shutdown method rollback can be: first, the main method is called to perform the shutdown operation; if the method returns successfully, the interface shutdown is considered complete; if it returns a command not found or the call fails, the interface is automatically shut down to try the backup method; if the backup method also fails, a shutdown error log is recorded, and the interface initialization process is terminated.

[0094] In some implementations, after the interface is closed, the system can wait for a certain period of time (e.g., 500ms) to ensure that the hardware state is completely stable and to avoid subsequent configuration operations failing due to hardware state synchronization issues. The double-shutdown method rollback design disclosed herein provides compatibility support for different versions of the operating system platform, ensuring that the service can correctly perform the interface shutdown operation on different versions of the same operating system.

[0095] After the interface is shut down, parameter configuration can be performed in operation 440. This involves configuring the controller LAN interface according to the target configuration information, such as setting various communication parameters, including bit rate, sampling point, and automatic restart timeout. In some implementations, parameter configuration can be accomplished by executing commands with a timeout via the command executor interface. The timeout can be set to, for example, 5 seconds to avoid initialization process stalling due to command blocking. As an example, in a Linux system, the executed parameter configuration command could be `ip link set can0 type can bitrate 1000000sample-point 0.875 restart-ms 100`. This command sets the bit rate of interface can0 to 1 Mbps (1,000,000 bps), the sampling point to 0.875, and the automatic restart timeout to 100 ms (i.e., automatically restarting after 100 ms if an interface error occurs). In a Windows system, the same parameters can be set by calling the configuration function of the PCAN driver or by using command-line tools.

[0096] After completing the parameter settings, you can perform the startup operation on the controller LAN interface in operation 445, switching the interface from the disabled state to the enabled state. The startup operation is also implemented by calling native operating system commands or driver interfaces through the command executor interface. For example, in a Linux system, executing the command `ip link set can0 up`, or in a Windows system, calling the startup interface function of the PCAN driver.

[0097] After the interface is started, configuration verification can be performed on the started CAN interface via operation 450. This verifies whether the configuration information of the (initialized) Controller Area Network (CAN) interface is consistent with the target configuration information, ensuring that the parameter configuration and interface status meet expectations. In some implementations, the configuration verification operation may include: querying the actual operating status of the started CAN interface through the command executor interface to verify whether the bit rate is consistent with the target configuration and whether the interface is in a normal startup state. For example, querying whether the actual bit rate of interface can0 is 1 Mbps, whether the sampling point is 0.875, whether the interface status is "UP", and whether there are no error frames, bus shutdown, or other abnormal indicators; if all verification items meet the requirements, the configuration verification can be determined to be successful; if any verification item fails to meet the requirements, such as incorrect bit rate configuration, interface not started, or an error state, the configuration verification can be determined to be unsuccessful.

[0098] In operation 455, the result of this interface initialization attempt can be judged: if the initialization is determined to be successful, i.e., the configuration verification is successful, then operation 460 can be entered, returning the result of successful interface initialization and ending the interface initialization process; otherwise, if the configuration information of the initialized controller LAN interface is different from the target configuration information, an initialization anomaly is determined, i.e., the initialization attempt is judged to have failed, and initialization needs to be retried. In some implementations, to avoid an endless loop due to initialization failure caused by temporary faults, an initialization strategy with fixed-interval retries can be enabled: by setting a maximum number of retries (e.g., 3 times) and a retry interval (e.g., 2 seconds), when the initialization attempt fails, the initialization process is re-executed at retry intervals before reaching the maximum number of retries; if the maximum number of retries is reached and the attempt still fails, the initialization is terminated.

[0099] After enabling the initialization strategy with fixed-interval retries, when operation 455 determines that initialization failed, operation 465 can be initiated to determine whether the number of initialization retries is less than a predetermined threshold, which can be the maximum number of retries. If the number of initialization attempts has reached the maximum number of retries (e.g., 3 times), meaning the number of retries is not less than the predetermined threshold, then in operation 470, retrying initialization is stopped, the controller LAN interface initialization is determined to have failed, the result of the interface initialization failure is returned, and a detailed failure log is recorded (including the reason for each failure, timestamp, etc.), ending the initialization process of the interface. If the number of initialization attempts is less than the maximum number of retries, meaning the number of retries is less than the predetermined threshold, then operation 475 can be initiated, and after waiting for the set retry interval (e.g., 2 seconds), operation 415 is returned to re-execute the interface existence verification and subsequent initialization process to re-initialize the controller LAN interface. For example, after the first initialization attempt fails, wait 2 seconds and execute the second attempt; if the second attempt also fails, wait another 2 seconds and execute the third attempt; if the third attempt also fails, then initialization failure is returned.

[0100] In some implementations, when a robot system or dexterous hand system has multiple CAN interfaces, a graceful degradation strategy can be adopted to improve the overall availability of the system. The graceful degradation strategy may include: initializing all configured interfaces one by one according to the interface configuration list, and recording the initialization result (success or failure) of each Controller Area Network (CAN) interface. If at least one CAN interface is successfully initialized, subsequent services are executed, such as the normal startup of the bridging service disclosed herein, and warning information of partial interface initialization failure is recorded in the log. The system can continue to use the successfully initialized interfaces to provide CAN communication services. Only when all CAN interface initializations fail, subsequent services are not executed and a fatal error is reported, such as terminating the bridging service startup process. In one example, the system is configured with three interfaces: can0, can1, and can2. If can0 and can1 are successfully initialized, and can2 fails to initialize, the service starts normally, and a warning of can2 initialization failure is recorded in the log. If all three interfaces fail to initialize, the service fails to start and a fatal error is reported. The graceful degradation strategy disclosed herein can maximize system availability and avoid the entire service becoming unavailable due to the failure of a single or partial interface.

[0101] After completing interface startup via procedure 400, the CAN socket binding and message transmission channel establishment process can be executed. This creates a dedicated communication socket for each started CAN interface and establishes a stable message transmission channel. This process can be performed by... Figure 1 The control device 120 executes this. In some implementations, the process of CAN socket binding and message transmission channel establishment can be implemented through the aforementioned socket provider interface. Specific steps may include:

[0102] 1. Call the creation method of the socket provider interface to create a raw socket of type AF_CAN, where AF_CAN is a dedicated address family for CAN bus communication, and obtain the file descriptor corresponding to the socket;

[0103] 2. By using the input / output control (ioctl) system call, pass in the interface name and file descriptor to obtain the index number of the CAN interface in the operating system kernel;

[0104] 3. Call the binding method of the socket provider interface to associate the created socket with the kernel index number of the target CAN interface, complete the binding of the socket and the interface, and ensure that subsequent messages can be transmitted through this interface;

[0105] 4. Construct the interface data structure, which can include the interface name, socket file descriptor, socket address information (such as address family, interface index number) and performance metric recorder (used to record metrics such as sending delay and number of successes), and register this data structure in the global interface mapping table of the interface manager to facilitate subsequent interface management and operation calls.

[0106] Once the message sending channel is established, the CAN message sending operation can be performed. This operation can be carried out by... Figure 2 The message sender 225 executes the message sending process, which can be as follows:

[0107] 1. First, query the global interface mapping table of the interface manager to verify whether the target interface has been configured and successfully initialized (i.e., the interface data structure has been registered and the socket status is normal); if the target interface is not registered or the status is abnormal, return a sending failure and record the error information.

[0108] 2. If the target interface is in normal condition, construct the CAN frame data structure. In some implementations, the CAN frame can contain a 4-byte identifier ID, a data length code (DLC), a 3-byte padding field, and an 8-byte data payload, with a total CAN frame size of 16 bytes. Regarding the identifier ID, the standard CAN frame identifier can use the lower 11 bits, while the extended CAN frame identifier can use the lower 29 bits, with the 31st bit set to 1 as an extended frame flag. The identifier ID can be of data type uint32; the data length code can be of data type uint8, with a value range of 0-8, used to identify the length of the data payload; the padding field can be used for memory alignment to improve transmission efficiency; the data payload can store the actual service data to be transmitted; and the extended frame flag can be used to distinguish between standard frames and extended frames.

[0109] 3. Serialize the constructed CAN frame structure into a 16-byte binary buffer, and store the ID, DLC, padding field, and data payload in byte order. Then, call the send method of the socket provider interface to send the binary buffer to the CAN bus through the bound socket.

[0110] 4. After the transmission operation is completed, performance metrics are recorded in real time. In some implementations, if the transmission is successful, the transmission delay can be stored in a sliding window, and the average delay and transmission success count can be updated; if the transmission fails, the error information and the timestamp of the error occurrence are recorded to provide a basis for subsequent health monitoring and troubleshooting. In some implementations, the error information may be socket error, bus busy, transmission timeout, etc.

[0111] While executing the CAN socket binding and message transmission channel establishment process described above, the system can also execute the real-time message listening and fixed-capacity ring buffer management process in parallel. This allows for the initiation of an independent message listening thread for each bound CAN interface, receiving message data from the CAN bus in real time and storing the received CAN messages in the fixed-capacity ring buffer. The message listening and real-time message listening and fixed-capacity ring buffer management processes can be handled by… Figure 1 Control device 120 or Figure 2 The message listener 230 component executes. In some implementations, the real-time message listening and sized ring buffer management process may include:

[0112] 1. Listening Thread Startup. In some implementations, a separate listening socket is created for each successfully initialized CAN interface. The binding method of the socket provider interface is called to bind the listening socket to the corresponding interface, and then a dedicated background thread is started to handle message listening. In some implementations, the listening socket can be separated from the sending socket to avoid send / receive conflicts. In some implementations, if the current operating system platform is determined to be Linux, the dedicated background thread can use a blocking read method to reduce resource consumption; if the current operating system platform is determined to be Windows, the dedicated background thread can use a non-blocking asynchronous receive method to avoid response delays caused by thread blocking.

[0113] 2. Message Reception and Parsing. In some implementations, to prevent the listening thread from being permanently blocked due to lack of message reception, a socket receive timeout can be set, for example, to 1 second. If no message is received after the timeout, the thread will be briefly awakened and re-enter the waiting state. After receiving a message, the 16 bytes of binary data read can be parsed into a standardized CAN frame structure. In some implementations, to improve reception efficiency and avoid event loop jitter caused by receiving messages one by one, an adaptive batch reception strategy can be adopted. For example, the upper limit for a single batch reception can be set to 256 messages, and the hardware buffer of the CAN interface can be emptied in batches during an event loop wake-up. In some implementations, the thread's sleep duration can be dynamically adjusted according to the instantaneous message arrival rate. For example, when continuous message arrivals are detected, it is determined to be a high-load scenario, and a short sleep duration is used to reduce thread switching overhead and improve reception efficiency; when no messages are detected, it is determined to be an idle scenario, and a long sleep duration is used to reduce CPU resource consumption. In some implementations, the short sleep duration can be 500 microseconds, and the long sleep duration can be 2 milliseconds.

[0114] 3. Fixed-capacity circular buffer (also known as independent message buffer) management. In some implementations, a corresponding independent message buffer can be configured for each CAN interface to ensure that message data from different interfaces do not interfere with each other. Figure 5 A schematic diagram of the structure of a fixed-volume annular buffer according to an exemplary embodiment of the present disclosure is shown, as follows: Figure 5 As shown, the buffer data structure can include: a pre-allocated message array msg1…msgn, a fixed maximum capacity, a cumulative receive counter, a read lock, and a write lock. Here, n is the fixed maximum capacity of the buffer, such as 100 messages. The cumulative receive counter can be used to count the total number of messages received by the interface. The read-write lock can be used to ensure the safety of concurrent access by multiple threads. The storage logic of the buffer can follow the characteristics of a circular queue, that is, the leftmost message is the oldest message at the head of the queue, and the rightmost message is the newest message at the tail of the queue. When a new message enters, a write lock is first acquired to prevent data corruption caused by multiple threads writing simultaneously. Then, the cumulative receive counter is incremented by 1, and the new message is written to the tail of the queue. If the total number of messages in the queue reaches the maximum capacity, the oldest message at the head of the queue is automatically evicted, and other messages are shifted one position to the left to make room for the new message. After the new message is written, the write lock can be released, allowing other threads to write new messages. In some implementations, the cumulative receive counter is not reset due to the elimination of old data, and it continuously accumulates the total number of received packets from the interface's startup to the present. This counter can be used to calculate statistical indicators such as packet arrival rate. In some implementations, the packet arrival rate can be the number of received packets per unit time. The fixed-capacity ring buffer management scheme disclosed herein can ensure constant memory usage and avoid memory overflow even when the high-speed CAN bus is fully loaded; at the same time, in conjunction with a read-write lock mechanism, it achieves thread-safe concurrent access. In some implementations, multi-threaded concurrency can include concurrent access by the listening thread writing packets and the upper-layer application thread reading packets.

[0115] 4. Message Log Recording and Rate Limiting. In some implementations, to avoid log overload in high-frequency message scenarios, which would consume excessive storage resources and affect system performance, the system can adopt a count-based log rate limiting strategy. For example, logs are recorded only for the first 10 received messages, and then once every 100 received messages. For messages in between, no detailed logs are recorded; only the cumulative receive counter and performance metrics are updated.

[0116] Figure 6This diagram illustrates a two-layer health monitoring and automatic recovery process 600 according to an exemplary embodiment of this disclosure. Process 600 can run continuously after interface initialization is complete, continuously monitoring the CAN interface operating status of the robot system or dexterous hand system, and automatically performing recovery operations when system errors occur. The two-layer health monitoring and automatic recovery process 600 can be... Figure 1 control equipment or Figure 2 The watchdog 235 component is executed. In some implementations, the two-layer health monitoring strategy can be a "passive indicator tracking + selective active detection" two-layer health monitoring strategy to ensure the comprehensiveness of monitoring and avoid unnecessary resource consumption.

[0117] See Figure 6 The execution of process 600 begins with operation 610. After the interface initialization is completed and the system enters normal operating state, watchdog 235 can be started.

[0118] In operation 615, all registered CAN interfaces in the system can be traversed first to monitor and collect the operating metrics of the Controller Area Network (CAN) interfaces. In some implementations, all registered CAN interfaces in the system may include interfaces in the global interface mapping table of the interface manager. In some implementations, the system can automatically and continuously record the relevant operating metrics of the interface sending messages during message transmission, thus the monitoring and data collection operations do not generate CAN bus overhead. As mentioned earlier, message transmission can be achieved by creating a transmit socket for each CAN interface, and messages can be sent to the CAN interface based on the transmit socket.

[0119] In some implementations, monitoring and collecting operational metrics of a controller LAN interface may include: creating a monitoring socket for each controller LAN interface; monitoring and collecting operational metrics of the controller LAN interface based on the monitoring socket; and storing the collected operational metrics in a buffer, such as the aforementioned fixed-capacity ring buffer. As mentioned earlier, the buffer may have a preset maximum capacity. When adding operational metrics to the buffer, if the operational metrics stored in the buffer reach the maximum capacity, the oldest operational metric in the buffer is deleted.

[0120] In some implementations, the relevant performance metrics may include:

[0121] The cumulative send count is used to record the total number of messages sent by this interface from startup to the present. This counter can be incremented by 1 after each successful call to the send method of the socket provider interface.

[0122] The cumulative error count records the total number of sending errors from the start of the interface to the present. This counter can be incremented by 1 each time the send method of the socket provider interface returns an error.

[0123] Last sent time: Records the timestamp of the last successfully sent message by this interface. This metric can be updated with the current timestamp after each successful send.

[0124] Recent Error Time: Records the timestamp of the last time this interface sent an error. This metric can be updated with the current timestamp after each error is sent.

[0125] Recent Error Information: Records detailed information about the most recent error sent by this interface. This metric can be updated after each error is sent. In some implementations, the detailed information about the sent error may include socket error codes, bus shutdown, timeout errors, etc.

[0126] Sending delay records, such as the sending delay records of the most recent 100 messages: Store the sending delay data of the most recent 100 successfully sent messages in a sliding window. If the window is full of 100 messages, the oldest delay data will be discarded when new delay data is added.

[0127] Average delay: Average delay = the sum of all delays within the sliding window divided by the number of messages within the window. For example, if the sliding window stores the sending delays of the most recent 100 messages, the average delay = the sending delays of the 100 messages divided by 100.

[0128] In some implementations, in addition to the basic operating indicators mentioned above, the system can also calculate derived indicators based on these indicators, such as the success rate of transmission. The calculation formula can be: Success rate = (cumulative number of transmissions - cumulative number of errors) / cumulative number of transmissions.

[0129] In some implementations, the collection process of the above-mentioned operating indicators can be embedded in the normal message sending process without the need for additional probe messages or monitoring threads. This ensures that no additional bus communication overhead or resource consumption will be generated during stable system operation, thus guaranteeing the operating efficiency of the system.

[0130] Next, in operation 620, the previously passively collected operational metrics are assessed to determine the health of the current interface and whether proactive health monitoring is required. In some implementations, the operational metrics of all registered interfaces can be assessed according to a fixed cycle. In some implementations, the fixed cycle can be 10 seconds, and the cycle can be configured according to business needs. For example, it can be shortened to 5 seconds for scenarios with high real-time requirements and extended to 20 seconds for scenarios sensitive to resource consumption. Within each assessment cycle, for each registered CAN interface, a preset assessment condition is used to determine whether proactive health detection is required: if the assessment result is that it is not required, operation 625 is entered, ending the current health monitoring process for that interface and waiting for the next cycle; if the assessment result is that it is required, operation 630 is entered, initiating the proactive health detection process.

[0131] In some implementations, the preset conditions for determining whether proactive health detection needs to be performed may include the following three items. If any one of the conditions is met, it can be determined that proactive health monitoring does not need to be performed; otherwise, it needs to be performed:

[0132] Condition 1: No errors have ever occurred. Specifically, this can be achieved by checking if the most recent error time is null or zero, meaning that the interface has not experienced any transmission errors since its startup. If so, the interface is considered stable and no active probing is required.

[0133] Condition 2: The most recent successful transmission time is after the most recent error time. When an interface has experienced an error but subsequent successful transmissions are recorded, it indicates that the system has automatically recovered its normal communication capabilities, and active probing is unnecessary.

[0134] Condition 3: The error is more than a certain threshold window away. For example, if the threshold window is set to 30 seconds, and the most recent error is 30 seconds or more away from the current time, it indicates that the error occurred in the distant past and has not recurred. The interface is currently stable and there is no need to perform active probing.

[0135] The selective triggering mechanism of the above three conditions ensures that the system only initiates the active detection process when the passive indicator indicates that the interface may be abnormal. Specifically, when the system determines that the controller LAN interface is unstable based on the operating indicators, that the error has not been recovered by itself, and the difference between the current time and the time when the error occurred is less than a preset threshold, the system avoids generating additional CAN bus communication overhead in stable operating scenarios.

[0136] Next, the proactive health detection process begins. First, in operation 630, a probe frame, such as a minimum probe frame, is constructed for the interface determined to require inspection, and this probe frame is sent to the unstable Controller Area Network (CLAN) interface. In some implementations, the minimum probe frame may have the following structure: Identifier ID = 0x00 (indicating a standard frame format), Data Payload = [0x00] (containing only 1 byte of data), Data Length Code (DLC) = 1 byte, for a total size of 16 bytes. After construction, the minimum probe frame can be attempted to be sent through the socket already bound to the interface.

[0137] In operation 635, it can be determined whether there is an anomaly in the transmission of the minimum probe frame. If an anomaly is determined in the transmission of the probe frame, the Controller Area Network (CAN) interface is identified as faulty, and only then is the subsequent fault recovery operation performed on the CAN interface executed. In some embodiments, to avoid resource waste caused by frequent interface failures, the system can use a limited-number automatic recovery strategy in conjunction with an active probing mechanism. In some embodiments, the limited-number automatic recovery strategy can be as follows: set an independent recovery counter for each CAN interface, with an initial value of 0; when the CAN interface successfully recovers from an error, the recovery counter is reset to zero; when recovery fails, the recovery counter is incremented; when the recovery counter reaches a preset maximum number of times (e.g., 3 times), the recovery attempt for that interface is abandoned to avoid infinite retries caused by permanent hardware failures.

[0138] When using a limited-number automatic recovery strategy, the determination of whether an anomaly exists in operation 635 can be as follows: If the minimum probe frame is successfully sent through the bound socket, it indicates that the interface hardware connectivity and communication capability are normal, and no anomaly is determined. Operation 640 is then initiated, ending the current health monitoring process and resetting the interface's recovery counter to zero, awaiting the next cycle. If sending the minimum probe frame fails, it indicates an interface anomaly, requiring the execution of the automatic recovery process. In this case, operation 645 can be initiated. In some implementations, failure to send the minimum probe frame may include returning a transmission error or timeout without response, and interface anomalies may include hardware failure, driver anomalies, bus interruptions, etc.

[0139] In operation 645, when the active detection determines that an interface is unhealthy, it can be further determined that the number of times fault recovery has been performed on the faulty Controller Area Network interface is less than a preset threshold, i.e., whether the recovery counter count of the interface is less than the maximum number of recovery attempts. If so, operation 655 is initiated to execute the automatic recovery process; if the recovery counter has reached or exceeded the maximum number of recovery attempts, operation 650 is initiated to end the current health monitoring process, record detailed alarm information, and notify maintenance personnel for manual troubleshooting. In some implementations, the alarm information may include the interface name, the type of anomaly, and the number of recovery attempts. In some implementations, the watchdog 235 component can check whether the system has enabled the automatic recovery function. If it is not enabled, the alarm is recorded directly and the process ends; if it is enabled, the current recovery counter value of the interface is obtained. If the value has reached the maximum number of recovery attempts, operation 650 is initiated to abandon the recovery and record the alarm; if it has not reached the maximum number of recovery attempts, operation 655 is initiated.

[0140] In operation 655, an automatic recovery procedure can be executed, and the recovery counter value of the interface can be incremented by 1. In some implementations, the automatic recovery procedure may include:

[0141] First, remove the old interface, that is, perform an interface removal operation on the faulty controller LAN interface. In some implementations, the socket corresponding to the faulty controller LAN interface can be closed, for example, by closing all sockets bound to the interface, releasing the occupied file descriptors and system resources, and clearing the interface data structure in the interface manager's global mapping table;

[0142] Then, re-initialization is performed, that is, performing interface initialization operations on the faulty Controller Area Network (CLAN) interface. In some implementations, the interface initialization process can be re-executed, for example, by creating a new socket for the faulty CLAN interface and binding the new socket to the faulty CLAN interface, thereby rebuilding the communication channel.

[0143] After the automatic recovery is completed in operation 655, the process returns to operation 630 to rebuild the minimum probe frame and attempt to send it to verify whether the interface has recovered successfully. If the sending is successful, operation 640 is entered to clear the recovery counter and end the process. If it still fails, the logic of operations 645 to 655 is repeated until the recovery counter reaches the maximum number of times or the recovery is successful.

[0144] The disclosed dual-layer health monitoring and automatic recovery process 600 achieves high efficiency and comprehensiveness in health monitoring through a dual-layer strategy of "passive indicator tracking + selective active detection": the passive layer collects operational indicators with zero overhead during normal message transmission and reception, ensuring real-time monitoring and low resource consumption; the selective triggering judgment mechanism only initiates active detection when the interface may be abnormal, avoiding additional overhead in stable scenarios; the active detection process, combined with a limited-number automatic recovery strategy, can effectively recover from intermittent faults and prevent infinite retries caused by permanent hardware failures. At the same time, through an independent recovery counter, it avoids frequent failures of one interface consuming the recovery quota of other interfaces, allowing subsequent new faults to regain a full recovery opportunity and preventing infinite retries caused by permanent hardware failures.

[0145] When the bridging service of this disclosure receives a termination signal and needs to be shut down, a graceful shutdown and resource cleanup can be performed. In some implementations, the components can be shut down in the following order: stop the message listener, stop the watchdog, shut down the HTTP server, shut down all transmit sockets, and disconnect the CAN interface.

[0146] In some implementations, the socket provider interface can be used to perform the shutdown of partial components. For example, a message listener can be stopped by calling the shutdown method of the socket provider interface; all sending sockets can be released and closed by traversing the interface manager registry and calling the shutdown method of the socket provider interface for each interface.

[0147] In some implementations, the CAN interface can be disassembled by calling the command executor interface method.

[0148] The method and device disclosed herein have been practically deployed and applied in dual-arm robot products. The test results are shown in Table 1 below. The test results show that the solution disclosed herein has the advantages of high real-time performance, good stability, extremely low and constant resource consumption, effective fault recovery mechanism, and strong cross-platform compatibility.

[0149] Table 1

[0150] CAN message transmission delay Single interface, bit rate 1 Mbps Average latency <1ms Message listening throughput Single interface, continuous high-speed reception >1000 msg / s Fault detection time Manually disconnect the USB-CAN device Detection within one inspection cycle (10~20 seconds) Automatic recovery time Reconnect after disconnection From detection to recovery completion <30 seconds Single interface memory usage Buffer capacity 100 entries Constant approximately 100KB Cross-platform API consistency The same request was sent to both the Linux and Windows clients. The response formats are completely consistent.

[0151] Figure 7 A flowchart illustrating an exemplary method 700 according to an exemplary embodiment of the present disclosure is shown. Exemplary method 700 can be performed by a device or at least a portion of a robot system or dexterous hand system, for example by... Figure 1 The control device 120 is executed. See also Figure 7The exemplary method 700 may include: operation 710, instantiating a controller local area network (Controller Area Network) service interface; operation 720, determining the currently running operating system platform; operation 730, establishing a mapping relationship between the Controller Area Network service interface method and the native interface of the currently running operating system platform; operation 740, calling the native interface of the currently running operating system platform through the Controller Area Network service interface to initialize the Controller Area Network service runtime environment; operation 750, receiving a general service request to start the Controller Area Network service, wherein the general service request is applicable to any operating system platform; operation 760, calling the Controller Area Network service interface method based on the requested Controller Area Network service; and operation 770, calling the native interface corresponding to the currently running operating system platform based on the called Controller Area Network service interface method and the mapping relationship to start the Controller Area Network service.

[0152] In some implementations, the general service request may include a service request based on the Hypertext Transfer Protocol or a service request based on the Remote Procedure Call Protocol.

[0153] In some implementations, the controller local area network (LAN) services may include at least one of the following: message sending and receiving services; status monitoring services; interface management services; or message listening services.

[0154] In some implementations, the controller LAN service interface may include a socket provider interface or a command executor interface.

[0155] In some implementations, the method provided by the socket provider interface may include at least one of the following: creating a controller area network (MAN) socket; obtaining an index of the MAN interface; enumerating devices connected to the MAN interface; associating the created MAN socket with the MAN interface; sending MAN frames; receiving information sent from the MAN interface or closing the MAN socket.

[0156] In some implementations, the methods provided by the command executor interface may include normal execution or execution with a timeout.

[0157] In some implementations, the operating system platform may include a Windows platform; the native interface may include a controller area network driver interface provided by the vendor.

[0158] In some implementations, the operating system platform may include a Linux platform; the native interface may include a socket interface or a system command interface.

[0159] Figure 8A flowchart illustrating an exemplary method 800 according to an exemplary embodiment of the present disclosure is shown. Exemplary method 800 may be performed by a device or at least a portion of a robot system or dexterous hand system, for example by… Figure 1 The control device 120 is executed. See also Figure 8 The exemplary method 800 may include: operation 810, querying the current status and current configuration information of the controller LAN interface to be initialized; operation 820, when the current status is in the startup state and the current configuration information is the same as the target configuration information, determining that the controller LAN interface initialization is complete and terminating the initialization method; operation 830, when the current status is in the startup state and the current configuration information is different from the target configuration information, initializing the controller LAN interface based on the target configuration information; operation 840, determining whether the configuration information of the initialized controller LAN interface is the same as the target configuration information; operation 850, when the configuration information of the initialized controller LAN interface is different from the target configuration information, determining that the initialization is abnormal and judging whether the number of initialization retries is less than a predetermined threshold; operation 860, when the number of retries is less than the predetermined threshold, re-initializing the controller LAN interface; operation 870, when the number of retries is not less than the predetermined threshold, determining that the controller LAN interface initialization has failed.

[0160] In some implementations, method 800 may further include: configuring the controller local area network interface based on environment variables before the query operation; configuring the controller local area network interface based on command line parameters if the environment variables are not set; calling the platform's automatic detection function to configure the controller local area network interface if the command line parameters are not set; and configuring the controller local area network interface based on default values ​​if the automatic detection function does not find the controller local area network interface.

[0161] In some implementations, method 800 may further include: verifying the existence of a controller local area network interface before the query operation.

[0162] In some implementations, initializing the controller local area network (Controller Area Network) interface based on the target configuration information may include: disabling the Controller Area Network interface; configuring the Controller Area Network interface according to the target configuration information; starting the Controller Area Network interface; and verifying whether the configuration information of the Controller Area Network interface is consistent with the target configuration information.

[0163] In some implementations, method 800 may further include: recording the initialization result of each controller LAN interface; executing subsequent services when at least one controller LAN interface is successfully initialized; and not executing subsequent services and reporting a fatal error when all controller LAN interfaces fail to initialize.

[0164] In some implementations, the configuration information may include at least one of the following: baud rate information of the controller LAN interface; sampling point information of the controller LAN interface; or automatic restart timeout information of the controller LAN interface.

[0165] Figure 9 A flowchart illustrating an exemplary method 900 according to an exemplary embodiment of the present disclosure is shown. The exemplary method 900 can be performed by a device or at least a portion of a robot system or dexterous hand system, such as by... Figure 1 The control device 120 is executed. See also Figure 9 The exemplary method 900 may include: operation 910, monitoring and collecting operating indicators of the controller LAN interface, wherein the monitoring and collection operation does not generate controller LAN bus overhead; operation 920, when it is determined based on the operating indicators that the controller LAN interface has a message transmission error, the error has not recovered on its own, and the difference between the current time and the time of the error occurrence is less than a preset threshold, determining that the controller LAN interface is operating unstable; operation 930, constructing a probe frame and sending the probe frame to the unstable controller LAN interface; operation 940, when it is determined that the transmission of the probe frame is abnormal, determining that the controller LAN interface is faulty, and performing fault recovery on the controller LAN interface.

[0166] In some implementations, the performance metrics may include at least one of the following: cumulative number of transmissions; cumulative number of errors; most recent transmission time; most recent error time; most recent error message; average delay; or transmission delay records.

[0167] In some implementations, performing fault recovery on the controller LAN interface may include: determining that the number of times fault recovery is performed on the faulty controller LAN interface is less than a preset threshold; performing an interface removal operation on the faulty controller LAN interface; and performing an interface initialization operation on the faulty controller LAN interface.

[0168] In some implementations, the interface removal operation may include closing the socket corresponding to the faulty Controller Area Network (CLAN) interface; the interface initialization operation may include creating a new socket for the faulty CLAN interface and binding the new socket to the faulty CLAN interface.

[0169] In some implementations, monitoring and collecting the operating metrics of the controller LAN interface may include: creating a monitoring socket for each controller LAN interface; monitoring and collecting the operating metrics of the controller LAN interface based on the monitoring socket; and storing the collected operating metrics in a buffer.

[0170] In some implementations, the buffer may have a preset maximum capacity. When adding running metrics to the buffer, if the running metrics stored in the buffer reach the maximum capacity, the oldest running metrics in the buffer can be deleted.

[0171] In some implementations, the buffer may include read locks and write locks.

[0172] In some implementations, method 900 may further include: creating a transmit socket for each controller local area network (Controller Area Network) interface before monitoring and collecting operational metrics of the Controller Area Network (Controller Area Network) interface; and sending a message to the Controller Area Network (Controller Area Network) interface based on the transmit socket.

[0173] Figure 10 This diagram illustrates a block diagram of an example device 1000 according to an exemplary embodiment of the present disclosure. Device 1000 may be implemented as a functional module or device in a robotic system or dexterous hand system, for example... Figure 1 At least a portion of the control device 120 is used to perform the exemplary embodiments discussed above. (See reference...) Figure 10 The device 1000 includes, for example, at least one processor 1010 and at least one memory 1020 storing an operating system 1022, instructions 1024, and data 1026. When the instructions 1024 are executed by the at least one processor 1010, the device 1000 causes at least the above-mentioned reference to be executed. Figure 7 , Figure 8 or Figure 9 The method described. In one example, the at least one memory 1020 and instructions 1024 (e.g., computer program code, software) are configured to cause the device 1000 to perform any of the methods described above, via the at least one processor 1010.

[0174] Operating system 1022 is system software stored in memory 1020. As an intermediate layer between hardware and instructions, it provides a unified abstract interface to provide a runtime environment for the execution of instructions 1024 and manages the computing resources of processor 1010, the space allocation of memory 1020, and the scheduling of user interface 1030 and communication interface 1040. Operating system 1022 can be a series of operating systems such as Windows, Mac OS, Unix, and Linux.

[0175] The data 1026 is stored in the memory 1020. It is a collection of various information that the processor 1010 reads, writes, transmits and processes according to the instructions 1024 under the scheduling and control of the operating system 1022, providing data support for the operation and function realization of the various components of the device 1000.

[0176] Processor 1010 may include, or be configured as, one or more circuits configured to perform stages of the method according to the disclosed exemplary embodiments. In this disclosure, the term "circuit" may refer to one or more of the following: (a) a hardware-only circuit implementation, such as an implementation solely in analog and / or digital circuitry; (b) a combination of hardware circuitry and software, if applicable, such as: (i) a combination of analog and / or digital hardware circuitry with software / firmware, and (ii) any portion of a hardware processor with software (including digital signal processors, software, and memory, which work together to enable a device such as a user equipment to perform various functions); (c) hardware circuitry and / or a processor, such as a microprocessor or a portion thereof, which requires software (e.g., firmware) for operation, but may be absent when not required for operation. This definition of circuitry applies to all uses of the term in this disclosure (including any claims). As a further example, when used in this disclosure, the term circuitry also encompasses: an implementation solely of hardware circuitry or a processor (or multiple processors), a portion of hardware circuitry or a processor, and an implementation of its accompanying software and / or firmware. If applicable to the specific features of the claims, the term "circuit" also covers, for example, baseband integrated circuits or processor integrated circuits for mobile devices, or similar integrated circuits in servers, cellular network devices, or other computing or network devices.

[0177] The memory 1020 can be implemented using any suitable data storage technology. The memory 1020 may include a database for storing data. The memory 1020 may be at least partially external to the device 1000, but may be accessible to the device 1000.

[0178] The operating system 1022, instructions 1024, and data 1026 may be contained in a computer-readable medium or a non-transitory computer-readable medium. The term non-transitory, as used herein, is defined in contrast to the limitation of data storage persistence (e.g., RAM versus ROM), and is a limitation concerning the medium itself (i.e., tangible rather than signaling).

[0179] Device 1000 may include one or more entities of any protocol layer. In some embodiments, one or more of these entities may be configured to perform method 700, method 800, method 900, or any one or more embodiments described with respect to these methods.

[0180] The device 1000 may also include a communication interface 1040, such as a wireless communication interface and / or a wired communication interface, which can provide communication capabilities for the device 1000.

[0181] The communication interface 1040 may include receiving circuitry, receivers, I / O interfaces, and other devices with network data receiving and transmitting functions. For example, the receiver may be configured to receive information according to at least one wired or wireless standard. The communication interface 1040 may include a transmitter configured to transmit information according to at least one wired or wireless standard. The receiver may include more than one receiver. The transmitter may include more than one transmitter. The communication interface 1040 may include a transceiver configured to receive and transmit information according to at least one wired or wireless standard. The transceiver may include more than one receiver.

[0182] Device 1000 may include a user interface 1030, which includes at least one of, for example, a keyboard, microphone, touchscreen, display, speaker, etc. User interface 1030 can be used by a user to control device 1000. User interface 1030 may be external to device 1000. For example, device 1000 may be connected to another device, such as a computer, via a wireless or wired connection, and device 1000 may be controlled by a user via the computer.

[0183] In some embodiments, at least some of the methods described herein can be performed by a device including means for performing various operations or steps in the described methods. The means for performing the method steps described herein may include software and / or hardware components of device 1000. For example, at least one processor 1010, memory 1020, and computer program code may form means for performing the methods described herein and any embodiments thereof. The term “means” as used herein may be interpreted in the singular form, meaning a single element, or in the plural form, meaning a combination of single elements. Therefore, the term “means for performing A, B, C” should be interpreted to encompass devices in which only one means performs A, B, C; or in which separate means perform A, B, C; or in which partially or entirely overlapping means perform A, B, C. Furthermore, the terms “apparatus for performing A, apparatus for performing B, apparatus for performing C” should be interpreted to cover devices in which only one apparatus performs A, B, or C; or in which separate apparatuses perform A, B, or C; or in which some or all overlapping apparatuses perform A, B, or C.

[0184] Figure 11 An example block diagram of an example device 1100 according to an exemplary embodiment of the present disclosure is shown. The example device 1100 may be, for example, at least a portion of the control device 120 described above.

[0185] like Figure 11As shown, the example device 1100 may include: device 1110 for instantiating a Controller Area Network (CAN) service interface; device 1120 for determining the currently running operating system platform; device 1130 for establishing a mapping relationship between the CAN service interface method and the native interface of the currently running operating system platform; device 1140 for calling the native interface of the currently running operating system platform through the CAN service interface to initialize the CAN service runtime environment; device 1150 for receiving a general service request to start a CAN service, the general service request being applicable to any operating system platform; device 1160 for calling the CAN service interface method based on the requested CAN service; and device 1170 for calling the native interface corresponding to the currently running operating system platform based on the called CAN service interface method and the mapping relationship to start the CAN service.

[0186] In some implementations, the general service request may include a service request based on the Hypertext Transfer Protocol or a service request based on the Remote Procedure Call Protocol.

[0187] In some implementations, the controller local area network (LAN) services may include at least one of the following: message sending and receiving services; status monitoring services; interface management services; or message listening services.

[0188] In some implementations, the controller LAN service interface may include a socket provider interface or a command executor interface.

[0189] In some implementations, the method provided by the socket provider interface may include at least one of the following: creating a controller area network (MAN) socket; obtaining an index of the MAN interface; enumerating devices connected to the MAN interface; associating the created MAN socket with the MAN interface; sending MAN frames; receiving information sent from the MAN interface or closing the MAN socket.

[0190] In some implementations, the methods provided by the command executor interface may include normal execution or execution with a timeout.

[0191] In some implementations, the operating system platform may include a Windows platform; the native interface may include a controller area network driver interface provided by the vendor.

[0192] In some implementations, the operating system platform may include a Linux platform; the native interface may include a socket interface or a system command interface.

[0193] Figure 12An example block diagram of an example device 1200 according to an exemplary embodiment of the present disclosure is shown. The example device 1200 may be, for example, at least a portion of a control device 120 as described above.

[0194] like Figure 12 As shown, the example device 1200 may include: a device 1210 for querying the current status and current configuration information of the controller LAN interface to be initialized; a device 1220 for determining that the controller LAN interface initialization is complete and terminating the initialization method when the current status is in the startup state and the current configuration information is the same as the target configuration information; a device 1230 for initializing the controller LAN interface based on the target configuration information when the current status is in the startup state and the current configuration information is different from the target configuration information; a device 1240 for determining whether the configuration information of the initialized controller LAN interface is the same as the target configuration information; a device 1250 for determining that the initialization is abnormal and judging whether the number of initialization retries is less than a predetermined threshold when the configuration information of the initialized controller LAN interface is different from the target configuration information; a device 1260 for re-initializing the controller LAN interface when the number of retries is less than the predetermined threshold; and a device 1270 for determining that the controller LAN interface initialization has failed when the number of retries is not less than the predetermined threshold.

[0195] In some embodiments, the device 1200 may further include: means for configuring the controller local area network interface based on environment variables before the query operation; means for configuring the controller local area network interface based on command line parameters if the environment variables are not set; means for calling the platform's automatic detection function to configure the controller local area network interface if the command line parameters are not set; and means for configuring the controller local area network interface based on default values ​​if the automatic detection function does not find the controller local area network interface.

[0196] In some embodiments, the device 1200 may further include means for verifying the existence of a controller local area network interface prior to the query operation.

[0197] In some implementations, initializing the controller local area network (Controller Area Network) interface based on the target configuration information may include: disabling the Controller Area Network interface; configuring the Controller Area Network interface according to the target configuration information; starting the Controller Area Network interface; and verifying whether the configuration information of the Controller Area Network interface is consistent with the target configuration information.

[0198] In some embodiments, the device 1200 may further include: means for recording the initialization result of each controller local area network interface; means for executing subsequent services when at least one controller local area network interface is successfully initialized; and means for not executing subsequent services and reporting a fatal error when all controller local area network interfaces fail to initialize.

[0199] In some implementations, the configuration information may include at least one of the following: baud rate information of the controller LAN interface; sampling point information of the controller LAN interface; or automatic restart timeout information of the controller LAN interface.

[0200] Figure 13 An example block diagram of an example device 1300 according to an exemplary embodiment of the present disclosure is shown. The example device 1300 may be, for example, at least a portion of the control device 120 described above.

[0201] like Figure 13 As shown, the example device 1300 may include: a device 1310 for monitoring and collecting operational metrics of a controller area network (CLAN) interface, wherein the monitoring and collection operations do not generate CLAN bus overhead; a device 1320 for determining that the CLAN interface is unstable when, based on the operational metrics, it is determined that the CLAN interface has a message transmission error, the error has not been self-recovered, and the difference between the current time and the error occurrence time is less than a preset threshold; a device 1330 for constructing a probe frame and sending the probe frame to the unstable CLAN interface; and a device 1340 for determining that the CLAN interface is faulty when it is determined that the transmission of the probe frame is abnormal, and performing fault recovery on the CLAN interface.

[0202] In some implementations, the performance metrics may include at least one of the following: cumulative number of transmissions; cumulative number of errors; most recent transmission time; most recent error time; most recent error message; average delay; or transmission delay records.

[0203] In some implementations, performing fault recovery on the controller LAN interface may include: determining that the number of times fault recovery is performed on the faulty controller LAN interface is less than a preset threshold; performing an interface removal operation on the faulty controller LAN interface; and performing an interface initialization operation on the faulty controller LAN interface.

[0204] In some implementations, the interface removal operation may include closing the socket corresponding to the faulty Controller Area Network (CLAN) interface; the interface initialization operation may include creating a new socket for the faulty CLAN interface and binding the new socket to the faulty CLAN interface.

[0205] In some implementations, monitoring and collecting the operating metrics of the controller LAN interface may include: creating a monitoring socket for each controller LAN interface; monitoring and collecting the operating metrics of the controller LAN interface based on the monitoring socket; and storing the collected operating metrics in a buffer.

[0206] In some implementations, the buffer may have a preset maximum capacity. When adding running metrics to the buffer, if the running metrics stored in the buffer reach the maximum capacity, the oldest running metrics in the buffer can be deleted.

[0207] In some implementations, the buffer may include read locks and write locks.

[0208] In some embodiments, the device 1300 may further include: means for creating a sending socket for each controller local area network interface before monitoring and collecting operational metrics of the controller local area network interface; and means for sending messages to the controller local area network interface based on the sending socket.

[0209] It should be understood that the apparatus according to the embodiments of this disclosure is not limited to the examples described above. The modules in the illustrated example apparatuses can be connected or coupled together in any suitable manner, and the arrows between the modules are only used to indicate the direction of data or signals of interest, but do not indicate that the direction of data or signals between modules can only be in the direction of the arrows.

[0210] Some exemplary embodiments also provide computer program code or instructions that, when executed by one or more processors, cause a device or apparatus to perform the methods described above. The computer program code for performing the methods of the example embodiments can be written in any known or future-developed programming language, such as Java, C++, C, and Assembler. The computer program code can be provided to one or more processors or controllers of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that, when executed by the processor or controller, it causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code can be executed entirely on the machine, partially on the machine as a stand-alone software package, partially on the machine and partially on a remote machine, or entirely on a remote computer or server.

[0211] Some example embodiments also provide a computer program product or computer-readable medium in which computer program code or instructions are stored, which, when executed by a processor, cause the associated means to perform the methods, steps, or functions described above. A computer-readable medium can be any tangible medium that may contain or store a program for use by or in connection with an instruction execution system, means, or apparatus. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can include, but are not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, means, or apparatuses, or any suitable combination thereof. More specific examples of machine-readable storage media will include electrical connections having one or more wires, portable computer floppy disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable optical disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0212] Furthermore, although the operations are described in a specific order, this should not be construed as requiring such operations to be performed in the specific order or sequence shown, or requiring all of the operations shown to achieve the desired result. In some cases, multitasking and parallel processing can be advantageous. Similarly, although several specific implementation details are included in the foregoing discussion, these details should not be construed as limiting the scope of this disclosure, but rather as descriptions of features specific to particular embodiments. Certain features described in the context of a single embodiment may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments.

[0213] The basic principles of this disclosure have been described above in conjunction with embodiments. However, it should be noted that the advantages, benefits, and effects mentioned in this disclosure are merely examples and not limitations, and should not be considered as essential features of each embodiment of this disclosure. Furthermore, the specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the scope of this disclosure to the necessity of employing the aforementioned specific details for implementation.

[0214] The block diagrams of devices, apparatuses, devices, and systems disclosed herein are merely illustrative examples and are not intended to require or imply that they must be connected, arranged, or configured in the manner shown in the block diagrams. As those skilled in the art will recognize, these devices, apparatuses, devices, and systems can be connected, arranged, and configured in any manner. Words such as “comprising,” “including,” “having,” etc., are open-ended terms meaning “including but not limited to,” and are used interchangeably with them. The terms “or” and “and” as used herein refer to the terms “and / or,” and are used interchangeably with them unless the context clearly indicates otherwise. The term “such as” as used herein refers to the phrase “such as but not limited to,” and is used interchangeably with it.

[0215] The above description of the disclosed aspects is provided to enable any person skilled in the art to make or use this disclosure. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects without departing from the scope of this disclosure. Therefore, this disclosure is not intended to be limited to the aspects shown herein, but rather to be carried out within the widest scope consistent with the principles and novel features disclosed herein.

[0216] The above description has been given for illustrative and descriptive purposes and is not intended to limit the embodiments of this disclosure to the forms disclosed herein. Although numerous exemplary aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, alterations, additions, and sub-combinations thereof.

[0217] Although the subject matter has been described in language specific to structural features and / or methodological actions, it should be understood that the subject matter defined in the appended claims is not limited to the specific features or actions described above. Rather, the specific features and actions described above are disclosed as examples of implementing the claims.

[0218] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0219] Those skilled in the art will understand that the features described in the various embodiments and / or claims of the present invention can be combined or combined in various ways, even if such combinations or combinations are not explicitly described in the present invention. In particular, the features described in the various embodiments and / or claims of the present invention can be combined or combined in various ways without departing from the spirit and teachings of the present invention. All such combinations and / or combinations fall within the scope of the present invention.

[0220] The embodiments of the present invention have been described above. However, these embodiments are merely illustrative and not intended to limit the scope of the invention. Although various embodiments have been described above, this does not mean that the measures in the various embodiments cannot be used advantageously in combination. The scope of the invention is defined by the appended claims and their equivalents. Various substitutions and modifications can be made by those skilled in the art without departing from the scope of the invention, and all such substitutions and modifications should fall within the scope of the invention.

Claims

1. A method for initializing a controller local area network (LAN) interface, comprising: Query the current status and configuration information of the controller LAN interface to be initialized; When the current state is the startup state and the current configuration information is the same as the target configuration information, it is determined that the controller local area network interface initialization is complete, and the initialization method is terminated; When the current state is the startup state and the current configuration information is different from the target configuration information, the controller local area network interface is initialized based on the target configuration information; Determine whether the configuration information of the initialized controller LAN interface is the same as the target configuration information; When the configuration information of the initialized controller LAN interface is different from the target configuration information, the initialization is determined to be abnormal and it is determined whether the number of initialization retries is less than a predetermined threshold. When the number of retries is less than a predetermined threshold, the controller local area network interface is reinitialized. If the number of retries is not less than a predetermined threshold, it is determined that the controller local area network interface initialization has failed.

2. The method of claim 1, further comprising: Before the query operation, Configure the controller LAN interface based on environment variables; If environment variables are not set, configure the controller LAN interface based on command-line parameters; If the command-line parameters are not set, the platform's automatic detection function will be invoked to configure the controller's LAN interface; If the automatic detection function does not find the controller LAN interface, it will configure the controller LAN interface based on the default value.

3. The method of claim 1, further comprising: Before the query operation, verify that the controller LAN interface exists.

4. The method of claim 1, wherein, The initialization of the controller LAN interface based on the target configuration information includes: Disable the controller's LAN interface; Configure the controller LAN interface according to the target configuration information; Start the controller's local area network interface; Verify that the configuration information of the controller LAN interface is consistent with the target configuration information.

5. The method of claim 1, further comprising: Record the initialization results of each controller's LAN interface; When at least one controller LAN interface is successfully initialized, subsequent business operations will be executed. If all controller LAN interface initializations fail, subsequent business logic will not be executed and a fatal error will be reported.

6. The method according to any one of claims 1 to 5, wherein, The configuration information includes at least one of the following: Baud rate information for the controller LAN interface; Sampling point information of the controller LAN interface; or Automatic restart timeout information for the controller LAN interface.

7. An electronic device, comprising: At least one processor; as well as At least one memory storing instructions, which, when executed by the at least one processor, cause the electronic device to perform at least one operation, the operation including: Query the current status and configuration information of the controller LAN interface to be initialized; When the current state is the startup state and the current configuration information is the same as the target configuration information, it is determined that the controller local area network interface initialization is complete, and the initialization method is terminated; When the current state is the startup state and the current configuration information is different from the target configuration information, the controller local area network interface is initialized based on the target configuration information; Determine whether the configuration information of the initialized controller LAN interface is the same as the target configuration information; When the configuration information of the initialized controller LAN interface is different from the target configuration information, the initialization is determined to be abnormal and it is determined whether the number of initialization retries is less than a predetermined threshold. When the number of retries is less than a predetermined threshold, the controller local area network interface is reinitialized. If the number of retries is not less than a predetermined threshold, it is determined that the controller local area network interface initialization has failed.

8. The device of claim 7, wherein the operation further comprises: Before the query operation, Configure the controller LAN interface based on environment variables; If environment variables are not set, configure the controller LAN interface based on command-line parameters; If the command-line parameters are not set, the platform's automatic detection function will be invoked to configure the controller's LAN interface; If the automatic detection function does not find the controller LAN interface, it will configure the controller LAN interface based on the default value.

9. The device of claim 7, wherein the operation further comprises: Before the query operation, verify that the controller LAN interface exists.

10. The device as claimed in claim 7, wherein, The initialization of the controller LAN interface based on the target configuration information includes: Disable the controller's LAN interface; Configure the controller LAN interface according to the target configuration information; Start the controller's local area network interface; Verify that the configuration information of the controller LAN interface is consistent with the target configuration information.

11. The device of claim 7, wherein the operation further comprises: Record the initialization results of each controller's LAN interface; When at least one controller LAN interface is successfully initialized, subsequent business operations will be executed. If all controller LAN interface initializations fail, subsequent business logic will not be executed and a fatal error will be reported.

12. The device as claimed in any one of claims 7 to 11, wherein, The configuration information includes at least one of the following: Baud rate information for the controller LAN interface; Sampling point information of the controller LAN interface; or Automatic restart timeout information for the controller LAN interface.

13. An electronic device comprising means for performing the method of any one of claims 1 to 6.

14. A computer-readable medium comprising program instructions that, when executed, implement the method of any one of claims 1 to 6.

15. A computer program product comprising instructions that, when executed by a processor, perform the method as described in any one of claims 1 to 6.

16. A robot comprising: A robotic arm and an actuator located at the end of the robotic arm; as well as A controller, electrically connected to both the robotic arm and the actuator, is used to perform the method as described in any one of claims 1 to 6.

Images