Method for grabbing control authority of surgical arms, electronic device, storage medium and product

Abstract

The application discloses a surgical arm control right grabbing method, an electronic device, a storage medium and a product, and relates to the technical field of surgical robots. In a case where it is determined that there are at least two doctors' consoles in an activated state in a target surgical robot system, and a target doctor's console that sends a surgical arm switching instruction has enabled a grabbing right, a surgical arm switching instruction is received, and a target surgical arm is determined. When the target surgical arm is a grabbable instrument arm, the surgical arm switching instruction is determined as a control right grabbing event. Based on the control right grabbing event, the control right of the target surgical arm is transferred to the target doctor's console. After the control right is transferred, an operation unit in the target doctor's console that is used to trigger the surgical arm switching instruction is mapped to the target surgical arm in a master-slave control mode. The scheme can automatically transfer the control right of the surgical arm, and can help ensure that a key instrument arm can be timely taken over in an emergency or high-risk surgical scene.

Description

Technical Field

[0001] This invention relates to the field of surgical robot technology, and in particular to a method for seizing control of a surgical arm, an electronic device, a storage medium, and a product. Background Technology

[0002] A surgical robotic system is a medical device that enables surgeons to remotely and precisely control the device through a master-slave teleoperation architecture. It typically consists of a control console (master) at the surgeon's end and a robotic arm execution unit (slave) at the patient's end. The surgeon issues commands on the control console via handgrips, foot pedals, or voice input devices. The system maps these commands in real time and drives multi-degree-of-freedom surgical instruments at the patient's end to perform delicate movements such as tissue cutting, suturing, and traction. Such systems are widely used in urology, gynecology, cardiothoracic surgery, and other fields, significantly improving the stability, minimally invasiveness, and accessibility of surgeries.

[0003] In multi-doctor collaborative surgical robot systems, multiple doctor consoles can simultaneously access and control different surgical arms to improve surgical efficiency and collaborative flexibility. However, when multiple consoles need to dynamically switch control of the same surgical arm, how to safely and efficiently transfer control becomes a key technical issue to ensure surgical continuity and patient safety.

[0004] Currently, a "request-confirmation" mechanism is typically used. This means that after the taking over physician's console initiates a request, it must be confirmed and approved by the current primary physician's console before the system transfers control and establishes a new master-slave control mapping. During this process, the target surgical arm remains in its original state or is frozen and waiting. This approach is prone to control switching blockages in emergency or high-risk surgical scenarios due to response delays or rejections, failing to meet the need for rapid and reliable takeover of critical surgical arms, potentially delaying surgery or even endangering patient safety. Summary of the Invention

[0005] This invention provides a method, electronic device, storage medium, and product for seizing control of a surgical arm, enabling automatic transfer of control of the surgical arm. This helps ensure timely takeover of critical surgical arms in emergency or high-risk surgical scenarios, preventing delays in surgical procedures or endangering patient safety due to delayed control switching.

[0006] According to one aspect of the present invention, a method for seizing control of a surgical arm is provided, the method comprising:

[0007] If it is determined that there are at least two active doctor consoles in the target surgical robot system, and the target doctor console that issued the surgical arm switching command has enabled the preemption permission, the surgical arm switching command is received, and the target surgical arm to which the surgical arm switching command is directed is determined.

[0008] When the target surgical arm is a grabbable instrument arm controlled by another active reference physician console, the surgical arm switching command is identified as a control grab event.

[0009] Based on the control takeover event, control of the target surgical arm is transferred from the reference doctor's console to the target doctor's console;

[0010] After the transfer of control is completed, a master-slave control mapping is established between the operation unit in the target doctor's console used to trigger the surgical arm switching command and the target surgical arm.

[0011] According to another aspect of the present invention, a device for seizing control of a surgical arm is provided, the device comprising:

[0012] The first determining module is used to receive the surgical arm switching instruction and determine the target surgical arm to which the surgical arm switching instruction points when there are at least two active doctor consoles in the target surgical robot system and the target doctor console that issued the surgical arm switching instruction has enabled the preemption permission.

[0013] The second determining module is used to determine the surgical arm switching command as a control takeover event when the target surgical arm is a grabbable instrument arm controlled by another active reference physician console.

[0014] The control transfer module is used to transfer control of the target surgical arm from the reference doctor's console to the target doctor's console based on the control takeover event;

[0015] The control mapping establishment module is used to establish a master-slave control mapping between the operation unit in the target doctor's console used to trigger the surgical arm switching command and the target surgical arm after the control transfer is completed.

[0016] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising:

[0017] At least one processor;

[0018] and a memory communicatively connected to the at least one processor;

[0019] The memory stores a computer program that can be executed by the at least one processor, which is then executed by the at least one processor to enable the at least one processor to perform the surgical arm control takeover method according to any embodiment of the present invention.

[0020] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the surgical arm control control takeover method according to any embodiment of the present invention.

[0021] According to another aspect of the present invention, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the method for seizing control of the surgical arm as described in any embodiment of the present invention.

[0022] The technical solution of this invention, by determining that there are at least two active doctor consoles in the target surgical robot system, and that the target doctor console issuing the surgical arm switching command has enabled the preemption permission, receives the surgical arm switching command and determines the target surgical arm to which the surgical arm switching command points; when the target surgical arm is a preemptible instrument arm controlled by another active reference doctor console, the surgical arm switching command is determined as a control preemption event; based on the control preemption event, the control of the target surgical arm is transferred from the reference doctor console to the target doctor console; after the control transfer is completed, a master-slave control mapping is established between the operation unit in the target doctor console used to trigger the surgical arm switching command and the target surgical arm, which can realize the automatic transfer of control permission for the surgical arm. This helps to ensure timely takeover of critical instrument arms in emergency or high-risk surgical scenarios, avoiding delays in surgical progress or endangering patient safety due to permission switching delays.

[0023] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

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

[0025] Figure 1 This is a flowchart of a method for seizing control of a surgical arm according to Embodiment 1 of the present invention;

[0026] Figure 2 This is a flowchart of a method for seizing control of a surgical arm according to Embodiment 2 of the present invention;

[0027] Figure 3This is a schematic diagram of a device for seizing control of a surgical arm according to Embodiment 3 of the present invention;

