Microsurgery robot protection stopping system

Abstract

The invention relates to a protection stopping system for a microsurgical robot. The protection stopping system comprises system software, a hardware control subsystem, a motion control subsystem and a user interaction subsystem. The system software is in two-way communication with the hardware control subsystem and the motion control subsystem through a heartbeat mechanism, the running state of the system is monitored in real time, and when abnormity is detected, a protection stop mechanism is automatically triggered, motion of an actuator is stopped immediately, and a power supply is cut off. The protection stopping mechanism has an automatic triggering mode and a manual triggering mode, the automatic triggering mode is automatically switched by system software according to abnormal signals, and the manual triggering mode achieves emergency power-off operation through the user interaction subsystem. By means of the protection stopping system, dangers caused by abnormal control of the system, hardware or motion can be effectively prevented, and safe operation of the microsurgical robot is ensured. The real-time response capability and safety of the robot system are improved, and the safety of a patient is greatly guaranteed.

Description

TECHNICAL FIELD

[0001] The present application relates to the medical field, and in particular to a microsurgery robot protection stopping system. BACKGROUND

[0002] The microsurgery robot is a high-risk complex medical device, which requires high precision control and high safety during the operation. When an abnormality occurs during the operation, the device must be stopped quickly and safely and withdrawn. However, the prior art usually adopts the emergency stop power-off and the motor brake to achieve the stop, but in the microsurgery, the response speed of the system and the mechanical drop generated after the brake device is started are often unacceptable. This delay may cause the fine movement in the operation to be unable to stop in time, thereby affecting the safety of the patient. SUMMARY

[0003] To solve the above technical problems, the present application provides a microsurgery robot protection stopping system, which can automatically trigger the protection mechanism when internal and external abnormalities occur, quickly stop the device movement through the cooperation of software and hardware, and effectively protect the safety of the patient. The present application is realized by the following technical solutions: The microsurgery robot protection stopping system of the present application comprises a system software and a subsystem, the subsystem comprises a hardware control subsystem, a motion control subsystem and a user interaction subsystem, the system software is used for coordinating the operation of each subsystem, receiving the control instruction from the user interaction subsystem, and monitoring the state of the hardware control subsystem and the motion control subsystem through the heartbeat mechanism to determine whether the system is in a normal operation state; The hardware control subsystem comprises a hardware control board and related hardware interfaces, is responsible for feeding back the hardware operation state to the system software through the heartbeat mechanism, providing hardware abnormality monitoring, and cutting off the power supply of the actuator through an independent protection stopping mechanism when an abnormality is detected, and providing a manual emergency power-off operation interface; The motion control subsystem comprises an actuator and a motion control module, communicates with the system software, is responsible for controlling the action of the actuator according to the system instruction, and suspends or terminates the motion when an abnormality occurs in the system software or other subsystems to prevent the actuator from moving unexpectedly; The user interaction subsystem is used for receiving the control instruction input by the user, and delivering it to the related subsystem through the system software, providing the visual feedback of the system operation state, and alarming through sound and light in the abnormal condition.

[0004] The system software not only coordinates the operation of each subsystem, but also monitors the health status of each subsystem to ensure seamless collaboration between the hardware control subsystem, motion control subsystem, and user interaction subsystem. In the design of the system software, the heartbeat mechanism plays a crucial role in timely detecting communication or functional abnormalities, thereby preventing potential system crashes or operational errors. In addition, the system software can optimize operations based on real-time data and adjust system behavior according to user input control instructions.

[0005] Further, the above-mentioned microsurgical robot protection stop system is provided with a protection stop mechanism, including automatic triggering and manual triggering; the automatic triggering mechanism is automatically activated by the system software according to abnormal signals, including hardware abnormalities, motion control abnormalities, and system software abnormalities; the manual triggering mechanism is triggered through the user interaction subsystem, disabling the actuator and suspending the motion control system.

[0006] The automatic triggering mechanism is activated by the system software based on abnormal signals, which not only includes hardware abnormalities, but also includes motion control subsystem and system software abnormalities. The manual triggering mechanism allows users to directly intervene through the user interaction subsystem for emergency stop. Manual triggering provides operators with additional safety control, allowing timely implementation of protective measures when the automatic system may not respond, preventing further risks.

[0007] Further, the above-mentioned microsurgical robot protection stop system is provided with a heartbeat mechanism, and the system software maintains a bidirectional heartbeat mechanism with the hardware control subsystem and motion control subsystem to ensure the real-time and reliability of the system, and automatically starts the protection stop mechanism when the heartbeat signal is lost.

[0008] The bidirectional heartbeat mechanism is crucial for ensuring the real-time and reliability of the system. The exchange of timing signals between the system software and the hardware control subsystem and motion control subsystem ensures the healthy operation of each subsystem. If one party fails to respond to the heartbeat signal, the system software will identify the abnormality and immediately activate the protection stop mechanism to prevent the system from continuing to run in an abnormal state. In addition, the heartbeat mechanism ensures smooth and timely data transmission, improving the overall fault tolerance of the system.

[0009] Further, the above-mentioned microsurgical robot protection stop system abnormality detection and processing process includes the system software coordinating each subsystem to take measures when system, hardware, or motion control abnormalities occur, including pausing the actuator, executing forced power cutoff through the hardware control subsystem, or providing alarm information through the user interaction subsystem to ensure patient safety.

[0010] When an anomaly occurs, the system software not only detects the fault but also coordinates the various subsystems to quickly implement appropriate countermeasures. For example, if the system software detects a hardware anomaly, the hardware control subsystem might immediately cut off power; while a motion control subsystem anomaly might pause motion and issue a warning signal. The user interaction subsystem displays relevant alarm information, allowing the user to make necessary interventions or adjustments. By coordinating the responses of various subsystems, the system maximizes patient safety.

[0011] Furthermore, the hardware control subsystem also includes a self-check function, which performs a self-check when the system is turned on to ensure that the hardware is in a normal state.

