A Fault Recovery Method and System for Quadruped Robots Based on Virtualization

Abstract

The present invention provides a fault recovery method and system for a quadruped robot based on virtualization, belonging to the field of robot control. The fault recovery system includes a Linux virtual machine and a controller monitoring system. A quadruped robot controller runs on the virtual machine. Whenever the MPC runs a fixed number of iterations, the controller records the running state information of the robot, packages it with a magic number, and sends it to the controller monitoring system through shared memory. The controller monitoring system sets a timer to check heartbeat packets. When an abnormality is detected, it triggers the Linux virtual machine restart mechanism. After the Linux virtual machine restarts, it synchronizes the latest stored running state information of the robot back to the controller, enabling the quadruped robot to resume the state corresponding to the latest running state information. The present invention improves the resistance of the quadruped robot to software faults, enabling the robot to achieve self-awareness without human intervention in case of system faults during operation.

Description

Technical Field

[0001] The present invention belongs to the technical field of robot control and virtualization, and particularly relates to a fault recovery method and system for a quadruped robot based on virtualization. Background Art

[0002] As a branch of robots, quadruped robots have a quadruped bionic structure, can complete exploration and rescue operations in complex environments and spaces, and do not require human participation. Therefore, quadruped robots may go to various different terrain environments to perform tasks, and have relatively high requirements for reliability. At present, there are many methods to improve reliability, such as enhancing the robustness of control algorithms, or when detecting that the quadruped robot is in an abnormal motion state, controlling the joint motors to execute corresponding preset instructions according to the type of abnormal motion state to eliminate the corresponding type of abnormal motion state.

[0003] In actual application scenarios, there are still some aspects that have not been considered. Reliability not only requires the upper-layer algorithm itself to be robust, but also requires the lower-layer system to have the ability to recover from faults. First, when a process or system crashes during operation, the traditional quadruped robot control system cannot achieve autonomous detection and self-introspection. Therefore, it is necessary for humans to restart the system and processes. And whenever the quadruped robot process starts, each joint motor will be reset, which will cause the loss of the previous running state information of the robot. If you want to enter the running state again, you still need to go through a series of state changes.

[0004] In recent years, with the continuous development of virtualization technology, virtualization-based fault tolerance technology has been widely applied in fields such as modern data centers and cloud computing environments. Fault tolerance can ensure that the virtual devices created by virtualization technology can automatically recover and continue to run when faults or errors occur, thus ensuring the reliability and security of the system. However, the traditional quadruped robot controller does not have the ability to recover from faults at the system level. Summary of the Invention

[0005] To solve the problems in the prior art, the present invention proposes a fault recovery method and system for a quadruped robot based on virtualization.

[0006] To solve the above technical problems, the technical solution adopted by the present invention is: a fault recovery method for a quadruped robot based on virtualization, comprising the following steps:

[0007] Step 1: The quadruped robot controller executes the MPC algorithm to achieve the centroid tracking of the quadruped robot. Whenever the MPC runs a fixed number of iterations, record the current running state information of the robot, where the running state information includes leg controller data, robot model parameters, MPC parameters, gait parameters, state estimator parameters, and sole trajectory planning parameters;

[0008] Step 2: Package the recorded running state information of the robot and the magic number into a heartbeat message, and send it to the controller monitoring system through shared memory;

[0009] Step 3: There is a timer in the controller monitoring system. If the controller monitoring system receives a heartbeat message within the set duration of the timer, unpack the message and check the magic number. When the magic number check is correct, update the robot running state information in the controller monitoring system and reset the timer at the same time; if the magic number check is incorrect, the controller monitoring system asks the quadruped robot controller to resend the heartbeat message;

[0010] Step 4: If a heartbeat message with a correct magic number check is not received within the set duration, the controller monitoring system triggers the Linux virtual machine restart mechanism. After the Linux virtual machine restarts, synchronize the latest robot running state information stored in the controller monitoring system back to the quadruped robot controller, so that the quadruped robot resumes the state corresponding to the latest robot running state information.

[0011] The present invention also provides a quadruped robot fault recovery system for implementing the above method. The system includes a Linux virtual machine and a controller monitoring system. The quadruped robot controller runs on the Linux virtual machine; the quadruped robot controller and the controller monitoring system realize system communication through shared memory;

[0012] The quadruped robot controller executes the MPC algorithm to achieve the centroid tracking of the quadruped robot. Whenever the MPC runs a fixed number of iterations, record the current running state information of the robot; package the recorded running state information of the robot and the magic number into a heartbeat message, and send it to the controller monitoring system through shared memory;