[0028] Figure 4 This is a schematic diagram of the structure of an electronic device that implements the method for seizing control of the surgical arm according to an embodiment of the present invention. Detailed Implementation

[0029] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0030] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0031] Example 1

[0032] Figure 1 This is a flowchart of a method for seizing control of a surgical arm according to Embodiment 1 of the present invention. This embodiment is applicable to situations where the working authority of a surgical arm in a surgical robot system needs to be forcibly transferred. This method can be executed by a device for seizing control of the surgical arm, which can be implemented in hardware and / or software. This device can be configured in electronic devices such as computers, servers, or tablet computers. Figure 1 As shown, the method includes:

[0033] Step 110: If at least two doctor consoles are active in the target surgical robot system, and the target doctor console that issued the surgical arm switching command has enabled the preemption permission, receive the surgical arm switching command and determine the target surgical arm to which the surgical arm switching command is directed.

[0034] The target surgical robot system can be any surgical platform, which may include multiple doctor consoles. Each doctor console can be a remote console or a local console. For example, it may include two local doctor consoles, or one local doctor console and one remote doctor console; this embodiment does not limit the specific configuration. Each doctor console can communicate with the patient surgical platform to control the movements of the surgical arms within the patient surgical platform.

[0035] In this context, an active doctor's console can be one that has successfully logged into the target surgical robot system, completed initialization, and whose operating unit (e.g., the main hand) is operable. For example, a console that is powered on, communicates normally with the main control computer, displays an HMI interface ready, and is not in sleep or offline mode can be considered to be in an active state.

[0036] Surgical arm switching commands can be control signals issued by the physician through the target physician control console interface (such as buttons, foot switches, or voice commands) to switch control of a specific surgical arm to this control console. For example, when the physician presses the physical button on the control panel labeled "Transfer Instrument Arm 3," the system generates a switching command containing the target arm identifier.

[0037] The target surgical arm is the surgical arm to be taken over as explicitly specified in the surgical arm switching command.

[0038] In one optional implementation of this embodiment, it can be detected whether at least two active doctor consoles exist in the target surgical robot system. When one of the doctor consoles (referred to as the target doctor console) issues a surgical arm switching command, it is further determined whether the target console has enabled preemption permission, which indicates that it is authorized to initiate a transfer of control without the other party's confirmation. If preemption permission is enabled, the surgical arm switching command is received, and the target surgical arm it refers to is parsed out. For example, the switching command may contain a unique identifier of the target surgical arm (e.g., ARM_02), based on which the specific instrument arm to be taken over can be determined.

[0039] Optionally, in this embodiment, the surgical robot control system continuously maintains a console status table, recording the connection status, activation flag, and permission configuration of all connected consoles. When the system detects that the activation status fields of at least two consoles are both true, it enters a preemptive monitoring mode. At this time, if any console issues a surgical arm switching command, it first reads the permission configuration data of that console to verify whether its preemptive permission is enabled; if not enabled, the command is discarded and optionally a permission-only prompt is returned to the user. If the permission is valid, the data payload of the command is parsed, the target surgical arm identifier is extracted, and the internal resource mapping table is used to confirm that the surgical arm is currently being controlled by another active console.

[0040] For example, in a laparoscopic surgery performed collaboratively by a surgeon and an assistant, a four-arm surgical robot system is simultaneously connected to two active surgeon consoles: the surgeon's console A and the assistant's console B. At this time, the assistant's console B is controlling instrument arm 3 for tissue traction. If sudden bleeding occurs during the operation, the surgeon needs to immediately take over the instrument arm to perform hemostasis. The surgeon presses the dedicated takeover button for arm 3 on console A, issuing a surgical arm switching command. First, it is confirmed that console A has been granted takeover authority before the operation, and that at least two consoles are currently active in the system. Further, the command is parsed to determine that its target is instrument arm 3, and it is verified that this arm is currently controlled by another active console (i.e., console B). After all the above conditions are met, the command is received, and the target surgical arm is confirmed to be instrument arm 3, thus triggering the control takeover process. During this process, there is no need to send a request to the assistant's console or wait for its confirmation, ensuring that the surgeon can gain control of the critical instrument arm within milliseconds and respond promptly to emergencies.

[0041] Step 120: When the target surgical arm is a grabbable instrument arm controlled by another active reference physician console, the surgical arm switching command is identified as a control grab event.

[0042] The reference doctor's console can be the console that is currently controlling the target surgical arm; being active indicates that the console has completed the system readiness process (such as login authentication, normal communication, and master hand enable), and can send control commands and receive feedback in real time.

[0043] It should be noted that in this embodiment, not all arms can be resuscitated; for example, arms performing emergency braking, in a fault-locked state, or used for critical life support may be marked as non-resuscitable. In this embodiment, whether an arm can be taken over can be determined by configuration parameters or real-time status. For example, a normal needle-holding arm is usually set to resuscitable, while an arm connected to an electrocautery device and performing hemostasis may be temporarily set to non-resuscitable for a specific period of time.

[0044] A control takeover event is a special event type defined in this embodiment, indicating that a legitimate takeover request that meets all the takeover conditions has been confirmed. Once this event is identified, a forced transfer process (such as disconnecting the original mapping and establishing a new mapping) will be initiated, eliminating the need for manual intervention.

[0045] Optionally, in this embodiment, after receiving a surgical arm switching command and identifying the target surgical arm it points to, it further determines whether the target surgical arm is a grabbable instrument arm controlled by another active reference surgeon's console. For example, in multi-surgeon collaborative surgery, if the assistant console is operating a regular needle-holding arm (marked as grabbable), and the surgeon's console issues a switching command for that arm, then after confirming that the needle-holding arm is indeed controlled by the active assistant console and meets the grabbable conditions, the switching command is identified as a control grabb event, thereby initiating an automatic permission transfer process that does not require confirmation from the other party. This ensures that the grabbable behavior is triggered only when the target is clear, the state is safe, and the subject is legitimate, effectively balancing operational efficiency and surgical safety.