[0012] The hardware control subsystem's self-test function is crucial for ensuring stable hardware operation. This power-on self-test allows the hardware control subsystem to promptly detect and report hardware issues, preventing the system from entering an abnormal state. This self-test process can include power checks, connection verification, and preliminary testing of sensors and actuators, ensuring that potential hardware failures are avoided before system startup.

[0013] Furthermore, the motion control subsystem communicates with the system software through an API, and when an abnormal state is detected, it automatically sends a stop signal and locks the actuator to prevent unexpected actions.

[0014] The API communication interface plays a crucial role in the motion control subsystem. Through the API, the motion control subsystem can communicate the current status of the actuator and any potential anomalies to the system software. This two-way communication not only ensures that the system software can accurately control the actuator's movements but also promptly triggers a stop signal in the event of an abnormal condition, preventing the actuator from continuing to perform incorrect actions and potentially preventing risks.

[0015] Furthermore, the above-mentioned protection stop mechanism further includes executing forced power cutoff through the hardware control subsystem when the system software detects that the hardware or motion control subsystem has failed, thereby ensuring that the motion is safely stopped under abnormal circumstances to prevent danger.

[0016] In the event of a hardware or motion control subsystem failure, the hardware control subsystem can implement a forced power cutoff function. This measure further enhances safety, allowing the hardware control subsystem to independently ensure a safe stop by cutting off the power supply even if the system software's own monitoring fails to respond in time, thus preventing the dangers that may arise from continued system operation.

[0017] Furthermore, the above system software also has the ability to determine whether to resume normal operation based on the system status, and can recover from the protection stop state to the normal working state when the conditions are met.

[0018] The system software not only can handle faults, but also has recovery function. When the system is in protection stop mode, the system software will determine whether to resume normal operation according to the health status of the system. This includes checking all subsystem heartbeat signals, confirming the hardware self-check, verifying the state of the actuator, and monitoring the communication state of the user interaction subsystem. Only when everything is normal, the system software can coordinate the subsystems to gradually restore the normal working state.

[0019] Further, the above-mentioned bidirectional heartbeat mechanism includes the exchange of timing signals between the system software and the hardware control subsystem and the motion control subsystem. The system software regularly sends heartbeat signals to the hardware control subsystem and the motion control subsystem and receives feedback heartbeat response signals to ensure the normal operation state of each subsystem. If the system software does not receive the feedback heartbeat signal, it automatically triggers the protection stop mechanism to suspend the actuator movement and cut off the power supply to ensure system safety.

[0020] The bidirectional heartbeat mechanism realizes the health monitoring of the subsystems through the exchange of timing signals. When the system software fails to receive the expected heartbeat signal, it automatically triggers the protection stop mechanism. The system will immediately suspend the actuator movement and cut off the power supply to prevent abnormal operation of the system. This mechanism ensures that the system can take timely measures in abnormal situations to prevent further fault expansion.

[0021] Further, the above-mentioned recovery conditions include: when the system software detects that the hardware control subsystem and the motion control subsystem have returned to normal operation state and no abnormal signal exists, the system software determines whether to return to normal working state according to the preset rules; the above-mentioned preset rules include: confirming that all subsystem heartbeat signals are normal, the hardware self-check is passed, the actuator of the motion control subsystem is in a safe state, and the communication between the system software and the user interaction subsystem is restored to normal, when the above-mentioned conditions are met, the system software gradually enables the actuator by coordinating each subsystem, and removes the suspension state of the motion control subsystem, so that the system returns to normal work.

[0022] The recovery process not only depends on automatic judgment, but also includes preset recovery conditions and manual intervention mode. The recovery conditions include confirming all subsystem heartbeat signals, passing the hardware self-check, and the actuator being in a safe state. When these conditions are met, the system software will coordinate each subsystem to gradually restore normal operation. The manual intervention mode provides the operator with more control to ensure that the system can be adjusted according to actual needs during the recovery process.

[0023] In addition, further explanations of the present application are as follows: I. About system software System software is the core coordination module of the entire microsurgery system, responsible for scheduling, communication, monitoring, exception handling, and other functions. The following will introduce the definition, core functions, interaction methods, exception handling capabilities, and design features of system software.

[0024] Definition of system software System software is a standalone program module responsible for coordinating the operation of hardware control subsystem, motion control subsystem, and user interaction subsystem, ensuring that the surgical robot can operate safely and reliably under normal and abnormal conditions.

[0025] System software is the "control center" of multiple subsystems, coordinating their work through communication interfaces. In the context of microsurgery, it has high real-time performance and can quickly respond to exceptions. System software can perform self-checking at startup and normal startup after troubleshooting. System software provides software and hardware protection mechanisms to ensure system safety and stability.

[0026] Core functions of system software 2.1 Subsystem communication and management Through IPC (Inter-Process Communication), TCP, UART, etc. Interface, communicate with hardware control subsystem, motion control subsystem and user interaction subsystem. It has a unified interface to coordinate information transmission between user interaction, hardware control and motion control. It can send instructions to each subsystem and receive feedback data for real-time state monitoring.

[0027] 2 Protection stop mechanism System software is the main trigger and coordinator of the protection stop mechanism, which can automatically trigger the protection stop, i.e. according to sensor, hardware feedback and software logic conditions, suspend or terminate the motion control subsystem action. It can also manually trigger the protection stop, i.e. through the user interface (such as buttons, touch screen) to trigger the protection stop.

[0028] After triggering, communicate with the hardware control subsystem and the motion control subsystem to disable the actuator and ensure patient safety.

[0029] 3 Exception detection and layered processing System software provides multi-level exception handling capabilities, which can monitor the heartbeat signals of all subsystems (hardware control, motion control), judge their running state, and analyze their running data to determine whether an unexpected exception has occurred.

