An ethercat-dss communication bridging method between a host computer and a main control board of a quadruped robot
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-04-30
- Publication Date
- 2026-08-11
AI Technical Summary
[0004]但是现有EtherCAT通信方案多采用固定编码配置,未设置灵活的参数化配置机制,无法适配不同硬件设备
[0012] The beneficial effects of the present invention are at least one of the following: by loading parameterized configuration files and parsing the corresponding communication and transmission parameters, it is possible to provide an adaptive configuration basis for the construction of communication links. Compared with the fixed encoding configuration method, it helps to improve the adaptability of the communication scheme to different hardware devices.
Smart Images

Figure CN122554262A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of robot control technology, and in particular to an EtherCAT-DDS communication bridging method for a quadruped robot host computer and main control board. Background Technology
[0002] In a quadruped robot system, the host computer is responsible for motion control reasoning, while the main control board is responsible for the underlying motor drive and sensor acquisition. The communication link between the two directly determines the system's real-time performance, reliability, and scalability.
[0003] In the current conventional architecture of quadruped robots, the host computer uses DDS (Data Distribution Service) to issue joint control commands and subscribe to joint status feedback. Some high-end models use EtherCAT as the real-time communication bus of the main control board and use open-source master station libraries such as SOEM (SimpleOpenEtherCATMaster) to realize the periodic data exchange between master and slave stations, which has high real-time performance and deterministic latency.
[0004] However, existing EtherCAT communication solutions mostly use fixed encoding configurations and lack flexible parameterization mechanisms, making them unsuitable for different hardware devices. Furthermore, the joint coordinates of the upper-layer data distribution service and the lower-layer motor encoder coordinates differ in direction and zero position; the lack of coordinated conversion can lead to control deviations.
[0005] In summary, current quadruped robot systems lack an integrated communication bridging solution that balances real-time communication, parameterized configuration, and bidirectional compensation for joint orientation zero position between the data distribution service control layer and the underlying Ethernet control automation technology main control board. Summary of the Invention
[0006] To address the technical problems existing in the prior art, this invention provides an EtherCAT-DDS communication bridging method between the host computer and the main control board of a quadruped robot.
[0007] The technical solution adopted in this invention is: an EtherCAT-DDS communication bridging method between a host computer and a main control board of a quadruped robot, comprising the following steps:
[0008] Step 1: The host computer loads the parameterized configuration file, parses the EtherCAT communication parameters and joint transmission parameters, and generates a communication configuration structure;
[0009] Step 2: Initialize the EtherCAT master station based on the communication configuration structure, complete the master-slave PDO mapping and DC distributed clock synchronization, and establish the EtherCAT real-time communication link between the host computer and the main control board.
[0010] Step 3: The host computer subscribes to the joint control commands of the motion control inference layer through DDS, and performs positive compensation for the execution direction and zero position of the joint control commands based on the joint transmission parameters to generate EtherCAT-adapted joint control data.
[0011] Step 4: Send the EtherCAT-adapted joint control data to the main control board via the EtherCAT real-time communication link, and collect the first joint status data in the motor adaptation coordinate system fed back by the main control board through the EtherCAT real-time communication link.
[0012] The beneficial effects of the present invention are at least one of the following: by loading parameterized configuration files and parsing the corresponding communication and transmission parameters, it is possible to provide an adaptive configuration basis for the construction of communication links. Compared with the fixed encoding configuration method, it helps to improve the adaptability of the communication scheme to different hardware devices.
[0013] Based on the parsed parameters, an EtherCAT real-time communication link is established, and master-slave station data mapping and clock synchronization are completed. This helps to ensure the real-time performance of data interaction between the host computer and the main control board, alleviate latency fluctuations during data transmission, and improve the stability of data transmission.
[0014] By sequentially performing forward and reverse direction and zero-position compensation conversions on joint control commands and joint status data, the differences between the upper-level motion control coordinate system and the lower-level motor coordinate system can be coordinated, reducing control deviations caused by coordinate mismatch and improving the reliability of joint control.
[0015] By establishing a bidirectional communication bridge between EtherCAT and DDS, a complete uplink and downlink data closed-loop transmission path can be constructed, ensuring the coherent interaction between motion control command issuance and status feedback, and improving the operational stability of the overall communication system of the quadruped robot. Attached Figure Description
[0016] Figure 1 This is a schematic diagram of the invention process of the present invention;
[0017] Figure 2 This is a schematic diagram of the system architecture of the present invention. Detailed Implementation
[0018] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings.
[0019] It should be noted that the methods in the following embodiments are all based on the following... Figure 2The system architecture shown is divided into three layers. The upper layer is the host computer operation and control inference layer, which includes a reinforcement learning inference module, a DDS publishing module, a first DDS subscription module, and a second DDS subscription module, and also connects to external peripheral devices. Among them, the DDS publishing module is driven by operation and control algorithms such as reinforcement learning inference, and publishes joint control commands to the bridging module. The first DDS subscription module is used to subscribe to the joint state / IMU fusion state data published by the bridging module, providing state feedback for the upper-layer operation and control algorithm. The second DDS subscription module is used to subscribe to the handle / peripheral fusion state data published by the bridging module, providing input feedback for upper-layer human-computer interaction and remote control.
[0020] The middle layer is a bridging module running in the host computer. The bridging module includes an EtherCAT-DDS bridging node, a handle driver module, a coordinate system transformation module, an EtherCAT master station manager, an EtherCATNode interface, a sending data structure, a receiving data structure, and an underlying YAML configuration file.
[0021] The lower layer is the main control board (EtherCAT slave), which is responsible for motor drive and attitude data acquisition, including EtherCAT slave driver firmware, CAN bus, and IMU sensor.
[0022] Example 1
[0023] Existing EtherCAT communication schemes mostly use fixed encoding configurations and lack flexible parameterized configuration mechanisms, making them unsuitable for different hardware devices. Furthermore, the joint coordinates of the upper-layer data distribution service and the lower-layer motor encoder coordinates have directional and zero-position differences; without coordinated conversion, this can lead to control deviations. To address this technical problem, this embodiment provides an EtherCAT-DDS communication bridging method between the host computer and the main control board of a quadruped robot, such as... Figure 1 As shown, it includes the following steps:
[0024] Step 1: The host computer loads the parameterized configuration file, parses the EtherCAT communication parameters and joint transmission parameters, and generates a communication configuration structure.
[0025] It should be noted that this step corresponds to Figure 2 The YAML configuration file for the bridging module, specifically the parameterized configuration file, is used to uniformly manage the communication and transmission-related parameters of various components within the bridging module (EtherCAT master station manager, coordinate system transformation module, etc.). The parameter content can be adjusted without modifying the code.
[0026] EtherCAT communication parameters are the fundamental parameters supporting the operation of the EtherCAT master station, including network card operating parameters, thread configuration parameters, and slave identification parameters. Joint transmission parameters are parameters that match the joint motion characteristics, including joint direction coefficients and joint zero-position offsets. The communication configuration structure is a standardized data structure that integrates the parsed parameters.
[0027] For example, the host computer loads a parameterized configuration file in YAML format, parses out EtherCAT communication parameters such as network card name and real-time thread priority, and also parses out joint transmission parameters such as direction coefficient and zero offset of each joint. The above parameters are integrated into a communication configuration structure, which can be directly called in subsequent steps.
[0028] Step 2: Initialize the EtherCAT master station based on the communication configuration structure, complete the master-slave PDO mapping and DC distributed clock synchronization, and establish the EtherCAT real-time communication link between the host computer and the main control board.
[0029] Among them, the EtherCAT master station is the EtherCAT communication management node running on the host computer. It is managed by the EtherCAT master station manager and is used to manage the data interaction between the master control board and the slave stations.
[0030] Master-slave PDO mapping maps the data fields sent and received by the master station to process data objects conforming to the EtherCAT protocol specification through the EtherCATNode interface, encapsulating them into standardized send and receive data structures to ensure data format matching.
[0031] DC distributed clock synchronization uses clock configuration commands to ensure that the control cycle clocks of the master station and all slave stations are kept consistent.
[0032] The EtherCAT real-time communication link is a master-slave data transmission channel with deterministic latency, connecting the transmit / receive data structure of the bridging module with the EtherCAT slave driver firmware of the main control board.
[0033] The communication configuration structure provides the basic configuration basis for the EtherCAT master station manager. Through master station initialization, PDO mapping and clock synchronization, it can eliminate data format mismatch and clock drift problems, build a stable real-time communication channel, and provide hardware support for command issuance and status acquisition.
[0034] In the specific implementation process, the EtherCAT master station manager of the host computer bridging module calls the communication configuration structure to complete the EtherCAT master station's operating environment configuration and slave station registration. During the master station state switching process, the master-slave PDO mapping is completed through the EtherCATNode interface, standardized transmit and receive data structures are generated, the DC distributed clock synchronization process is initiated to align the master and slave station clocks, and finally, the EtherCAT real-time communication link between the host computer and the main control board is established.
[0035] Furthermore, considering the rigidity of existing EtherCAT master station configuration methods, which cannot adapt to different network cards, CPU platforms, and slave devices, resulting in poor reusability and adaptability, in one possible implementation, the EtherCAT master station manager extracts network card information, CPU binding information, and real-time thread priority information from the communication configuration structure. Based on the network card information, network card binding is completed; based on the CPU binding information, CPU binding is completed; and based on the real-time thread priority information, thread configuration is completed, generating the master station runtime environment configuration result. Based on the runtime environment configuration result, EtherCAT slave stations are enumerated and node registration is completed, generating slave node registration results. Based on the registration results, the master station state machine is controlled to switch level by level, completing the master station initialization.
[0036] This implementation method can adapt to different hardware platforms and robot models without modifying the code, improving the flexibility and reusability of the main station initialization and ensuring the stability of the main station operation.
[0037] Furthermore, considering that during the master-slave PDO mapping process, the lack of a unified mapping rule for data transmission between the master and slave stations, coupled with abnormal byte alignment, can easily lead to data parsing errors and communication failures, one possible implementation addresses this issue. The EtherCAT master station manager acquires the trigger signal indicating the EtherCAT master station's switch from PREOP to SAFEOP state. Based on this trigger signal, the send and receive data fields are obtained via the slave node callback function and the EtherCATNode interface. The send data field is mapped to a send process data object and encapsulated into a send data structure; the receive data field is mapped to a receive process data object and encapsulated into a receive data structure. Fixed byte alignment is then performed on the mapped data structures to generate a transmission data format that matches the master control board's EtherCAT slave driver firmware.
[0038] This implementation triggers the mapping process at key nodes during master station state switching, obtains send and receive data fields through callback functions, completes process data object mapping and byte alignment, ensures data format matching, avoids data parsing errors, and improves the reliability and accuracy of the communication process.
[0039] Furthermore, considering that clock drift between master and slave stations causes large fluctuations in data transmission latency, which cannot meet the high real-time joint control requirements of quadruped robots, in one possible implementation, the EtherCAT master station manager reads synchronization enable parameters from the communication configuration structure and initiates the clock synchronization process. Based on the synchronization enable parameters, the EtherCAT master station issues synchronization clock configuration commands to all slave stations. All slave stations align their own control cycle clocks with the master station clock based on the configuration commands. The clock drift is eliminated based on the clock alignment result, generating a real-time communication link with deterministic latency.
[0040] This implementation method initiates the clock synchronization process based on the synchronization enable parameter. The master station sends a clock configuration command to the slave station to align the slave station's clock with the master station's clock, eliminating clock drift and achieving precise synchronization between the master and slave station clocks. This reduces data transmission jitter, ensures deterministic delay in periodic data interaction, and meets high real-time control requirements.
[0041] Step 3: The host computer subscribes to the joint control commands of the motion control inference layer through DDS, and performs positive compensation for the execution direction and zero position of the joint control commands based on the joint transmission parameters to generate EtherCAT-adapted joint control data.
[0042] Specifically, such as Figure 2 As shown, the EtherCAT-DDS bridging node of the bridging module in the host computer subscribes to the joint control commands published by the DDS publishing module of the host computer's motion control inference layer. The coordinate system transformation module performs positive compensation for direction and zero position, generates EtherCAT-adapted joint control data, and encapsulates it into the transmission data structure.
[0043] It should be noted that DDS is a data distribution service used to transmit joint control commands. After the reinforcement learning inference module of the host computer's motion control inference layer generates joint control commands, it publishes the corresponding topic through the DDS publishing module. The EtherCAT-DDS bridging node of the bridging module subscribes to the topic and obtains the control commands.
[0044] The joint control data adapted to EtherCAT is joint control data that conforms to the EtherCAT protocol format and can be directly sent to the main control board. It is encapsulated in the data transmission structure for real-time transmission.
[0045] Because the joint control commands in the motion control inference layer are generated based on the simulation coordinate system, there are differences in direction and zero position between them and the underlying motor encoder coordinate system. Directly issuing these commands will cause control deviations. Positive compensation can eliminate the differences between the two coordinate systems and generate control data that is compatible with EtherCAT transmission.
[0046] To address the issue of orientation and zero-position differences between the upper-level simulation coordinate system and the lower-level motor coordinate system, where simply converting a single control variable can lead to control failure or mechanical damage, the coordinate system transformation module extracts the joint orientation coefficient and joint zero-position offset from the joint transmission parameters and obtains the simulation coordinate system joint control command data subscribed to by the EtherCAT-DDS bridge node. A full positive transformation is performed for the i-th joint. The target angle is transformed according to the formula: the joint motor target angle equals the orientation coefficient multiplied by the difference between the simulation target angle and the zero-position offset, as shown below:
[0047]
[0048] in, For the first quadruped robot The target angle of the joint motor in the motor adaptation coordinate system. For the first The direction coefficients of each joint take values of +1 or -1. For the first quadruped robot The simulated target angle of each joint in the simulation coordinate system. This is the zero-position offset of the i-th joint.
[0049] The target speed is converted according to the formula: the target speed of the joint motor is equal to the direction coefficient multiplied by the simulated target speed, as follows:
[0050]
[0051] in, For the first quadruped robot The target speed of the joint motor in the motor adaptation coordinate system. For the first The directional coefficient of each joint For the first quadruped robot The simulated target velocity of each joint in the simulation coordinate system.
[0052] The feedforward torque is converted according to the formula that the feedforward torque of the joint motor is equal to the direction coefficient multiplied by the simulated feedforward torque, as follows:
[0053]
[0054] in, For the first quadruped robot The joint motor feedforward torque in the motor adaptive coordinate system. For the first The directional coefficient of each joint For the first quadruped robot Simulated feedforward torque of each joint in the simulation coordinate system.
[0055] The position stiffness gain and velocity damping gain directly use the values from the simulation coordinate system. The motor end parameters are consistent with the simulation coordinate system parameters. The position stiffness gain is calculated according to the formula. Perform the conversion; the velocity damping gain is calculated according to the formula. Perform the conversion.
[0056] in, This is the gain for the motor end position stiffness. This is the stiffness gain at the simulation end position.
[0057] This is the speed damping gain at the motor end. This represents the velocity damping gain at the simulation end.
[0058] Based on the transformation results, joint control data for the motor's adaptive coordinate system is generated and encapsulated into the data transmission structure.
[0059] This implementation method, based on joint transmission parameters, performs a full positive transformation on the target angle, target speed, feedforward torque, position stiffness gain, and velocity damping gain. It adapts to the requirements of the motor coordinate system, completely eliminates the coordinate differences between simulation and actual machine, ensures accurate transformation of all control quantities, avoids motion reversal and position deviation, and improves control safety.
[0060] Step 4: Send the EtherCAT-adapted joint control data to the main control board via the EtherCAT real-time communication link, and collect the first joint status data in the motor adaptation coordinate system fed back by the main control board through the EtherCAT real-time communication link.
[0061] It should be noted that the hardware module that carries the underlying motor drive and sensor acquisition tasks runs as an EtherCAT slave and communicates with the bridging module through the EtherCAT slave driver firmware.
[0062] The first joint status data in the motor adaptation coordinate system is the raw joint status data directly output by the motor encoder and collected by the main control board via the CAN bus, without undergoing coordinate transformation processing.
[0063] The EtherCAT real-time communication link features high real-time performance and deterministic latency. Sending control data through this link ensures efficient command transmission while simultaneously collecting raw joint status data, providing foundational data for subsequent reverse compensation, thus forming a two-way interaction between command issuance and status acquisition.
[0064] In the specific implementation process, the EtherCAT master station manager of the bridging module sends the EtherCAT adapted joint control data from the data structure to the EtherCAT slave driver firmware of the main control board via the EtherCAT real-time communication link according to a preset control cycle. After receiving the control data, the EtherCAT slave driver firmware of the main control board drives the motor to run through the CAN bus, and at the same time collects the estimated values of joint angle, joint speed, and torque in the motor's adapted coordinate system through the CAN bus. The EtherCAT master station manager reads this set of data in real time through the received data structure and records it as the first joint status data.
[0065] Step 5: Perform inverse compensation of direction and zero position on the first joint state data according to the joint transmission parameters, generate the second joint state data adapted by DDS, and publish the second joint state data to the motion control inference layer through DDS to realize the bidirectional communication bridge between EtherCAT and DDS.
[0066] Specifically, such as Figure 2 As shown, the coordinate system transformation module of the bridging module performs inverse compensation of the direction and zero position of the first joint state data according to the joint transmission parameters, and generates the second joint state data adapted by DDS. The EtherCAT-DDS bridging node publishes the second joint state data to the first DDS subscription module of the host computer's motion control inference layer through DDS, thereby realizing bidirectional communication bridging between EtherCAT and DDS.
[0067] It should be noted that the inverse compensation of direction and zero position is the process by which the coordinate system transformation module restores the first joint state data of the motor's adaptive coordinate system to the simulation coordinate system data, which is the inverse mapping of the forward compensation.
[0068] The second joint state data adapted by DDS is joint state data that conforms to the DDS protocol format and can be directly used by the operation and control inference layer. It is published to the first DDS subscription module of the operation and control inference layer through DDS.
[0069] Two-way communication bridging is a complete data loop that enables DDS command issuance and EtherCAT status feedback.
[0070] Because the first joint status data is the original motor data, it cannot be directly used by the upper-level motion control layer. It is restored to the simulation coordinate system data through the inverse compensation of the coordinate system transformation module, and then published to the first DDS subscription module of the upper-level motion control layer through the EtherCAT-DDS bridging node via DDS, thus completing the complete closed loop from command issuance to status feedback and realizing the bridging of the two types of communication protocols.
[0071] In one possible implementation, the first joint state data is subjected to directional and zero-position inverse compensation based on the joint transmission parameters to generate DDS-adapted second joint state data, including the following:
[0072] Extract the joint direction coefficient and joint zero-position offset, which are the same as those used in the forward compensation, from the joint transmission parameters to obtain the first joint state data acquired in step 4. Perform a full reverse conversion for the i-th joint. The angle is converted back according to the formula: simulated angle equals direction coefficient multiplied by motor angle, plus zero-position offset. The formula is as follows:
[0073]
[0074] in, Let be the zero-position offset of the i-th joint of the quadruped robot, in radians.
[0075] The speed is converted back according to the simulation speed being equal to the direction coefficient multiplied by the motor speed, as shown in the following formula:
[0076]
[0077] The feedforward torque estimate is converted back according to the formula: the simulated feedforward torque estimate equals the direction coefficient multiplied by the motor torque estimate. The formula is as follows:
[0078]
[0079] in, For the first quadruped robot The simulated feedforward torque estimates of each joint in the simulated coordinate system. For the first quadruped robot Estimated feedforward torque values of each joint in the motor-adapted coordinate system.
[0080] The second joint state data is generated based on the transformation results. The forward transformation and the reverse transformation are inverse mappings of each other.
[0081] This embodiment achieves parametric configuration loading, EtherCAT real-time communication link establishment, and bidirectional coordinate compensation of joint control commands and status data through the collaborative work of various components within the bridging module (YAML configuration file, EtherCAT master station manager, EtherCAT-DDS bridging node, coordinate system transformation module, EtherCATNode interface, send / receive data structure, and handle driver module). This fully realizes bidirectional EtherCAT-DDS communication bridging between the quadruped robot's host computer and the main control board, improving the real-time performance and determinism of the communication link and reducing data transmission latency and jitter. The parametric configuration enhances the adaptability to different hardware platforms and robot models, reducing code modification and maintenance costs. Bidirectional compensation for direction and zero position eliminates the difference between the simulation coordinate system and the motor encoder coordinate system, reducing control deviation and improving the accuracy and stability of joint motion control. Finally, a complete closed loop of command issuance and status feedback data is constructed, ensuring the reliable operation of the quadruped robot's motion control system.
[0082] Example 2
[0083] Considering that the bidirectional communication bridging in Embodiment 1 only realizes the bidirectional transmission of joint commands and joint states, while the real-time motion control of a quadruped robot requires the collaborative participation of posture sensing data, and that the original IMU data units are not uniform and cannot be directly used by the upper-level motion control algorithm, nor can it be synchronously published to the first DDS subscription module with the joint states, this will lead to incomplete control data and require the algorithm to perform additional secondary conversion. Therefore, it is necessary to supplement the bridging with an IMU data standardization and fusion publishing mechanism to complete the sensor data link. In one possible implementation, the method further includes the following:
[0084] The EtherCAT master station manager of the bridging module receives raw IMU data from the main control board via the EtherCAT real-time communication link through a data structure receiving system. This raw IMU data includes quaternions, angular velocity, acceleration, and Euler angles. The coordinate system transformation module performs unit standardization processing on the raw IMU data, converting all types of sensor data into SI values to generate standardized IMU data. This standardized IMU data is then integrated with the second joint status data to generate fused IMU status data. This fused IMU status data is then synchronously published by the EtherCAT-DDS bridging node to the first DDS subscription module in the motion control inference layer via DDS.
[0085] In this embodiment, the raw IMU data is collected and then standardized to convert the raw data into SI units. The data is then integrated with the second joint status data and published synchronously through the same DDS channel to ensure that the sensor data and joint status are aligned in time.
[0086] Example 3
[0087] Considering that the above embodiments only address the protocol conversion and transmission of joint data, such as Figure 2 As shown, peripheral devices (such as gamepads) need to be connected to the bridging module. Using a separate process would increase latency and complexity. Therefore, in addition to bridging, the gamepad driver module needs to supplement the peripheral unified access parsing module, incorporating peripheral data into the same bridging system to achieve integrated management of control commands, joint states, and peripheral data. In one possible implementation, the method further includes the following:
[0088] The bridging module's handle driver module loads the YAML parameterized configuration file and parses the peripheral access parameters, then calls the system driver interface based on these parameters. It collects raw peripheral data input from the peripheral device via the system driver interface, reads the handle layout type parameter from the peripheral access parameters, and matches it with the corresponding parsing rules. Based on these rules, it performs periodic parsing processing on the raw peripheral data to generate standard handle data. This standard handle data is then sent to the coordinate system transformation module and fused with the second joint state data to generate fused handle state data. The EtherCAT-DDS bridging node synchronously publishes this fused handle state data to the second DDS subscription module in the motion control inference layer via DDS.
[0089] Specifically, the EtherCAT-DDS bridging node embeds the controller fusion status data into the rt / wirelesscontroller topic and publishes it synchronously to the second DDS subscription module of the upper-layer operation and control inference layer through DDS. That is, the second DDS subscription module corresponds one-to-one with the rt / wirelesscontroller topic and is used to subscribe to the controller and peripheral fusion status data.
[0090] For example, the configuration file is loaded to parse peripheral parameters, and the raw peripheral data is read through the Linux joystick driver interface; it supports two layouts, Xbox and Switch, which can be switched through the joystick.type field in the configuration file; it parses data at a fixed 2ms cycle to generate standard controller data; it merges the controller data with the second joint state data and publishes it to the rt / wirelesscontroller topic.
[0091] This embodiment parses peripheral parameters through configuration files, collects raw data and automatically parses it according to layout type, merges standard handle data with second joint status data, and publishes it uniformly through DDS, so as to realize the same source, synchronization and same link transmission of peripheral data and joint status, realize centralized management of peripherals, support configuration switching of multiple types of peripherals, and reduce communication latency; the synchronous publication of peripheral data and joint status improves control response speed and simplifies system architecture.
[0092] Example 4
[0093] Considering that the bidirectional communication bridge in the above embodiments only achieves correct data conversion and transmission, and does not include a startup security verification mechanism, if a joint control command is issued directly before the motor has been enabled, the motor is prone to sudden movements, causing mechanical shock or even equipment damage. To solve this technical problem, in one possible implementation, the method further includes the following:
[0094] After the EtherCAT master station manager of the bridging module completes the initialization of the EtherCAT master station and enters the running state, it sends an enable command to the generator to the main control board. It polls and collects the enable status data fed back by the motors through the EtherCAT real-time communication link, and determines whether all motors have been enabled based on the enable status data. Based on the determination that all motors are enabled, the DDS transceiver thread is started to perform data interaction.
[0095] For example, after the master station enters the running state, it sends an enable command to the motor and clears all control quantities; it polls the enable status at a 1ms cycle, and if the enable is not enabled after 5000ms, it records the ID and name of the disabled joint, calls DisableMotors to send a disable command, stops the master station, and exits with an error code; after all are enabled, it starts the DDS transceiver thread, where DisableMotors is a motor disable control function encapsulated in the EtherCAT master station manager in the bridging module, used to send a motor disable command to the main control board, forcibly cut off the motor power output, and realize mechanical safety protection.
[0096] In this embodiment, after the master station enters the running state, it first issues a generator enable command and polls to verify the status of all motors. After confirming that all motors are enabled, it starts the DDS transceiver thread to avoid sending control commands to disabled motors, avoid the risk of disabled motors receiving sudden commands, complete the safety verification before system startup, improve the safety of on-machine operation, and protect the mechanical structure.
[0097] Example 5
[0098] Considering that the above embodiments do not handle scenarios of abnormal system termination, if communication is stopped directly when a termination signal is received or the program exits abnormally, the motor will continue to run uncontrollably in its current state, which can easily cause mechanical impact and equipment damage. To solve this technical problem, in one possible implementation, the method further includes the following:
[0099] After receiving the system termination signal, the host computer triggers the safe exit process; the EtherCAT master station manager of the bridging module sends a generator disabling command through the EtherCAT real-time communication link and clears all joint control parameters; based on the motor disabling completion result, the EtherCAT master station stops running; based on the EtherCAT master station stopping result, the system safe exit is completed.
[0100] For example, the host computer receives the SIGINT / SIGTERM termination signal and triggers the safe exit process; it issues a generator disabling command to clear all joint control parameters; after confirming the motor disabling, it stops the EtherCAT master station and completes the safe exit.
[0101] Upon receiving the system termination signal, this embodiment does not directly stop the master station. Instead, it first issues a generator disabling command, clears all control parameters, and confirms that the motor has safely stopped before stopping the EtherCAT master station. This achieves a controllable and smooth safe exit, ensuring that the motor smoothly disables itself during normal or abnormal system termination and avoiding mechanical shock. This forms a standardized safe exit procedure, significantly improving the safety of system operation.
[0102] The embodiments described above are merely illustrative of specific implementations of the present invention, and while the descriptions are detailed, they should not be construed as limiting the scope of the present invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these modifications and improvements all fall within the scope of protection of the present invention.
Claims
1. A method for bridging EtherCAT-DDS communication between a host computer and a main control board of a quadruped robot, characterized in that, Includes the following steps: Step 1: The host computer loads the parameterized configuration file, parses the EtherCAT communication parameters and joint transmission parameters, and generates a communication configuration structure; Step 2: Initialize the EtherCAT master station based on the communication configuration structure, complete the master-slave PDO mapping and DC distributed clock synchronization, and establish the EtherCAT real-time communication link between the host computer and the main control board. Step 3: The host computer subscribes to the joint control commands of the motion control inference layer through DDS, and performs positive compensation for the execution direction and zero position of the joint control commands based on the joint transmission parameters to generate EtherCAT-adapted joint control data. Step 4: Send the EtherCAT-adapted joint control data to the main control board via the EtherCAT real-time communication link, and collect the first joint status data in the motor-adapted coordinate system fed back by the main control board through the EtherCAT real-time communication link. Step 5: Perform inverse compensation of direction and zero position on the first joint state data according to the joint transmission parameters, generate the second joint state data adapted by DDS, and publish the second joint state data to the motion control inference layer through DDS to realize the bidirectional communication bridge between EtherCAT and DDS.
2. The EtherCAT-DDS communication bridging method for a quadruped robot host computer and main control board according to claim 1, characterized in that, The initialization of the EtherCAT master station based on the communication configuration structure includes the following: Extract network card information, CPU binding information, and real-time thread priority information from the communication configuration structure; Based on the network card information, complete the network card binding; based on the CPU binding information, complete the CPU binding; based on the real-time thread priority information, complete the real-time thread priority configuration, and generate the main station runtime environment configuration result. Based on the master station's operating environment configuration results, enumerate EtherCAT slave stations and complete slave station node registration, generating slave station node registration results; Based on the registration results of the slave nodes, the EtherCAT master station state machine is controlled to switch step by step to complete the EtherCAT master station initialization.
3. The EtherCAT-DDS communication bridging method between the upper computer and the master control board of the quadruped robot according to claim 1, characterized in that, The master-slave PDO mapping includes the following: Obtain the trigger signal for the EtherCAT master station to switch from PREOP state to SAFEOP state; Based on the trigger signal, the sent data field and received data field are obtained through the callback function of the slave node; Based on the acquired data fields, the sent data fields are mapped to sent process data objects, and the received data fields are mapped to received process data objects; Based on the mapped process data object, fixed byte alignment processing is performed on the data structure to generate a transmission data format that matches the main control board firmware.
4. The EtherCAT-DDS communication bridging method between the upper computer and the master control board of the quadruped robot according to claim 1, characterized in that, The DC distributed clock synchronization includes the following: Read the synchronization enable parameters from the communication configuration structure and start the clock synchronization process; Based on the synchronization enable parameters, the EtherCAT master station sends a synchronization clock configuration command to all slave stations. All slave stations are configured to align their own control cycle clock with the EtherCAT master station clock based on the synchronous clock configuration command. Based on the clock alignment results, master-slave clock drift is eliminated, and an EtherCAT real-time communication link with deterministic delay is generated.
5. The EtherCAT-DDS communication bridging method between the upper computer and the master control board of the quadruped robot according to claim 1, characterized in that, Step 3 Includes the following: Extract the joint direction coefficient and joint zero-position offset from the joint transmission parameters; Obtain the joint control command data of the simulation coordinate system subscribed to by DDS; Based on the joint orientation coefficient and the joint zero offset, a forward transformation is performed on the joint control command data of the simulation coordinate system. Based on the forward transformation results, EtherCAT-recognizable motor-adaptive coordinate system joint control data is generated.
6. The EtherCAT-DDS communication bridging method between the upper computer and the master control board of the quadruped robot according to claim 1, characterized in that, Based on the joint transmission parameters, the first joint state data is subjected to inverse compensation in direction and zero position to generate DDS-adapted second joint state data, which includes the following: Extract the joint direction coefficient and joint zero-position offset from the joint transmission parameters; Based on the joint orientation coefficient and the joint zero offset, the first joint state data is reverse-converted. Based on the reverse transformation results, the second joint state data is generated.
7. The EtherCAT-DDS communication bridging method between the upper computer and the master control board of the quadruped robot according to claim 1, characterized in that, The method also Includes the following: Raw IMU data fed back from the main control board is acquired via the EtherCAT real-time communication link; Perform unit standardization processing on the raw IMU data to generate standardized IMU data; Standardized IMU data is integrated with second joint status data to generate IMU fusion status data; The IMU fusion status data is synchronously published to the operation and control inference layer via DDS.
8. The EtherCAT-DDS communication bridging method between the upper computer and the master control board of the quadruped robot according to claim 1, characterized in that, The method also includes the following: Load the parameterized configuration file and parse the peripheral access parameters, then call the system driver interface based on the peripheral access parameters; Collect raw data from peripherals based on the system driver interface; Read the controller layout type parameter from the peripheral access parameters, and match the corresponding parsing rules based on the controller layout type parameter; Based on the parsing rules, the original data of the peripheral device is parsed and processed periodically to generate standard handle data; The standard handle data is fused with the second joint state data to generate handle fused state data; The controller fusion status data is synchronously published to the motion control inference layer via DDS.
9. A method for bridging EtherCAT-DDS communication between a host computer and a main control board of a quadruped robot according to claim 1, characterized in that, The method also includes the following: After the EtherCAT master station completes initialization and enters the running state, it sends a generator enable command to the main control board. The enable status data fed back by the motor is collected by polling through the EtherCAT real-time communication link. Determine whether all motors have been enabled based on the enable status data; Based on the judgment that all motors are enabled, the DDS transceiver thread is started to perform data interaction.
10. The EtherCAT-DDS communication bridging method between the upper computer and the master control board of the quadruped robot according to claim 1, characterized in that, The method also Includes the following: After receiving the system termination signal, the host computer triggers the safe exit procedure; The system executes a generator disabling command via the EtherCAT real-time communication link and clears all joint control parameters; based on the generator disabling result, it stops the EtherCAT master station; and based on the EtherCAT master station shutdown result, it completes a safe system exit.