[0046] In practice, the surgical robot control system queries the internally maintained console status table and surgical arm resource mapping table to determine the received surgical arm switching command: it extracts the identifier of the target surgical arm from the command and confirms in the surgical arm resource mapping table whether the surgical arm is currently controlled by another doctor's console; if it is indeed controlled by another console, it further checks in the console status table whether the activation flag of that console is true, and simultaneously checks whether the grabbearing attribute of the target surgical arm is true; the grabbearing attribute flag is dynamically set according to real-time safety conditions such as whether the surgical arm is in an emergency stop state, whether it is performing a high-risk operation, or whether it is connected to critical life support equipment; only when the target surgical arm is controlled by an active reference doctor's console and its grabbearing attribute is true is the surgical arm switching command determined as a control grabbing event, and the subsequent permission transfer process is triggered.

[0047] Step 130: Based on the control takeover event, transfer control of the target surgical arm from the reference doctor's console to the target doctor's console.

[0048] Optionally, in this embodiment, after determining the surgical arm switching command as a control takeover event, the master-slave data flow between the reference doctor's console and the target surgical arm can be disconnected. For example, this can include blocking the master hand command transmission path and stopping the feedback of the target surgical arm's status information. Further, the binding relationship between the target surgical arm and the reference doctor's console is cleared in the surgical arm resource mapping table, and the control ownership of the surgical arm is updated to the target doctor's console. Then, the current joint angle and end-effector pose of the target surgical arm are read, and the pose data is written into the master-slave mapping module of the target doctor's console operation unit as the initial reference pose of the master hand. Finally, the downlink control channel of the target doctor's console operation unit to the target surgical arm is enabled, so that the master hand's motion input can generate corresponding motion control commands in real time.

[0049] In this embodiment, the entire transfer process does not rely on the response or confirmation of the reference doctor's console, which can ensure a rapid and seamless switch of control in emergency scenarios.

[0050] Step 140: After the transfer of control is completed, establish a master-slave control mapping between the operation unit in the target doctor's console used to trigger the surgical arm switching command and the target surgical arm.

[0051] The completion of control transfer means that all operations involved in the above steps, such as releasing permissions, updating ownership, and disconnecting the original mapping, have been executed. The target surgical arm is currently in a masterless but takeover state, and the target doctor's console has been officially registered as its new controller. The operating unit used to trigger the surgical arm switching command can refer to the physical or logical input device in the target doctor's console that actually issues the switching command, usually a master joystick, a dedicated button, or a foot switch. For example, when the doctor presses the grab button integrated on the handle using master hand A, this master hand is the operating unit used to trigger the command.

[0052] In this embodiment, establishing a master-slave control mapping is not an abstract concept, but rather refers to completing a series of configuration actions within the control device so that the motion input of the operating unit can be converted into the motion output of the target surgical arm in real time. This may include: pose alignment, kinematic model binding, command channel activation, or feedback loop activation, etc.

[0053] In an optional implementation of this embodiment, after the transfer of control is completed, a record can be created or updated in the master-slave mapping management table to bind the operation unit in the target doctor's console used to trigger the surgical arm switching command to the target surgical arm one-to-one; further, the current six-degree-of-freedom pose data (e.g., may include three-dimensional position coordinates x, y, z and Euler angles roll, pitch, yaw) of the target surgical arm is read from the joint encoder and end-effector pose calculation module, and the pose value is written into the reference coordinate system register in the master-slave mapping module corresponding to the operation unit as the initial zero position of the master hand; further, according to the kinematic parameters of the target surgical arm (may include link length, joint offset or degree-of-freedom configuration, etc.) and the preset scaling factor, the corresponding forward and inverse kinematic mapping functions can be loaded into the real-time control thread dedicated to the operation unit.

[0054] In another optional implementation of this embodiment, based on the above, the downlink control channel can be activated to start sampling the master hand motion input of the operation unit at a frequency of 1 kHz or higher. The joint velocity command or end-effector trajectory command of the target surgical arm is calculated in real time through the mapping function and sent to the underlying servo controller. At the same time, the uplink feedback channel is activated to transmit the data streams returned by the target surgical arm, such as joint angle, end-effector force / torque, collision detection status, and emergency stop signal, back to the operation unit in real time for driving the force feedback motor or updating the human-machine interface status. Finally, the status field of the master-slave pair in the mapping management table is updated from pending activation to activated, indicating that the master-slave control mapping has been successfully established, and the doctor can immediately perform continuous, smooth and closed-loop teleoperation control of the target surgical arm through the operation unit.

[0055] In one example of this scheme, during a robot-assisted laparoscopic partial nephrectomy performed collaboratively by a surgeon and an assistant, the surgical robot platform is connected to two active surgeon consoles: the surgeon's console A and the assistant's console B. At this time, the assistant's console B is operating instrument arm 3 (used to retract the kidney) via its right master hand; this arm is marked as repossessed. During the operation, a branch of the renal artery ruptures and bleeds, requiring the surgeon to immediately take control of instrument arm 3 to assist in hemostasis. The surgeon then presses the integrated repossession button on the right master hand of console A, issuing a surgical arm switching command for instrument arm 3. The control device detects that console A has repossession authority, and that instrument arm 3 is currently controlled by the active console B and is repossessed; therefore, it identifies the command as a control takeover event. Subsequently, the control device disconnects the master-slave data stream between console B and instrument arm 3, releases its control binding, and transfers control of instrument arm 3 to console A. After the transfer, the control device establishes a master-slave control mapping between the right-hand master hand triggering the command in console A and instrument arm 3: it reads the current end-effector pose of instrument arm 3 as the initial reference zero position of the master hand, loads the corresponding kinematic model, activates the downlink command channel from the master hand to the instrument arm and the uplink feedback channel from the instrument arm status to the master hand, and updates the mapping status from pending activation to activated. The entire process is completed within 200 milliseconds without assistant confirmation. The surgeon then smoothly manipulates instrument arm 3 through the master hand to achieve precise compression hemostasis, effectively avoiding the risk of blood loss caused by the delay in switching permissions.

[0056] The technical solution of this embodiment, by determining that there are at least two active doctor consoles in the target surgical robot system, and that the target doctor console issuing the surgical arm switching command has enabled the preemption permission, receives the surgical arm switching command and determines the target surgical arm to which the surgical arm switching command points; when the target surgical arm is a preemptible instrument arm controlled by another active reference doctor console, the surgical arm switching command is determined as a control preemption event; based on the control preemption event, the control of the target surgical arm is transferred from the reference doctor console to the target doctor console; after the control transfer is completed, a master-slave control mapping is established between the operation unit in the target doctor console used to trigger the surgical arm switching command and the target surgical arm, which can realize the automatic transfer of control permission for the surgical arm, and help ensure that the critical instrument arm can be taken over in a timely manner in emergency or high-risk surgical scenarios, avoiding delays in the surgical process or endangering patient safety due to permission switching delays.