[0030] When an exception is detected, if it is determined to be a mild exception, the subsystems will be suspended to allow recovery operations; if it is determined to be a serious exception, the protection stop mechanism will be triggered, or even forced to cut off the power supply.

[0031] 4 State monitoring and feedback System software provides system and subsystem running state analysis, and displays the current system state, subsystem running state, actuator state, and abnormal information on the user interaction interface. After triggering the protection stop mechanism, it determines whether to recover from the protection stop state to normal operation through state monitoring.

[0032] 5 Abnormal recovery When the recovery condition is met, the system software allows gradual recovery from the protection stop state to the normal state, supporting both manual and automatic recovery modes.

[0033] Interaction mode of system software 3.1 Interaction with user subsystem System software transmits user operation instructions (such as start, pause, stop) to related subsystems. In abnormal situations, it transmits alarm information to users through visual and audio means. The user interface can be a touch screen, buttons, etc., interacting with system software through API.

[0034] 2 Communication with hardware control subsystem System software communicates with hardware control subsystem based on communication protocols (such as UART or TCP), sends heartbeat signals, monitors the state of hardware control subsystem, receives real-time data from hardware (such as sensor state, protection stop button state), and triggers or releases the protection stop mechanism according to hardware feedback.

[0035] 3 Communication with motion control subsystem Motion control subsystem provides API interface calls for instruction transmission and state monitoring. System software sends motion instructions to motion control subsystem, enables or disables actuators, and receives feedback data from motion control subsystem (such as position information, motion state), and when motion control subsystem fails, it directly monitors actuator state for state judgment.

[0036] Abnormal handling mechanism of system software 4.1 Abnormal source Hardware abnormalities include hardware control subsystem failure, sensor failure or data anomaly; motion control abnormalities include actuator loss of control or disconnection, motion control logic anomaly; system software itself abnormalities include crash, instruction error, etc.

[0037] 2 Abnormal hierarchical processing Subsystem abnormality: detect heartbeat timeout, system software triggers protection stop, and pauses related subsystems.

[0038] Hardware control subsystem abnormality: hardware control subsystem automatically takes over and cuts off actuator power.

[0039] Motion Control Subsystem Anomaly: System software coordinates the pause and further processing by directly monitoring the actuator status.

[0040] Self Anomaly: When system software fails, the hardware control subsystem and motion control subsystem start independent protection logic.

[0041] Design Features of System Software 5.1 High Modularity System software adopts modular design, and each subsystem interacts through API or communication protocol. Modular design makes the system easy to extend and maintain.

[0042] 2 Redundant Design Heartbeat mechanism is used between system software and subsystems for bidirectional monitoring to ensure safe operation. When system software fails, the hardware control subsystem can operate independently.

[0043] 3 Real-time and Reliability Real-time communication protocol is used to ensure the timeliness of command transmission and state feedback between subsystems. In abnormal situations, protection mechanisms can be triggered quickly to ensure safety.

[0044] 4 User Friendliness An intuitive user interface is provided to support surgeons operating the system through various means. Detailed operation and abnormal information is provided through visual and audio-visual prompts.

[0045] In summary, system software is the central nervous system of the entire microsurgery system, connecting and coordinating the operation of all subsystems. Its core responsibility is to ensure that the system can safely and efficiently complete the surgical task through bidirectional heartbeat mechanism, anomaly monitoring and layered protection. In design, system software enhances the scalability and reliability of the system through modular and redundant design, while providing a friendly user experience.

[0046] II. About Hardware Control Subsystem The hardware control subsystem is an important part of the microsurgery system, responsible for hardware state monitoring, collaboration with system software, and independent protection actions in abnormal situations. Among them: 1. Interaction between hardware subsystem and system software Communication mechanism: Hardware subsystem communicates with system software through independent hardware control board. Typical protocols include IPC, TCP or UART.

[0047] Heartbeat mechanism is used to monitor the running state of system software, and protection mechanism is started when heartbeat timeout.

[0048] Hardware feedback data is used to determine whether the current system state is normal, such as actuator status, heartbeat signal continuity, etc.

[0049] Function Trigger: In normal operation, the system software can call the interface (API) of the hardware subsystem for user interaction and actuator power control.

[0050] When the system software judges an abnormal scenario (such as needing to cut off actuator power), it can request the hardware subsystem to forcibly stop through the interface.

[0051] Abnormal Trigger Conditions and Processing Logic The hardware control subsystem monitors and responds to three types of abnormalities: Heartbeat Signal Interruption: Recognize the continuity of heartbeat data frames, when the heartbeat signal fails, it is considered that the system software is abnormal, and the independent protection logic is started.

[0052] Protection Stop Button Trigger: When the physical emergency button of the hardware interface is pressed, the motion control is immediately stopped to ensure that the actuator enters the protection state.

[0053] Real-time Self-test Abnormality: The hardware subsystem performs real-time self-test to identify abnormalities of the actuator or other components (such as power supply abnormalities, motor overload, etc.), triggering the protection stop.

[0054] Independent Protection Logic When the system software fails, the hardware control subsystem provides independent protection mechanisms as follows: Acoustic and Light Alarm Prompt: Provides independent user interaction means (such as LED flashing or buzzer prompt) to enable users to identify abnormal states even when the system software fails.

[0055] Actuator Power Control: Provides an effective hardware way to cut off actuator power to avoid unintended movement of the robot arm.

[0056] Emergency Power-off Function: Users can manually force power-off through the hardware emergency power-off interface (such as a button) to ensure device safety.

[0057] Abnormal Scenario Examples The hardware control subsystem triggers protection according to the following scenarios: Heartbeat Mechanism Failure: If the system software does not send heartbeat signals as expected, the hardware subsystem will judge that the system software is abnormal and suspend the actuator.

[0058] Actuator Power Abnormality: When current or voltage abnormalities are detected, the hardware will forcibly cut off power and trigger protection.