[0013] There is a timer in the controller monitoring system. If a heartbeat message is received within the set duration of the timer, unpack the message and check the magic number. When the magic number check is correct, update the robot running state information in the controller monitoring system and reset the timer at the same time; if the magic number check is incorrect, the controller monitoring system requires the quadruped robot controller to resend the heartbeat message; if a heartbeat message with a correct magic number check is not received within the set duration, the controller monitoring system triggers the Linux virtual machine restart mechanism. After the Linux virtual machine restarts, the controller monitoring system synchronizes the latest robot running state information stored back to the quadruped robot controller, so that the quadruped robot resumes the state corresponding to the latest robot running state information.

[0014] The present invention enhances the recovery ability of software - type faults of the quadruped robot through the application of virtualization technology, and at the same time further reduces the dependence on manpower, making the quadruped robot more suitable for exploration and rescue operations in complex environments and spaces.

[0015] The fault recovery system is a virtualized system, including a Linux system (Linux virtual machine) and a real-time operating system (RTOS). A quadruped robot controller runs on the Linux system; the Linux system provides a rich tool kit, and the RTOS with real-time performance and reliability runs a controller monitoring system to improve the overall reliability of the system.

[0016] The method of the present invention enables the controller to restore to the context of the last run after restart, enhancing the resistance of the quadruped robot to system faults, so that when software faults occur during the operation of the robot, self-introspection can be realized without human intervention. Description of the Drawings

[0017] Figure 1 It is the architecture diagram of the quadruped robot system based on virtualization of the present invention.

[0018] Figure 2 It is the overall flowchart of the fault detection and recovery method.

[0019] Figure 3 It is the virtual machine monitor protocol diagram.

[0020] Figure 4 It is the schematic diagram of the leg joint length and angle of the quadruped robot. Detailed Embodiments

[0021] The following further elaborates and explains the present invention in conjunction with specific embodiments. The described embodiments are only examples of the present disclosure and do not delimit the scope of limitation. The technical features of each embodiment of the present invention can be combined correspondingly without conflict.

[0022] As Figure 1 shown, it is the architecture diagram of the quadruped robot system based on virtualization of the present invention. In robot control, the virtual machine monitor (Hypervisor) is mainly used for virtualization and resource management to ensure that multiple operating systems or applications can run efficiently and securely while sharing hardware resources. The robot system may need to run a real-time operating system (RTOS) and a general operating system (such as Linux) simultaneously. Hypervisor allows multiple operating systems to run in parallel on the same hardware, ensuring that real-time tasks and non-real-time tasks do not interfere with each other. In the quadruped robot of the present invention, Hypervisor is used to isolate control tasks and monitoring tasks to ensure that high-precision control and data collection do not interfere with each other.

[0023] As Figure 1As shown, in an embodiment of the present invention, a quadruped robot controller runs on a Linux system (Linux virtual machine); the Linux system provides a rich toolkit, and an RTOS with real-time performance and reliability runs a controller monitoring system to improve the overall reliability of the system. The quadruped robot controller and the controller monitoring system communicate through shared memory.

[0024] As Figure 2 shown, this embodiment provides a virtualization-based quadruped robot fault recovery method, which includes the following steps:

[0025] Step 1: The quadruped robot controller executes the MPC algorithm to achieve centroid tracking of the quadruped robot. Whenever the MPC runs a fixed number of iterations, record the current operating state information of the robot. The operating state information includes leg controller data, robot model parameters, MPC parameters, gait parameters, state estimator parameters, and sole trajectory planning parameters.

[0026] In Step 1, the fixed number of iterations is the period of MPC foot end force calculation; that is, when the MPC calculates the foot end support force of the current period, save the operating state parameters within this period.

[0027] In the present invention, the leg controller data includes the angles of each joint of the current quadruped robot, such as the hip joint rotation angle, thigh joint rotation angle, calf joint rotation angle, etc. The robot model parameters include the weight of the quadruped robot and the dimensions of each joint. The dimensions of each joint include, for example, the hip joint link length, thigh link length, calf link length, knee joint Y-direction link length, and so on. The MPC parameters include the foot end force calculated by the MPC and the current iteration number of the MPC. The gait parameter is the gait of the quadruped robot, such as trotting, jumping, running, walking and other gaits, and different gaits especially correspond to the swing time . The state estimator parameter is the current motion state of the quadruped robot, and the motion state includes attitude angle, position, attitude angular velocity and velocity.