[0057] Example 2

[0058] Figure 2 This is a flowchart of a method for seizing control of a surgical arm according to Embodiment 2 of the present invention. This embodiment is a further refinement of the above technical solution, and the technical solution in this embodiment can be combined with various optional solutions in one or more of the above embodiments. Figure 2 As shown, the method includes:

[0059] Step 210: If at least two doctor consoles are active in the target surgical robot system, and the target doctor console that issued the surgical arm switching command has enabled the preemption permission, receive the surgical arm switching command and determine the target surgical arm to which the surgical arm switching command is directed.

[0060] Optionally, in this embodiment, when it is determined that there are at least two active doctor consoles in the target surgical robot system, and the target doctor console that issued the surgical arm switching command has enabled the preemption permission, receiving the surgical arm switching command and determining the target surgical arm to which the surgical arm switching command points may include: after receiving the surgical arm switching command issued by the target doctor console, obtaining the identity status and preemption permission configuration of the target doctor console; when the identity status is active, the preemption permission configuration indicates that the preemption permission has been enabled, and there are at least two active doctor consoles in the system, parsing the surgical arm switching command, and determining the target surgical arm based on the parsing result.

[0061] Optionally, in this embodiment, after receiving the surgical arm switching command issued by the target doctor's console, the target surgical robot system can extract the source console identifier from the message header of the command and use it as an index to look up the corresponding record in the internally maintained console status table. In this embodiment, the record may contain multiple fields, among which the identity status field is used to indicate the current running stage and determine whether its value is active. The active status requires that the console has completed user authentication, the master hand is enabled and the foot pedal is in the depressed state, the communication heartbeat with the real-time control kernel is normal, and it has not been put into sleep or offline mode. Furthermore, the user permission configuration table can be queried based on the user identity in the same record to read the preemption permission configuration field. If the value of this field is true, it indicates that the preemption permission has been enabled. At the same time, the control device traverses all records in the console status table and counts the number of entries with the status "active". If the total number is less than 2, it is determined that the multi-control collaboration prerequisite is not met, and the instruction is directly discarded. Only when all three conditions are met—identity status is active, preemption permission is enabled, and the number of active consoles is ≥2—is the instruction parsing module called to perform structured decoding of the data payload of the surgical arm switching instruction. For example, if the instruction is in JSON format, the string value of the "target robotic arm" identifier field (such as "TOOL_ARM_RIGHT") is extracted, and then mapped to an internally unique surgical arm logical ID (such as "ARM_02") by looking up the table. Finally, this ID is determined as the target surgical arm, and it is passed to the subsequent preemption event determination module along with the source console ID.

[0062] The solution in this embodiment is based on predefined data structures and state machine logic, which are executed automatically to ensure that the control transfer process is only allowed in clear, safe, and compliant multi-doctor collaborative scenarios.

[0063] Step 220: Determine whether the target surgical arm is in an inactive control state; if it is determined that the target surgical arm is in an inactive control state, then the surgical arm switching command is identified as a control takeover event.

[0064] The inactive control state includes at least one of the following states: the target surgical arm is not in master-slave teleoperation motion, clutch activation waiting state, and mirror control related waiting state.

[0065] In this embodiment, an inactive control state refers to a situation where the target surgical arm may be nominally held by a doctor's console, but is not in actual teleoperation or critical interaction waiting, and therefore can be safely taken over. This state is not idle, but rather refers to the absence of real-time master-slave coupling or high-priority task occupancy.

[0066] Not in master-slave teleoperation motion means that the target surgical arm is not currently responding to any master hand input to move. For example, although the assistant console still has control of the instrument arm 3, its master hand has been stationary for more than 500ms and the servo command stream has been paused. At this time, the arm is in a pose-holding state, which is not a master-slave teleoperation motion.

[0067] Clutch activation wait state refers to a situation where the doctor has activated the clutch function (e.g., pressed the clutch button on the master arm) and is waiting to realign the master and slave positions or prepare to regain control. During this time, the slave arm pauses movement, but control is retained. For example, after releasing the clutch, the doctor needs to depress the enable pedal again to continue operating; this interval constitutes the clutch activation wait state.

[0068] Endoscope-related waiting state refers to a state where the target surgical arm, acting as an endoscope arm, is in a standby state triggered by an endoscope control mode (e.g., voice, foot pedal, or automatic tracking) but has not yet executed a new command. For example, if the doctor says "look up," the endoscope control module will interpret the command and enter a waiting confirmation or buffer queue, but the lens has not yet moved; this is an endoscope-related waiting state.

[0069] Optionally, in one implementation of this embodiment, after determining the target surgical arm, the corresponding operating status record of the surgical arm can be further read; the motion command output log of its downlink command channel in the past 200 milliseconds can be checked. If all joint speeds and end-effector trajectory commands are zero or in hold mode, then it is marked as not being in master-slave teleoperation motion. At the same time, the clutch input signal status of the associated console is read. If the clutch button is pressed and the motion enable flag of the target surgical arm is paused, then it is marked as being in clutch activation waiting state. If the target surgical arm is an endoscope arm, then the endoscope control task scheduling queue is further queried. If there is a parsed but not yet triggered view adjustment request in the queue, then it is marked as being in endoscope control related waiting state. Finally, the above three flags can be logically ORed. As long as any one flag is true, it can be determined that the target surgical arm is in an inactive control state. Under the condition that this determination result is true, the received surgical arm switching command is formally determined as a control takeover event, and the subsequent permission transfer process is triggered. If all three flags are false, then it can be determined that the target surgical arm is in an active control state, the switching command is rejected, and no takeover event is generated.

[0070] Optionally, in this embodiment, before determining the surgical arm switching command as a control takeover event, it may further include: determining whether a condition prohibiting takeover is triggered, and if it is determined that a condition prohibiting takeover is triggered, not determining the surgical arm switching command as a control takeover event, and maintaining the ownership of control of the target surgical arm unchanged.