[0059] User Manual Operation: Users trigger protection stop or emergency power-off operation through physical buttons.

[0060] The design features of the hardware control subsystem include: Redundant design, dual-channel communication design (such as one-to-one control and multi-to-one monitoring) ensures that the system can maintain basic functions when the main channel fails. Power cut-off design is separated from system software to avoid single-point failure.

[0061] High real-time performance, real-time monitoring of heartbeat mechanism enables hardware subsystems to quickly identify abnormalities and reduce response delay.

[0062] Modularity and independence, independent hardware control board allows subsystems to operate independently of system software, reducing the impact of system failure.

[0063] III. Motion Control Subsystem The motion control subsystem is one of the core modules of the microsurgical system, responsible for controlling and executing mechanical movements. Its main goal is to accurately control mechanical movements, implement safety protection logic, and collaborate with other subsystems in abnormal situations to ensure system safety.

[0064] Here is a detailed analysis of the motion control subsystem: 1. Core functions (1) User motion control input Accept motion instructions from the user interaction subsystem. Instructions include: start, pause, stop, resume, speed adjustment, path planning, etc. Instruction input forms: touch screen, buttons, voice or other user interface operations.

[0065] (2) Motion algorithm execution Use advanced motion planning algorithms (such as interpolation algorithms, inverse kinematics, etc.) to ensure smooth and accurate movement of the robotic arm. Interpolation function is to divide complex path into continuous small steps. Error correction refers to real-time calculation of the deviation between target position and actual position and compensation.

[0066] (3) Motion execution Control actuators (such as servo motors) to move according to instructions and planning, issue control instructions through real-time communication protocols (such as TCP / IP, CAN, etc.), and monitor actuator state information (position, speed, torque, etc.).

[0067] (4) State feedback Provide real-time feedback of actuator and motion state, including current position, speed, and running state of the robotic arm. Report abnormal states (such as overload, temperature anomaly) to the system software.

[0068] Exception handling mechanism (1) System-level exception handling Interact with system software: when the system software detects an exception, the motion control subsystem receives a stop or pause instruction, immediately stops the current motion and locks the actuator.

[0069] (2) Subsystem internal exception handling When the subsystem self-check finds an exception, different responses are triggered according to different situations. When the end effector fails, no protection stop is triggered, and only abnormal data is reported to the system software. When the robot arm or controller fails, the motion is paused, the effector is locked, and further instructions from the system software are awaited. When the communication is abnormal, if the communication with the system software is interrupted, all motion is stopped and the protection state is entered.

[0070] (3) Heartbeat mechanism Heartbeat communication is maintained with the system software. If the heartbeat fails (the system software does not respond), the protection stop is immediately triggered. The heartbeat mechanism can prevent system out-of-control caused by software-level exceptions.

[0071] Design features (1) Instruction timeout protection The effector is controlled by persistent instructions. If a new instruction is not received within the set timeout period, the motion is automatically paused. After the pause is explicitly released, new instructions can be executed to prevent misoperation.

[0072] (2) Dual-channel communication The control part and the monitoring part are designed separately. The control channel is used for one-to-one instruction issuance, and the monitoring channel supports multi-to-one monitoring for state feedback and exception monitoring.

[0073] (3) Effector locking mechanism After the protection stop is triggered, the effector is not directly powered off, but the motor holding force is maintained to ensure that the robot arm maintains the current position.

[0074] (4) Data synchronization Bidirectional synchronization is maintained with the system software. The state and parameters are updated in real time through the API, supporting multi-layer state analysis. Even if the system software fails, the state can be directly read by the hardware control subsystem.

[0075] Protection logic of the motion control subsystem The protection mechanism of the motion control subsystem in abnormal situations includes: (1) When the system layer is abnormal The system software calls the subsystem API after determining the exception, and performs the following operations: Pause the current action, lock the effector to maintain the current position, disable further instruction input, and wait for system recovery.

[0076] (2) When the subsystem is internally abnormal Different measures are taken according to different exception types. When the effector fails, data is reported but no stop is triggered. When the controller fails, the motion is stopped and the system layer is further processed.

[0077] (3) When communication fails If the heartbeat with the system software is interrupted, perform the following steps: Terminate the current action, lock the control terminal to prevent new input, and use audio and visual prompts (such as LED flashing or buzzer) to remind the user.

[0078] (4) Automatic recovery logic After the abnormal condition is removed, normal operation is restored through system software instructions.

[0079] Key points of actuator design (1) Motion control Continuous instruction mechanism: The continuity of the instruction determines the action of the actuator; the actuator automatically enters the pause state after timeout.

[0080] (2) Exception handling When the communication link is lost, the actuator stops moving and locks until manually unlocked after communication is restored.

[0081] (3) Redundant design Provides dual-channel communication interface to ensure that some functions can be maintained when a single channel fails.

[0082] (4) Energy retention When the protection stop is triggered, the power is not cut off but the movement is stopped to ensure that the robot arm maintains the current posture and avoid unexpected falls due to power outages.

[0083] Collaboration with other subsystems (1) With system software Receive user commands and system-level abnormal signals, and implement control through API; provide information such as motion status and hardware status to assist system-level decision-making.

[0084] (2) With the hardware control subsystem The motion control subsystem and hardware control subsystem each maintain heartbeats with the system software. Coordinated by the system software's heartbeat mechanism, these two subsystems operate independently and collaborate with each other to form a complete safety protection mechanism. The motion control subsystem also provides real-time actuator status and supports hardware protection logic.

[0085] (3) User interaction subsystem Receive user instructions and execute them, feeding back real-time status data for user reference. In abnormal situations, it cooperates with the user interaction subsystem to issue alarm prompts.

[0086] In summary, the motion control subsystem is the core module of the microsurgery system for achieving precision motion. It can ensure the accurate motion control of the surgical robot arm. In abnormal situations, it can trigger a protective stop through software and hardware to ensure safety. It also works with other subsystems through the API to form redundant protection. It runs independently and maintains dynamic communication with the system software, which enhances reliability.