[0028] The sole trajectory planning parameters include the predicted swing leg trajectory and the expected trajectory state data of the quadruped robot. Among them, the swing leg trajectory is obtained by calculating the landing point position in combination with the Bezier curve. The input of the Bezier curve is the positions of the foot end starting point and the landing point, as well as the maximum height of the leg swing. A smooth foot end swing curve is obtained by interpolating the Bezier curve. Therefore, the swing leg trajectory includes the positions of the foot end starting point and the landing point.

[0029] Among them, the starting point position is ;

[0030] In the formula, is the current coordinate of the fuselage, calculated by the state estimator, is the rotation matrix of the fuselage, is the coordinate of the hip joint in the fuselage coordinate system, is the coordinate of the leg in the hip joint coordinate system, calculated from the joint angles combined with the lengths of each link. The calculation formula is:

[0031] , where, is the length of the hip joint link, is the length of the thigh link, is the length of the calf link, is the length of the knee joint link in the Y direction, is the rotation angle of the hip joint, is the rotation angle of the thigh joint, is the rotation angle of the calf joint. The leg joint lengths and angles of the quadruped robot can be referred to Figure 4 . sidesign is the direction symbol, with a value of 1 for the left leg and -1 for the right leg. The rotation angles of the hip joint, thigh joint, and calf joint are all stored in the leg controller LegController.

[0032] The landing point position is ; where is the feedforward term, is the feedback term;

[0033] ; where is the current speed of the quadruped robot, is the swing time; ; where is the gain, is the desired speed of the quadruped robot, is the current speed of the quadruped robot.

[0034] The position of the supporting leg remains unchanged, but it is in contact with the ground. To maintain body balance, the end forces of each leg are required , where the subscript r represents the leg number of the quadruped robot. Denote the leg numbers: 1 represents the right front leg, 2 represents the left front leg, 3 represents the right hind leg, and 4 represents the left hind leg. The end forces of the four legs at time i are .

[0035] and are obtained by quadratic programming. The constraint formula for quadratic programming is as follows:

[0036] ;

[0037] ;

[0038] ;

[0039] wherein, represents the motion state data of the quadruped robot at the current moment, is the attitude angle, is the position, is the angular velocity of the attitude, is the velocity. Among them, , , are the roll angle, pitch angle, and yaw angle respectively; x, y, and z are the position coordinates of the robot in three dimensions, represents the predicted motion state data of the quadruped robot at a future moment, represents the expected trajectory state data of the quadruped robot at this future moment, represents the end - point forces of the four legs at the current moment, and are the weight ratios, and are constant matrices, is the friction coefficient, and are the upper and lower boundaries of the friction force; Solving the above - mentioned planning obtains the current end - point forces of the quadruped robot.

[0040] Therefore, whenever the MPC runs a fixed number of iterations, the current running state information of the robot that needs to be recorded includes leg controller data, robot model parameters, MPC parameters, gait parameters, state estimator parameters, and sole trajectory planning parameters.

[0041] Step 2: Package the recorded running state information of the robot and the magic number into a heartbeat message, and send it to the controller monitoring system through shared memory. The magic number is a pre - agreed string used to verify the correctness of the current heartbeat message.

[0042] Step 3: There is a timer in the controller monitoring system. If the controller monitoring system receives a heartbeat message within the set duration of the timer, it unpacks the message, checks the magic number. When the magic number check is correct, it updates the robot running state information in the controller monitoring system and resets the timer; if the magic number check is incorrect, the controller monitoring system asks the quadruped robot controller to resend the heartbeat message.

[0043] The set duration of the timer is 2 times the average time to receive a heartbeat. When no heartbeat message is received within the set duration, or the message is incorrect, it is considered that the quadruped robot controller has an operation error and a recovery operation is executed.

[0044] According to the requirements of different scenarios, the set duration in the timer needs to be set according to the requirements. The smaller the set duration, the faster the response speed to faults. However, due to the possible communication delay of the heartbeat message, the error rate of fault judgment is higher. The larger the set duration, the slower the response speed to faults, but the error rate of fault judgment is lower.

[0045] Step 4: If a heartbeat message with correct magic number check is not received within the set duration, the controller monitoring system triggers the Linux virtual machine restart mechanism. After the Linux virtual machine restarts, the latest robot running state information stored in the controller monitoring system is synchronized back to the quadruped robot controller, so that the quadruped robot resumes the state corresponding to the latest robot running state information.

[0046] Specifically, when a heartbeat message with correct magic number check is not received within the set duration, load the virtual machine image to the specified memory address. After the loading is completed, start the Linux virtual machine from this memory address;