[0071] The conditions under which seizure is prohibited include at least one of the following situations: the target surgical arm is a scope-holding arm or is malfunctioning; or, the target surgical arm is in a master-slave teleoperation motion, a clutch activation waiting state, or a scope-related waiting state; or, the target surgical robot system is in scope-controlled operation mode; or, the operating unit used to trigger the surgical arm switching command is in a clutch activation state.

[0072] It is understood that the endoscope-holding arm refers to the surgical arm used to hold and manipulate the endoscope. Because its field of view directly affects the operating vision of all surgeons, it is usually set as a high priority or prohibited from being grabbed. Faults can include hardware failures (e.g., motor overheating, encoder malfunction), software anomalies (e.g., communication timeout, motion planning failure), or safety conditions (e.g., emergency stop triggered). For example, if the joint temperature sensor of the target surgical arm reports exceeding a threshold, it can be flagged as an overheating fault.

[0073] In an optional implementation of this embodiment, before determining the surgical arm switching command as a control takeover event, the type identifier of the target surgical arm can be read. If its type field is a scope arm, a takeover prevention condition is triggered. Further, the fault status register of the surgical arm can be queried; if any fault flag bit is true, a takeover prevention condition is triggered. Further, its downlink command log is checked: if there are consecutive non-zero joint velocities or end-effector trajectory commands within the past 200 milliseconds, it is determined that it is in master-slave teleoperation motion, triggering a takeover prevention condition; if it is not in motion, the clutch signal of its associated control console is further read. If the clutch button is pressed and the motion enable is paused, it is determined to be in a clutch activation waiting state, triggering the anti-seizure condition. If the target surgical arm is an endoscope arm, the endoscope control task queue is queried. If there is a parsed but unexecuted view adjustment request in the queue, it is determined to be in an endoscope control related waiting state, triggering the anti-seizure condition. At the same time, the global operation mode flag can also be read. If the current mode is endoscope control operation mode, the anti-seizure condition is triggered regardless of the target arm type. In addition, the clutch input signal of the operation unit used to trigger the switching command is read. If its clutch is in an active state, the anti-seizure condition is also triggered.

[0074] In this embodiment, when any of the above conditions are met, the process of generating the takeover event can be terminated immediately, the current ownership of the target surgical arm can be maintained, and a takeover prohibition prompt can be returned to the initiator. Only when none of the prohibition conditions are triggered will the subsequent judgment continue and the instruction be identified as a takeover event.

[0075] This embodiment of the solution, by introducing multi-dimensional judgments on prohibition conditions before the confirmation of a takeover event, effectively avoids problems such as operational conflicts, mechanical abrupt changes, or loss of visual control that may result from forcibly taking over the surgical arm in high-risk or inappropriate scenarios. It ensures that takeover of control only occurs when the target is clear, the situation is safe, and the operation is legal, thus guaranteeing both the continuity and safety of the surgical procedure and improving the reliability and clinical applicability of multi-doctor collaborative operations.

[0076] Step 230: Based on the control takeover event, transfer control of the target surgical arm from the reference doctor's console to the target doctor's console.

[0077] Optionally, in this embodiment, transferring control of the target surgical arm from the reference doctor's console to the target doctor's console based on the control takeover event may include: disconnecting the master-slave data stream between the first operating unit in the reference doctor's console that has established a master-slave control mapping with the target surgical arm and the target surgical arm, and releasing the target surgical arm's control permissions over the reference doctor's console; assigning the control permissions of the target surgical arm to the operating unit in the target doctor's console used to trigger the surgical arm switching command, and setting the initial master hand pose of the operating unit according to the current pose information of the target surgical arm.

[0078] The first operating unit refers to the specific human-computer interaction input device that establishes a master-slave control mapping with the target surgical arm on the doctor's console. It receives the doctor's hand operation intentions and converts them into control commands to drive the target surgical arm's movement. This operating unit is typically the master hand manipulation device, possessing multi-degree-of-freedom motion sensing capabilities. It can collect the doctor's hand position, posture, and operational force in real time and generate corresponding slave surgical arm movement commands through a master-slave mapping algorithm. For example, in a cholecystectomy assisted by a four-arm surgical robot, the assistant doctor uses the master hand (i.e., the first operating unit) on the right side of their console to control the instrument arm 2 for tissue traction. At this time, a one-to-one master-slave mapping relationship has been established between the right master hand and the instrument arm 2: when the assistant moves the master hand, the instrument arm 2 moves synchronously; simultaneously, the force sensor data at the end of the instrument arm 2 drives the force feedback motor of the master hand through the uplink channel, allowing the assistant to feel tissue tension. When the surgeon initiates a takeover request for the arm and it is confirmed as a valid takeover event, the aforementioned right master hand, acting as the first operating unit, disconnects the master-slave data flow with the instrument arm 2, and control is released.

[0079] In an optional implementation of this embodiment, after confirming the control takeover event, the master-slave data flow between the first operating unit paired with the target surgical arm in the reference doctor's console and the surgical arm can be interrupted first. For example, this may include stopping the sampling of the motion input of the first operating unit to generate downlink commands and closing the uplink status feedback channel (e.g., position, force, running status, etc.) from the target surgical arm to the operating unit. Further, in the surgical arm permission management table, the control ownership field of the target surgical arm is cleared from the identifier of the reference doctor's console or set to invalid, thus releasing the control permission of the console. The control ownership field of the target surgical arm is updated to the unique identifier of the operating unit in the target doctor's console used to trigger the surgical arm switching command, thus completing the allocation of control permissions.

[0080] Based on this, the current six-degree-of-freedom pose data, including three-dimensional spatial coordinates and Euler angles, is read from the joint encoder and end-effector pose calculation module of the target surgical arm, and the pose value is written into the reference coordinate system register in the master-slave mapping module corresponding to the operation unit as its master hand initial pose.

[0081] Step 240: After the transfer of control is completed, establish a master-slave control mapping between the operation unit in the target doctor's console used to trigger the surgical arm switching command and the target surgical arm.

[0082] Optionally, in this embodiment, after the transfer of control is completed, establishing a master-slave control mapping between the operation unit in the target doctor's console used to trigger the surgical arm switching command and the target surgical arm may include: associating the control authority of the target surgical arm with the operation unit; setting the current pose of the target surgical arm as the initial pose of the master hand of the operation unit; enabling the operation unit to remotely control the target surgical arm so that the master hand motion input of the operation unit can drive the movement of the target surgical arm.