[0087] 4. Implementation of the Heartbeat Mechanism Motion control subsystem heartbeat: Maintains two-way communication with the system software. The system software sends heartbeat queries, and the motion control subsystem responds. If the motion control subsystem fails to respond in a timely manner, the system software triggers a protective stop or stop motion command.

[0088] The hardware control subsystem heartbeat maintains independent, two-way communication with the system software. The system software periodically sends heartbeat signals, and the hardware control subsystem responds within the specified time. If the hardware control subsystem heartbeat is interrupted, the system enters hardware protection mode, cutting off power to the actuator or triggering an audible or visual alarm.

[0089] There is no direct heartbeat dependency between the motion control subsystem and the hardware control subsystem, but a complete protection logic is formed through the coordination of system software.

[0090] In summary, the motion control subsystem and the hardware control subsystem independently maintain a heartbeat mechanism with the system software, each monitoring its own status and providing feedback to the system software.

[0091] 5. About Hardware Control Subsystem and Motion Control Software Because the hardware control subsystem and motion control software have different responsibilities for monitoring the system hardware status, a redundant protection mechanism is formed in the architectural design. This design is intended to enhance system reliability and security and avoid uncontrollable risks caused by single point failures.

[0092] Differences in division of responsibilities (1) Hardware status monitoring of motion control software Key monitoring areas: The status of the motion control subsystem's hardware peripherals (e.g., actuators, sensors, and communication modules). Focus is on real-time motion-related data and functional status, such as actuator trajectory, speed, and position. Sensor feedback, such as torque, inertia, and temperature, command execution validity, and communication status.

[0093] Scenario for triggering a protective stop: If an abnormality is detected within the subsystem (such as actuator overload or sensor failure), the current motion will be proactively stopped to protect the equipment and patients.

[0094] (2) Hardware status monitoring of the hardware control subsystem Key monitoring scope: The hardware running status of the entire system, including but not limited to motion control hardware peripherals. The monitoring level is more bottom-level, covering the electrical status of the entire system, such as power supply voltage, current monitoring, hardware module health status, and self-checking results of key components.

[0095] Scenarios that trigger protection stop: Discovering abnormalities related to system electricity or hardware (such as unstable power supply, hardware subsystem communication interruption, actuator failure, etc.), and triggering protection stop in a timely manner. When the motion control software fails, the hardware control subsystem can take over the hardware state monitoring and independently trigger the protection stop.

[0096] Necessity of redundancy protection Safety guarantee in high-risk scenarios: Any loss of control or abnormality of the actuators (such as mechanical arms) in a microsurgical system can cause serious harm to the patient.

[0097] If we simply rely on motion control software to monitor hardware status, once the motion control software itself fails (such as logic errors, crashes, or communication interruptions), the system will not be able to effectively stop the movement.

[0098] The hardware control subsystem, as an independent module, provides a second line of defense, ensuring that even if the motion control software fails, it can detect abnormalities and protect the device.

[0099] Avoiding single-point failure: Software-level abnormalities can cause the state judgment of the motion control subsystem to fail, and the independent monitoring and protection function at the hardware level can avoid the failure of the protection mechanism due to software failure.

[0100] Unique advantages of the hardware control subsystem (1) Independence and immediate response capability The hardware control subsystem is a physical hardware unit independent of the software modules of the motion control subsystem, with independent logic judgment capability.

[0101] Its real-time performance relies on hardware design rather than software logic, with faster and more stable response speed.

[0102] (2) Hardware self-checking and bottom-level protection The hardware control subsystem can monitor the bottom-level status of hardware operation (such as power supply and connection status), which is not directly perceivable by the motion control software.

[0103] In the event of hardware power supply interruption, hardware module failure, etc., the hardware control subsystem can first cut off the power supply or trigger the protection stop.

[0104] Key scenarios for redundancy design The following scenarios show the necessity of the synergy between the two: Motion control software operates normally: The motion control software can detect motion hardware anomalies and trigger a protective stop. The hardware control subsystem acts as a backup monitoring system, providing underlying data support.

[0105] Motion control software failure: The hardware control subsystem detects software failure through heartbeats and immediately activates protection logic to suspend actuator motion to ensure system safety.

[0106] Abnormal power supply or hardware failure: If the hardware power supply or communication is abnormal, the hardware control subsystem can directly cut off the power supply or provide an alarm without relying on the intervention of the motion control software.

[0107] Comprehensive system anomaly: If multiple subsystems fail (such as the motion control and user interaction modules fail at the same time), the hardware control subsystem can directly complete the protective stop through hardware means.

[0108] In summary, through the coordinated monitoring of the hardware control subsystem and motion control software, the motion control software focuses on real-time and motion-related high-level logic, while the hardware control subsystem is responsible for low-level hardware monitoring as a redundant protection layer.

[0109] This dual-level monitoring design is particularly important in high-risk scenarios, as it can minimize safety hazards in abnormal situations and ensure the safety and reliability of the microsurgery system.

[0110] 6. About Actuators Actuators are key components of the motion control subsystem, directly responsible for implementing mechanical motion. Their core objective is to accurately, stably, and responsively execute motion commands issued by the system while also providing safety protection in abnormal situations.

[0111] Main functions of the actuator (1) Exercise execution Receives instructions from the motion control subsystem and controls the robot's motion according to a predetermined trajectory or posture. Motion parameters include position, velocity, and torque.

[0112] (2) Status feedback Monitor its own operating status in real time and provide key data to the motion control subsystem and system software: motor status (current, temperature, speed, etc.), position information (feedback from position encoder), and load conditions (force sensor detection).

[0113] (3) Security protection When a protection stop is triggered, the system stops motion but maintains the motor's holding force to maintain the current posture. In the event of communication interruption, timeout, or abnormality detection, the system automatically enters a locked state to prevent accidental movement.