[0047] After the Linux virtual machine starts normally, obtain the latest robot running state information saved in the controller monitoring system through shared memory;

[0048] Start the quadruped robot controller and start it in the fault recovery mode through parameter configuration, that is, first enter the running state of the quadruped robot, load the latest robot running state information, restore the program context, and then the quadruped robot controller runs normally.

[0049] As Figure 3 shown is the virtual machine monitoring protocol executed by the controller monitoring system involved in Steps 2 - 4 of the present invention. "Running State" in the figure is the current running state information of the robot. SmartOSEK OS in the figure is a real-time operating system (RTOS) designed specifically for embedded systems and follows the OSEK / VDX standard. OSEK (Open Systems and the Corresponding Interfaces for Automotive Electronics) is an open system standard aimed at improving the portability and reusability of software. SmartOSEK OS is widely used in embedded fields such as automotive electronics and industrial control. "SYN (Synchronize)" and "ACK (Acknowledgment)" are two key control flags used in TCP (Transmission Control Protocol) to establish a reliable connection. SYN is used to initiate a connection request and synchronize the sequence number; the receiving party sends an ACK message to confirm that it has received SYN or data.

[0050] Based on the above understanding of the method, the present invention also provides a virtualized fault recovery system for supporting the above method. The system includes a Linux virtual machine and a controller monitoring system. A quadruped robot controller runs on the Linux virtual machine. The quadruped robot controller and the controller monitoring system communicate through shared memory.

[0051] The quadruped robot controller executes the MPC algorithm to achieve the centroid tracking of the quadruped robot. Whenever the MPC runs a fixed number of iterations, the current running state information of the robot is recorded. The recorded running state information of the robot and the magic number are packed into a heartbeat message and sent to the controller monitoring system through shared memory.

[0052] The controller monitoring system has a timer. If a heartbeat message is received within the set duration of the timer, the message is unpacked and the magic number is checked. When the magic number check is correct, the running state information of the robot is updated in the controller monitoring system, and the timer is reset at the same time. If the magic number check is incorrect, the controller monitoring system requests the quadruped robot controller to resend the heartbeat message. If a heartbeat message with a correct magic number check is not received within the set duration, the controller monitoring system triggers the Linux virtual machine restart mechanism. After the Linux virtual machine restarts, the controller monitoring system synchronizes the latest stored running state information of the robot back to the quadruped robot controller, so that the quadruped robot resumes to the state corresponding to the latest running state information of the robot. The present invention improves the resistance of the quadruped robot to system failures, enabling the robot to achieve self-awareness without human intervention during operation in case of system failures.

[0053] The above embodiments only represent several implementation manners of the present invention. The description is relatively specific and detailed, but it should not be construed as a limitation on the scope of the patent of the present invention. For those of ordinary skill in the art, without departing from the concept of the present invention, several modifications and improvements can still be made, and these all belong to the protection scope of the present invention.

Claims

1. A fault recovery method for a quadruped robot based on virtualization, characterized in that, It includes the following steps: Step 1: The quadruped robot controller executes the MPC algorithm to achieve centroid tracking of the quadruped robot. Whenever the MPC runs a fixed number of iterations, record the current operating state information of the robot. The operating state information includes leg controller data, robot model parameters, MPC parameters, gait parameters, state estimator parameters, and sole trajectory planning parameters; Step 2: Package the recorded operating state information of the robot and a magic number into a heartbeat message and send it to the controller monitoring system through shared memory; Step 3: The controller monitoring system has a timer. If the controller monitoring system receives a heartbeat message within the set duration of the timer, unpack the message and check the magic number. When the magic number check is correct, update the robot operating state information in the controller monitoring system and reset the timer at the same time; if the magic number check is incorrect, the controller monitoring system asks the quadruped robot controller to resend the heartbeat message; Step 4: If a heartbeat message with a correct magic number check is not received within the set duration, the controller monitoring system triggers the Linux virtual machine restart mechanism. After the Linux virtual machine restarts, synchronize the latest robot operating state information stored in the controller monitoring system back to the quadruped robot controller, so that the quadruped robot resumes the state corresponding to the latest robot operating state information; The specific content of Step 4 is as follows: When a heartbeat message with a correct magic number check is not received within the set duration, load the virtual machine image to the specified memory address. After the loading is completed, execute the startup process of the Linux virtual machine from this memory address; After the Linux virtual machine starts up normally, obtain the latest robot operating state information saved in the controller monitoring system through shared memory; Start the quadruped robot controller and start it in the fault recovery mode through parameter configuration, that is, first enter the running state of the quadruped robot, load the latest robot operating state information, restore the program context, and then the quadruped robot controller runs normally.