[0083] In an optional implementation of this embodiment, after the transfer of control is completed, the control master hand identifier field corresponding to the target surgical arm can be further updated to the globally unique identifier of the operation unit in the surgical arm resource mapping table to complete the binding of control permissions; furthermore, the current angle values ​​output by the position sensors of each joint of the target surgical arm can be read, the pre-stored forward kinematics model of the surgical arm can be called, and the three-dimensional spatial position and three-dimensional spatial attitude of the end effector in the robot base coordinate system can be calculated; the calculated position and attitude data can be written into the reference pose register associated with the operation unit in the master-slave mapping management table as the initial pose of the master hand. A real-time task scheduler is configured to trigger a master hand sampling operation every millisecond. In each sampling, the raw output signals of the position sensors of each degree of freedom of the operation unit are acquired, filtered and calibrated, and then converted into the displacement change of the master hand in joint space or Cartesian space. The displacement change is multiplied by a preset motion scaling ratio to obtain the expected displacement change of the end effector of the target surgical arm. Furthermore, the expected displacement change is input to the inverse kinematics solving module of the target surgical arm to calculate the velocity commands required for each joint. The velocity commands of each joint are encapsulated into real-time communication protocol messages and sent to the servo driver of the target surgical arm through the industrial bus.

[0084] Simultaneously, the actual joint angle, motor current, collision status, and end-effector force sensor data of the target surgical arm are periodically read from the servo driver; this feedback data is transmitted to the force feedback control module of the operating unit to generate the drive signal for the force feedback motor; the motion input of the master hand is thus continuously converted into the motion output of the target surgical arm, forming a complete remote operation control closed loop.

[0085] Optionally, in this embodiment, after establishing a master-slave control mapping between the operating unit and the target surgical arm, if the operating unit is in a master-slave teleoperation state before the seizure, then the master-slave teleoperation control with the target surgical arm is activated; if the operating unit is not in a master-slave teleoperation state before the seizure, then the master-slave teleoperation control is not activated.

[0086] In an optional implementation of this embodiment, after establishing a master-slave control mapping between the operating unit and the target surgical arm, the operating unit's running status record before the snatching event can be further queried to determine whether it is in a master-slave teleoperation state. This state is determined by checking whether the downlink command channel of the operating unit is active at the time the snatching command is triggered, and whether its associated slave surgical arm is responding to its real-time motion input. If the record shows that the operating unit has previously established a valid master-slave mapping with another surgical arm and is in continuous teleoperation, then the mapping binding with the target surgical arm is completed. Subsequently, the teleoperation control of the target surgical arm by the operating unit is automatically activated, including initiating master hand input sampling, activating motion mapping calculation, issuing servo commands, and opening the status feedback loop. If the record shows that the operating unit did not establish a master-slave mapping with any surgical arm before the grab, or although it was bound, it was in a clutch-activated, paused, or idle state, then after the mapping binding is completed, only the permission association and pose initialization are completed. The master hand input sampling and command issuance process are not initiated, and the teleoperation control remains inactive. The target surgical arm will only start moving after the doctor performs an explicit operation such as stepping on the enable pedal or pressing the recovery button.

[0087] The solution in this embodiment intelligently determines whether to automatically activate teleoperation based on the control state of the operating unit before the takeover, avoiding unnecessary false triggers or unexpected movements: when the operating unit is already performing teleoperation, it indicates that it is in active operation mode, and at this time, the control of the newly taken-over surgical arm is automatically activated, which can achieve seamless continuous operation and improve surgical efficiency; when the operating unit is originally in an idle, disengaged, or inactive state, teleoperation is not automatically activated to prevent the target surgical arm from moving unexpectedly due to the micro-movement or drift of the master hand, thereby balancing the smoothness of operation and the safety of surgery.

[0088] To better understand the method for seizing surgical arm permissions involved in this embodiment, an example is used below for illustration, which mainly includes the following: real-time monitoring and maintenance of the identity status of all doctor consoles in the system, determining whether there are at least two doctor consoles currently in the "active" state; if not, prohibiting any control seizure behavior; if so, further determining whether the doctor console initiating the seizure request has pre-enabled the "seizure permission" function, and only allowing entry into the subsequent seizure process when the console has seizure permission;

[0089] In response to the arm switching operation command executed by the master hand (left master hand HL or right master hand HR) of the initiating doctor's console with the right to seize control, the arm switching operation command is triggered by stepping on the SW-Pedal pedal or the Fn-Pedal function pedal. The system identifies the target surgical arm pointed to by the command and verifies whether the target surgical arm is an instrument arm that is ready for surgery (i.e., non-scope arm, non-faulty arm, and in a usable state).

[0090] If the target surgical arm is currently controlled by another "active" doctor's console, then it is further checked whether the holding state meets the preconditions for takeover: that is, the other doctor's console is not currently performing any of the following operations on the target surgical arm - master-slave teleoperation, waiting in the clutch-activated state, or mirror-related waiting; if the target surgical arm is in any of the above operation states, then it is determined that the takeover condition is not met, the arm switching command is processed according to the normal logic or is rejected, and the control remains unchanged;

[0091] If the target surgical arm is in an idle control state (i.e., it is held but not being operated), the system will identify this arm switching behavior as a "control grab" event and immediately execute a forced transfer of permissions: unilaterally and asymmetrically stripping the target surgical arm from the other doctor's console and granting it to the initiating doctor's console; this transfer process does not require confirmation from the party whose control was grabbed, cannot be interrupted, cannot be revoked, and does not involve the exchange of identities or other surgical arm permissions between the two parties;

[0092] After a successful takeover, the system automatically maps the primary arm (HL or HR) that triggered the arm switching command in the initiating doctor's console to the target surgical arm that was just taken over, and performs differentiated follow-up actions based on the primary arm's operating state before the takeover:

[0093] If the master hand is in a master-slave teleoperation state before the seizure (i.e., it has controlled a surgical arm and is performing movements), the master-slave control relationship will be automatically switched to the newly seized surgical arm after the mapping is completed, and the continuous master-slave movements will continue to be executed, achieving seamless operation.