[0114] (4) Bidirectional communication Provide control and monitoring channels: Control channel receives motion control commands (such as start, stop, adjust). The monitoring channel feeds back real-time status and allows the system to monitor the status.

[0115] Design points of the actuator (1) Continuous command mechanism The actuator only runs when it continuously receives commands, preventing accidental operation: If the command interval exceeds the timeout, the actuator will automatically enter a suspended state. In the suspended state, new commands can only be received by explicitly releasing the suspension.

[0116] (2) Communication validity check The actuator maintains a connection with the motion control subsystem through a dual communication interface: If the control channel is disconnected, the actuator automatically stops the current action and locks. After restoring communication, new commands can only be executed by manually unlocking.

[0117] (3) Redundant communication design Dual communication interface: The control part is a one-to-one dedicated channel to ensure the independence and real-time nature of command transmission. The monitoring part supports multiple-to-one connection for broadcasting status information to other modules.

[0118] (4) Energy retention capability After a protection stop trigger, the actuator does not directly power off, but retains the motor's holding force to avoid unexpected mechanical arm drops. This design is particularly important to prevent accidental injuries caused by mechanical arm movement during surgery.

[0119] (5) Priority of motion commands Support for priority scheduling of motion commands: Protection commands are always prioritized, such as stop and suspend commands always taking precedence over ordinary motion commands. Recovery command conditions: In the protection state, only after the exception is resolved can the motion be reactivated.

[0120] Exception handling logic The actuator's behavior in the following exceptional situations: (1) Communication interruption When communication with the motion control subsystem fails, immediately stop the current motion. The locked state maintains the motor's posture until communication is restored and an unlock command is received.

[0121] (2) Timeout mechanism If the command interval exceeds the set timeout, the actuator automatically suspends and waits for an explicit recovery command, preventing system loss of control due to long periods of non-updated commands.

[0122] (3) Internal failure When internal hardware exceptions (such as overload, over-temperature) are detected, the motion control subsystem is reported of the exception, and automatically enters a protection state. Depending on the type of exception, it is decided whether to allow subsequent recovery.

[0123] Protection mechanism of the actuator (1) Software protection Interact with the motion control subsystem and system software, pause the action when protection stop triggers: immediately stop the motion. Keep motor torque: maintain the current position.

[0124] (2) Hardware protection Built-in hardware logic can directly stop the action in the following cases: communication interruption: the hardware layer detects disconnection and immediately pauses. Hardware button trigger: stop the action when the protection stop button is activated.

[0125] (3) Surgical scene specialization design For the design of microsurgery scenes, the actuator needs to ensure: vibration-free start / stop: smooth motion to avoid introducing additional micro-disturbances. Exception state retention: when an exception is triggered, avoid the mechanical arm from falling or losing control due to power failure.

[0126] Collaboration of the actuator with other modules (1) With the motion control subsystem, receive motion instructions and feedback running status.

[0127] The motion control subsystem implements the following functions through API: action start / pause / stop, data reading (such as position, status, etc.), parameter setting (such as speed, torque limit, etc.).

[0128] (2) With the hardware control subsystem The hardware control subsystem can directly trigger the actuator protection through physical interfaces (such as emergency buttons). When the system software or motion control subsystem fails, the hardware control subsystem takes over the state monitoring of the actuator.

[0129] (3) With the system software Provide redundant data paths to ensure that the system software can still read the actuator status when the motion control subsystem fails.

[0130] The beneficial effects of the present application are that through the protection stop mechanism combining software and hardware, the system can respond in time and ensure rapid stop of motion when an exception occurs, avoiding the response delay and falling problem in traditional methods, significantly improving the safety during the surgical process. This method ensures the reliability of the microsurgery robot in complex environments, can quickly respond to system exceptions, and effectively protects patient safety. DETAILED DESCRIPTION

[0131] The present application will be further described in conjunction with specific embodiments: Embodiment: A microsurgical robot protective stop system includes system software and subsystems, wherein the subsystems include a hardware control subsystem, a motion control subsystem, and a user interaction subsystem. The system software is used to coordinate the operation of the subsystems, receive control instructions from the user interaction subsystem, and monitor the status of the hardware control subsystem and the motion control subsystem through a heartbeat mechanism to determine whether the system is in normal operation. The hardware control subsystem, including the hardware control board and related hardware interfaces, is responsible for providing feedback on the hardware operating status to the system software through a heartbeat mechanism, providing hardware anomaly monitoring, and when an anomaly is detected, cutting off the actuator power supply through an independent protection stop mechanism, and providing a manual emergency power-off operation interface; The above-mentioned motion control subsystem includes an actuator and a motion control module. The motion control subsystem communicates with the system software and is responsible for controlling the movement of the actuator according to system instructions. It also pauses or terminates the movement when an abnormality occurs in the system software or other subsystems to prevent the actuator from moving unexpectedly. The user interaction subsystem is used to receive control commands input by the user and transmit them to related subsystems through system software, provide visual feedback of the system operation status, and issue an alarm through sound and light prompts in abnormal situations.

[0132] The above-mentioned microsurgical robot protection stop system is equipped with a protection stop mechanism, including automatic triggering and manual triggering. The automatic triggering mechanism automatically switches to the protection stop mode by the system software according to abnormal signals. The above-mentioned abnormal signals include hardware abnormalities, motion control abnormalities and system software abnormalities themselves. The above-mentioned manual triggering mechanism is triggered by the user interaction subsystem, disabling the actuator and suspending the action of the motion control system.

[0133] The above-mentioned microsurgical robot protection stop system is equipped with a heartbeat mechanism. A bidirectional heartbeat mechanism is maintained between the above-mentioned system software and the hardware control subsystem and motion control subsystem to ensure the real-time and reliability of the system. When the heartbeat signal is lost, the protection stop mechanism is automatically started.