2. The method for fault recovery of a quadruped robot based on virtualization according to claim 1, wherein, In Step 1, the fixed number of iterations is the period of MPC foot-end force calculation; that is, when the MPC calculates the foot-end support force of the current period, save the operating state parameters within this period.

3. The method for fault recovery of a quadruped robot based on virtualization according to claim 1, wherein The leg controller data includes the angles of each joint of the current quadruped robot; the robot model parameters include the weight of the quadruped robot and the dimensions of each joint; the MPC parameters include the foot-end force calculated by the MPC and the current iteration number of the MPC; the gait parameter is the gait of the quadruped robot; the state estimator parameter is the current motion state of the quadruped robot, and the motion state includes attitude angle, position, attitude angular velocity, and velocity; the sole trajectory planning parameters include the predicted swing leg trajectory and the desired trajectory state data of the quadruped robot.

4. The method for fault recovery of a quadruped robot based on virtualization according to claim 3, wherein, The predicted swing leg trajectory includes the positions of the foot-end starting point and the landing point; Among them, the starting point position is , is the current coordinate of the fuselage, is the rotation matrix of the fuselage, is the coordinate of the hip joint in the fuselage coordinate system, is the coordinate of the leg in the hip joint coordinate system, which is calculated from the joint angles combined with the lengths of each link. The calculation formula is: , where is the length of the hip joint link, is the length of the thigh link, is the length of the calf link, is the length of the knee joint link in the Y direction, is the hip joint rotation angle, is the thigh joint rotation angle, is the calf joint rotation angle, and sidesign is the direction symbol, with a value of 1 for the left leg and -1 for the right leg; The landing point position is ; where is the feedforward term, is the feedback term; ; where is the speed of the current quadruped robot, is the swing time; ; where is the gain, is the desired speed of the quadruped robot, is the speed of the current quadruped robot.

5. The virtualization-based quadruped robot fault recovery method according to claim 3, wherein The foot-end force calculated by the MPC is obtained by solving the following planning problem: The planning problem is: ； ； ； Among them, represents the motion state data of the quadruped robot at the current moment, is the attitude angle, is the position, is the angular velocity of the attitude, is the velocity, represents the predicted motion state data of the quadruped robot at a future moment, represents the expected trajectory state data of the quadruped robot at that future moment, represents the end - point forces of the four legs at the current moment, and is the weight ratio, and is the constant matrix, is the friction coefficient, and are the upper and lower boundaries of the frictional force; Solve the above planning to obtain the current foot-end force of the quadruped robot.

6. The method for fault recovery of a quadruped robot based on virtualization according to claim 1, characterized in that In Step 2, the magic number is a pre-agreed string used to verify the correctness of the current heartbeat message.

7. A fault recovery method for a quadruped robot based on virtualization according to claim 1, characterized in that In step 3, the set duration of the timer is twice the average time between receiving heartbeats. If no heartbeat message is received within the set duration or the message is incorrect, it is considered that the quadruped robot controller has an operation error and a recovery operation is executed.

8. A quadruped robot fault recovery system for implementing the method according to claim 1, characterized in that, The system includes a Linux virtual machine and a controller monitoring system. The quadruped robot controller runs on the Linux virtual machine; the quadruped robot controller and the controller monitoring system achieve system communication through shared memory; The quadruped robot controller executes the MPC algorithm to achieve centroid tracking of the quadruped robot. Whenever the MPC runs a fixed number of iterations, the current operation state information of the robot is recorded; the recorded operation state information of the robot and the magic number are packed into a heartbeat message and sent to the controller monitoring system through shared memory; The controller monitoring system has a timer. If a heartbeat message is received within the set duration of the timer, the message is unpacked and the magic number is checked. When the magic number check is correct, the operation state information of the robot is updated in the controller monitoring system and the timer is reset at the same time; if the magic number check is incorrect, the controller monitoring system requests the quadruped robot controller to resend the heartbeat message; if a heartbeat message with a correct magic number check is not received within the set duration, the controller monitoring system triggers the Linux virtual machine restart mechanism. After the Linux virtual machine restarts, the controller monitoring system synchronizes the latest stored operation state information of the robot back to the quadruped robot controller, so that the quadruped robot resumes to the state corresponding to the latest operation state information of the robot.

Images