[0094] If the master arm is idle before the grabbing (not bound to any surgical arm or not performing master-slave operation), only the mapping binding is completed, and the master-slave control is not automatically started. The surgical arm can only be driven after the doctor actively operates it.

[0095] Before executing the grabbing judgment, the system must also check the global operation status: if the entire surgical system is currently in the endoscope control operation mode, or the trigger master hand of the initiating doctor's console is in the clutch activation state (i.e. the master hand and slave arm are decoupled), then regardless of whether other conditions are met, the grabbing function is prohibited, and the user can be prompted with "grabbing unavailable".

[0096] All triggering conditions, judgment results, permission transfer records, and mapping changes for all snatching incidents are recorded in real time to an immutable audit log, and the ownership status of the surgical arm is visually updated on the patient-side human-machine interface (HMI) to ensure operational transparency and accountability.

[0097] The solution of this invention significantly improves the flexibility and response efficiency of multi-surgeon collaborative operations by constructing a multi-level, conditional control takeover mechanism, while ensuring surgical safety. On the one hand, by strictly limiting the triggering conditions for takeover, it effectively avoids instrument abrupt movements, loss of vision, or operational conflicts caused by accidental takeover in high-risk or unsuitable scenarios. On the other hand, when safety conditions are met, it realizes an instantaneous, one-way, and irreversible transfer of authority without the confirmation of the party being taken over. It also intelligently determines whether to automatically activate teleoperation based on the previous state of the initiating master hand, ensuring that the surgeon can quickly take over key instrument arms in emergencies and preventing the idle master hand from accidentally driving slave arms.

[0098] Example 3

[0099] Figure 3 This is a schematic diagram of a surgical arm control control grabbing device according to Embodiment 3 of the present invention. Figure 3 As shown, the device includes: a first determining module 310, a second determining module 320, a control transfer module 330, and a control mapping establishment module 340.

[0100] The first determining module 310 is used to receive the surgical arm switching instruction and determine the target surgical arm to which the surgical arm switching instruction points when there are at least two active doctor consoles in the target surgical robot system and the target doctor console that issued the surgical arm switching instruction has enabled the preemption permission.

[0101] The second determining module 320 is used to determine the surgical arm switching command as a control takeover event when the target surgical arm is a grabbable instrument arm controlled by another active reference physician console.

[0102] The control transfer module 330 is used to transfer control of the target surgical arm from the reference doctor's console to the target doctor's console based on the control takeover event;

[0103] The control mapping establishment module 340 is used to establish a master-slave control mapping between the operation unit in the target doctor's console used to trigger the surgical arm switching command and the target surgical arm after the control transfer is completed.

[0104] In this embodiment, the solution involves a first determining module that, when at least two doctor consoles are active in the target surgical robot system and the target doctor console issuing the surgical arm switching command has enabled the preemption of control, receives the surgical arm switching command and determines the target surgical arm to which the command points. A second determining module identifies the surgical arm switching command as a control preemption event. Based on this event, a control transfer module transfers control of the target surgical arm from the reference doctor console to the target doctor console. After the control transfer is completed, a control mapping module establishes a master-slave control mapping between the operation unit in the target doctor console that triggers the surgical arm switching command and the target surgical arm. This enables automatic transfer of control over the surgical arm, ensuring timely takeover of critical surgical arms in emergency or high-risk surgical scenarios and preventing delays in surgical progress or endangering patient safety due to delayed control switching.

[0105] In an optional implementation of this embodiment, the acquisition of control rights for the surgical arm further includes: a master-slave teleoperation control activation confirmation module, which is used to automatically activate master-slave teleoperation control with the target surgical arm if the operating unit is in a master-slave teleoperation state before the acquisition after establishing a master-slave control mapping between the operating unit and the target surgical arm.

[0106] If the operating unit is not in a master-slave remote operation state before the seizure, the master-slave remote operation control will not be automatically activated.

[0107] In an optional implementation of this embodiment, the first determining module 310 is specifically used to obtain the identity status and preemption permission configuration of the target doctor's console after receiving the surgical arm switching instruction issued by the target doctor's console;

[0108] When the identity status is active, the permission to seize is configured to enable permission to seize, and there are at least two active doctor consoles in the system, the surgical arm switching command is parsed, and the target surgical arm is determined based on the parsing result.

[0109] In an optional implementation of this embodiment, the device for seizing control of the surgical arm further includes: a module for confirming the triggering of a prohibition condition, used to determine whether a prohibition condition is triggered, and if it is determined that a prohibition condition is triggered, not to determine the surgical arm switching command as a control seizure event, and to maintain the control of the target surgical arm unchanged;

[0110] The prohibition of robbery includes at least one of the following situations:

[0111] The target surgical arm is a scope-holding arm or is malfunctioning;

[0112] Alternatively, the target surgical arm may be in a master-slave teleoperation state, a clutch activation waiting state, or a mirror-related waiting state.

[0113] Alternatively, the target surgical robot system may be in endoscopic control mode.

[0114] Alternatively, the operating unit used to trigger the surgical arm switching command is in a clutch-activated state.

[0115] In an optional implementation of this embodiment, the second determining module 320 is specifically used to determine whether the target surgical arm is in an inactive control state;

[0116] If it is determined that the target surgical arm is in an inactive control state, then the surgical arm switching command is determined as a control takeover event;

[0117] The inactive control state includes at least one of the following states: the target surgical arm is not in master-slave teleoperation motion, clutch activation waiting state, or mirror control related waiting state.

[0118] In an optional implementation of this embodiment, the control transfer module 330 is specifically used to disconnect the master-slave data flow between the first operation unit in the reference doctor console that has established a master-slave control mapping with the target surgical arm and the target surgical arm, and to release the target surgical arm's control permissions over the reference doctor console;

[0119] The control authority of the target surgical arm is assigned to the operation unit in the target doctor's console used to trigger the surgical arm switching command, and the initial position of the main hand of the operation unit is set according to the current position information of the target surgical arm.

[0120] In an optional implementation of this embodiment, the control mapping establishment module 340 is specifically used to associate the control permissions of the target surgical arm with the operation unit;

[0121] Set the current pose of the target surgical arm as the initial pose of the main hand of the operation unit;