[0134] The abnormality detection and processing process of the above-mentioned microsurgical robot protection stop system includes the system software coordinating the subsystems to take measures when a system, hardware or motion control abnormality occurs. The above-mentioned measures include pausing the actuator, executing forced power cut-off through the hardware control subsystem, or providing alarm information through the user interaction subsystem to ensure patient safety.

[0135] The above hardware control subsystem also includes a self-check function, which performs a self-check when the system is turned on to ensure that the hardware is in a normal state.

[0136] The above-mentioned motion control subsystem communicates with the system software through the API. When an abnormal state is detected, it automatically sends a stop signal and locks the actuator to prevent unexpected actions.

[0137] The above-mentioned protection stop mechanism further includes executing forced power removal through the hardware control subsystem when the system software detects a failure of the hardware or motion control subsystem, ensuring that the motion is safely stopped under abnormal circumstances to prevent danger.

[0138] The above system software also has the ability to determine whether to resume normal operation based on the system status, and can restore from the protection stop state to the normal working state when the conditions are met.

[0139] The above-mentioned bidirectional heartbeat mechanism includes a timed signal exchange between the system software and the hardware control subsystem and motion control subsystem. The system software periodically sends heartbeat signals to the hardware control subsystem and the motion control subsystem, and receives their feedback heartbeat response signals to ensure the normal operation of each subsystem; if the system software does not receive the feedback heartbeat signal, it automatically triggers the protection stop mechanism, suspends the actuator movement and cuts off the power supply to ensure system safety.

[0140] The above recovery conditions include: when the system software detects that the hardware control subsystem and the motion control subsystem have resumed normal operating status and there are no abnormal signals, the system software determines whether to restore to normal working status according to preset rules; the above preset rules include: confirming that the heartbeat signals of all subsystems are normal, the hardware self-test has passed, the actuators of the motion control subsystem are in a safe state, and the communication between the system software and the user interaction subsystem has returned to normal. When the above conditions are met, the system software gradually enables the actuators by coordinating the subsystems and releases the pause state of the motion control subsystem, so that the system resumes normal operation.

[0141] For the present invention, the protection stop mechanism includes the following typical scenarios: 1. When the system is operating normally, user intervention or unexpected abnormality triggers a protection stop and pauses the actuator movement Working process: Under normal operating conditions, the system maintains stable communication and heartbeat mechanisms with each subsystem (hardware control subsystem, motion control subsystem, and user interaction subsystem). When an abnormal situation occurs (for example, a user triggers a control command, or the system detects any unexpected anomaly), the protective stop mechanism is activated.

[0142] The system software will capture abnormal signals (such as hardware failure, communication failure, etc.) through the abnormality detection module and trigger the protection stop mechanism.

[0143] The system software sends a pause command to the motion control subsystem to prohibit the actuator from moving and avoid risks to the patient caused by unexpected movement.

[0144] Principle: The system continuously monitors the status of each subsystem through the heartbeat mechanism. Once an abnormality in the system or hardware is detected, it automatically switches to the protection stop mode, ensuring that the actuator is promptly paused and the patient's safety is protected.

[0145] When the system software is abnormal, the motion control subsystem, hardware control subsystem, and user interaction subsystem fail, triggering the protection stop through their respective heartbeat mechanism failures Working process: When the system software itself has an abnormality (e.g., loss of heartbeat mechanism, loss of instructions, etc.), the system loses effective monitoring of the hardware control subsystem, motion control subsystem, and user interaction subsystem.

[0146] Due to the failure of the heartbeat signal to be normally transmitted, each subsystem will monitor the loss of the heartbeat signal and automatically enter a self-protection state, triggering the protection stop mechanism.

[0147] Each subsystem will pause the actuator's action and provide abnormal information or alarms through the user interaction subsystem to inform the operator that the system has a fault.

[0148] Principle: The core principle of the protection stop mechanism is heartbeat monitoring. When the system software cannot work normally, the hardware control subsystem and motion control subsystem will independently start the protection stop mechanism to prevent the system from losing control and causing unintended actions.

[0149] When the non-motion control subsystem software is abnormal, the system software coordinates the pause of the motion control subsystem action Working process: In this scenario, the motion control subsystem's action pause is coordinated by the system software. When a non-motion control subsystem (such as the user interaction subsystem or hardware control subsystem) has an abnormality, the system software will determine that the abnormality may affect the overall safety and immediately issue a pause command to the motion control subsystem.

[0150] After receiving the pause command, the motion control subsystem pauses the motion of the actuator, avoiding any unsafe actions.

[0151] Principle: The system software determines whether to trigger the protection stop based on pre-set abnormality monitoring rules, ensuring that even if a non-motion control subsystem has an abnormality, it can still affect the motion control subsystem in time, ensuring the overall safety of the system.

[0152] When the motion control subsystem itself has an abnormality, other than the end effector, the other fault handling is to pause the action Working process: When the motion control subsystem itself has a fault (such as communication interruption, control algorithm abnormality, etc.), the system will stop the motion control command through the system software coordination.

[0153] If a fault occurs in a non-end effector component, the system will suspend the entire motion control system. When the end effector (such as a robotic arm) itself fails, the system may not trigger a protective stop, but only notify the system software through an exception signal for further processing.

[0154] Principle: Through the system's hierarchical fault handling mechanism, when non-critical components (such as non-end parts of the motion control subsystem) encounter exceptions, only the relevant part of the motion is suspended, avoiding affecting other normally running modules, and preventing dangerous situations caused by loss of control or failure of the robotic arm.

[0155] System software bypasses motion control subsystem, directly monitors the status of the effector, and uses safety mechanisms to terminate effector action when an exception occurs Working process: In some cases, the system software may bypass the motion control subsystem and directly monitor the status of the effector. In this way, even if the motion control subsystem itself cannot respond in time, the system software can still detect the exception signal by directly monitoring the effector's action and intervene in time.