[0122] The operation unit is enabled to remotely control the target surgical arm, so that the main hand motion input of the operation unit can drive the target surgical arm to move.

[0123] The surgical arm control control grabbing device provided in this embodiment of the invention can execute the surgical arm control control grabbing method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0124] Example 4

[0125] Figure 4 A schematic diagram of an electronic device 10, which can be used to implement embodiments of the present invention, is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0126] like Figure 4 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded into the RAM 13 from the storage unit 18. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0127] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0128] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, digital signal processors (DSPs), and any suitable processor, controller, microcontroller, etc. Processor 11 executes the various methods described above, such as the method of seizing control of a surgical arm.

[0129] In some embodiments, the method for seizing control of the surgical arm may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the surgical arm control seizure method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to perform the surgical arm control seizure method by any other suitable means (e.g., by means of firmware).

[0130] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0131] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0132] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, RAM, ROM, erasable programmable read-only memory (EPROM), optical fibers, compact disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0133] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device for displaying information to the user (e.g., a cathode ray tube (CRT) or liquid crystal display (LCD) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0134] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0135] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system. It addresses the shortcomings of traditional physical hosts and Virtual Private Servers (VPS) in terms of management difficulty and weak business scalability.

[0136] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0137] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

[0138] This invention also provides a computer program product, including a computer program that, when executed by a processor, implements the method for seizing control of the surgical arm as provided in any embodiment of this application.

[0139] In implementing the computer program product, computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof. Programming languages ​​include object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including LANs or WANs—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0140] It should be noted that in the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, they do not mean that the solution has been or necessarily used.

[0141] Note that the above description is merely a preferred embodiment of the present invention and the technical principles employed. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in detail through the above embodiments, the present invention is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of the present invention, the scope of which is determined by the scope of the appended claims.

Claims

1. A method for seizing control of a surgical arm, characterized in that, The method includes: If it is determined that there are at least two active doctor consoles in the target surgical robot system, and the target doctor console that issued the surgical arm switching command has enabled the preemption permission, the surgical arm switching command is received, and the target surgical arm to which the surgical arm switching command is directed is determined. When the target surgical arm is a grabbable instrument arm controlled by another active reference physician console, the surgical arm switching command is identified as a control grab event. Based on the control takeover event, control of the target surgical arm is transferred from the reference doctor's console to the target doctor's console; wherein, the transfer process does not depend on the response or confirmation of the reference doctor's console; After the transfer of control is completed, a master-slave control mapping is established between the operation unit in the target doctor's console used to trigger the surgical arm switching command and the target surgical arm; Before determining the surgical arm switching command as a control takeover event, the method further includes: Determine whether the anti-seizure condition is triggered, and if the anti-seizure condition is triggered, do not determine the surgical arm switching command as a control seizure event, and maintain the control ownership of the target surgical arm unchanged; The prohibition of robbery includes at least one of the following situations: The target surgical arm is a scope-holding arm or is malfunctioning; Alternatively, the target surgical arm may be in a master-slave teleoperation state, a clutch activation waiting state, or a mirror-related waiting state. Alternatively, the target surgical robot system may be in endoscopic control mode. Alternatively, the operating unit used to trigger the surgical arm switching command is in a clutch-activated state.

2. The method for seizing control of the surgical arm according to claim 1, characterized in that, The method further includes: After establishing a master-slave control mapping between the operating unit and the target surgical arm, if the operating unit is in a master-slave teleoperation state before the seizure, then the master-slave teleoperation control with the target surgical arm is activated. If the operating unit is not in a master-slave remote operation state before the seizure, the master-slave remote operation control will not be activated.

3. The method for seizing control of the surgical arm according to claim 1, characterized in that, In the case where at least two doctor consoles are active in the target surgical robot system, and the target doctor console that issued the surgical arm switching command has enabled preemption privileges, receiving the surgical arm switching command and determining the target surgical arm to which the surgical arm switching command points includes: Upon receiving the surgical arm switching command from the target doctor's console, the system obtains the identity status and preemption permission configuration of the target doctor's console. When the identity status is active, the permission to seize is configured to enable permission to seize, and there are at least two active doctor consoles in the system, the surgical arm switching command is parsed, and the target surgical arm is determined based on the parsing result.

4. The method for seizing control of the surgical arm according to claim 1, characterized in that, When the target surgical arm is a grabbable instrument arm controlled by another active reference physician console, the surgical arm switching command is defined as a control grab event, including: Determine whether the target surgical arm is in an inactive control state; If it is determined that the target surgical arm is in an inactive control state, then the surgical arm switching command is determined as a control takeover event; The inactive control state includes at least one of the following states: the target surgical arm is not in master-slave teleoperation motion, clutch activation waiting state, or mirror control related waiting state.

5. The method for seizing control of the surgical arm according to claim 1, characterized in that, The transfer of control of the target surgical arm from the reference physician console to the target physician console based on the control takeover event includes: Disconnect the master-slave data stream between the first operating unit in the reference doctor console that has established a master-slave control mapping with the target surgical arm and the target surgical arm, and release the target surgical arm's control permissions over the reference doctor console; The control authority of the target surgical arm is assigned to the operation unit in the target doctor's console used to trigger the surgical arm switching command, and the initial position of the main hand of the operation unit is set according to the current position information of the target surgical arm.

6. The method for seizing control of the surgical arm according to claim 1, characterized in that, After the transfer of control is completed, a master-slave control mapping is established between the operation unit in the target doctor's console used to trigger the surgical arm switching command and the target surgical arm, including: Associate the control authority of the target surgical arm with the operation unit; Set the current pose of the target surgical arm as the initial pose of the main hand of the operation unit; The operation unit is enabled to remotely control the target surgical arm, so that the main hand motion input of the operation unit can drive the target surgical arm to move.

7. An electronic device, characterized in that, The electronic device includes: At least one processor; and a memory communicatively connected to the at least one processor; The memory stores a computer program that can be executed by the at least one processor, which is then executed by the at least one processor to enable the at least one processor to perform the method for seizing control of the surgical arm as described in any one of claims 1-6.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that, when executed by a processor, implement the method for seizing control of the surgical arm as described in any one of claims 1-6.

9. A computer program product comprising a computer program that, when executed by a processor, implements a method for seizing control of a surgical arm according to any one of claims 1-6.

Images