[0156] If the effector encounters an exception (such as position deviation, over-limit motion, etc.), the system software will immediately send a termination instruction to force the effector to stop moving, preventing the execution of unintended actions.

[0157] Principle: This design takes advantage of the system software's direct control and monitoring of the effector to achieve the most direct and effective protective stop, ensuring that the effector can be immediately stopped and accidents can be avoided in emergency situations.

[0158] A forced power removal method is provided to implement the hardware design, and users can implement emergency power-off when the overall protective stop mechanism fails Working process: In extreme cases, if the system's multi-layer protective stop mechanism fails (for example, the system software, subsystem, or heartbeat mechanism cannot work normally), users can implement forced power removal through a manual interface (such as an emergency power-off button).

[0159] This function provides the last line of defense, ensuring that even if all automatic mechanisms fail to work, users can still manually cut off the power supply of the effector, preventing further movement that could injure the patient.

[0160] Principle: The emergency power-off interface is the last line of defense in the system, ensuring that when all automated protection measures fail, the effector power supply can still be cut off through human intervention, avoiding uncontrollable movement.

[0161] Through these six scenarios of protection mechanisms, the microsurgical robot can take appropriate protective stop measures in various abnormal situations, ensuring patient safety and reducing the risk of surgery.

[0162] It should be pointed out finally that the above only describes the preferred embodiments of the present application and is not intended to limit the present application. Although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art can make modifications to the technical solutions described in the foregoing embodiments or make equivalent replacements to some of the technical features, and any modifications, equivalent replacements, improvements, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. A microsurgery robot protection and stop system, comprising system software and subsystems, wherein the subsystems include a hardware control subsystem, a motion control subsystem, and a user interaction subsystem, characterized in that: The system software is used to coordinate the operation of each subsystem, receive control instructions from the user interaction subsystem, and monitor the status of the hardware control subsystem and motion control subsystem through a heartbeat mechanism to determine whether the system is in normal operation; The hardware control subsystem, including the hardware control board and related hardware interfaces, is responsible for feeding back the hardware operating status to the system software through a heartbeat mechanism, providing hardware anomaly monitoring, and when an anomaly is detected, cutting off the actuator power supply through an independent protection stop mechanism, and providing a manual emergency power-off operation interface; The motion control subsystem includes an actuator and a motion control module. The motion control subsystem communicates with the system software and is responsible for controlling the actuator's movements according to system instructions. It also pauses or terminates the movement when an abnormality occurs in the system software or other subsystems to prevent the actuator from moving unexpectedly. The user interaction subsystem is used to receive control instructions input by the user and transmit them to related subsystems through system software, provide visual feedback of the system operation status, and alarm through sound and light prompts in abnormal situations.

2. A microsurgery robot protection and stopping system according to claim 1, characterized in that: A protective stop mechanism is provided, including automatic triggering and manual triggering. The automatic triggering mechanism automatically switches the system software into protective stop mode according to abnormal signals, and the abnormal signals include hardware abnormalities, motion control abnormalities and system software abnormalities. The manual triggering mechanism is triggered by the user interaction subsystem, disabling the actuator and suspending the action of the motion control system.

3. The microsurgery robot protection and stopping system according to claim 1, characterized in that: A heartbeat mechanism is provided, and a bidirectional heartbeat mechanism is maintained between the system software and the hardware control subsystem and the motion control subsystem to ensure the real-time performance and reliability of the system. When the heartbeat signal is lost, a protection stop mechanism is automatically started.

4. The microsurgery robot protection and stopping system according to claim 1, characterized in that: The abnormality detection and handling process includes the system software coordinating the subsystems to take measures when a system, hardware or motion control abnormality occurs. The measures include pausing the actuator, forcibly cutting off the power through the hardware control subsystem, or providing alarm information through the user interaction subsystem to ensure patient safety.

5. A microsurgery robot protection and stopping system according to any one of claims 1 or 4, characterized in that: The hardware control subsystem also includes a self-check function, which performs a self-check when the system is turned on to ensure that the hardware is in a normal state.

6. A microsurgery robot protection and stopping system according to any one of claims 1 or 4, characterized in that: The motion control subsystem communicates with the system software through the API. When an abnormal state is detected, it automatically sends a stop signal and locks the actuator to prevent unexpected movements.

7. The microsurgery robot protection and stopping system according to claim 2, characterized in that: The protection stop mechanism further includes executing forced power removal through the hardware control subsystem when the system software detects a failure of the hardware or motion control subsystem, thereby ensuring safe stopping of the motion in abnormal circumstances and preventing danger.

8. A microsurgery robot protection and stopping system according to any one of claims 1 or 4, characterized in that: The system software also has the ability to determine whether to resume normal operation based on the system status, and can resume normal operation from a protection stop state when conditions are met.

9. The microsurgery robot protection and stopping system according to claim 3, characterized in that: The bidirectional heartbeat mechanism includes a timed signal exchange between the system software and the hardware control subsystem and motion control subsystem. The system software periodically sends heartbeat signals to the hardware control subsystem and motion control subsystem, and receives their feedback heartbeat response signals to ensure the normal operation of each subsystem; if the system software does not receive the feedback heartbeat signal, it automatically triggers the protection stop mechanism, suspends the actuator movement and cuts off the power supply to ensure system safety.

10. The microsurgery robot protection and stopping system according to claim 8, characterized in that: The recovery conditions include: when the system software detects that the hardware control subsystem and the motion control subsystem have returned to normal operating status and there are no abnormal signals, the system software determines whether to return to normal operating status according to preset rules; the preset rules include: confirming that the heartbeat signals of all subsystems are normal, the hardware self-test has passed, the actuators of the motion control subsystem are in a safe state, and the communication between the system software and the user interaction subsystem has returned to normal. When the above conditions are met, the system software gradually enables the actuators by coordinating the subsystems and releases the pause state of the motion control subsystem, so that the system returns to normal operation.