Control system for a surgical robotic system with safety device

Abstract

A control system for controlling a surgical robotic system, the surgical robotic system comprising a surgical robot comprising a base and an arm extending from the base to an attachment for an instrument, the arm comprising a plurality of joints whereby the configuration of the arm can be varied, the control system comprising: a master controller configured to receive a communication from an operator of the surgical robot identifying an input, to generate a control signal based on the input for controlling movement of the surgical robot arm, and to send a communication to the surgical robot identifying the control signal; and a safety device positioned such that communications to and from the master controller pass through the safety device, the safety device operable to selectively filter communications to and / or from the master controller.

Description

Background Technology

[0001] The use of robots to assist and perform surgery is known. Figure 1 An exemplary surgical robot system 100 is shown, including a surgical robot 102 comprising a base 104, an arm 106, and an instrument 108. The base 104 supports the robot and is rigidly attached to, for example, an operating room floor, operating room ceiling, or trolley. The arm 106 extends between the base 104 and the instrument 108. The arm 106 is hinged by means of a plurality of flexible joints 110 along its length, which are used to position the surgical instrument relative to the patient in a desired location. The surgical instrument is attached to the distal end 112 of the robotic arm. The surgical instrument passes through the body of the patient 114 at a port 116 to access the surgical site. The instrument includes, at its distal end, an end effector 118 for engagement during medical procedures.

[0002] Surgical robot 102 is remotely controlled by an operator (e.g., a surgeon) via operator console 120, which may be located in the same room (e.g., an operating room) as the surgical robot 102 or remotely. Operator console 120 may include input devices 122, 124 for controlling the status of arm 106 and / or instruments 108 attached to the arm. Input devices 122, 124 may be, for example, handles or manual controllers (e.g., one per hand) with one or more buttons mounted on parallelogram links. Operator console 120 may also include a display 126. Display 126 may be arranged to be visible to the operator (e.g., the surgeon) operating input devices 122, 124. Display 126 may be used to display video streams of the surgical site (e.g., video streams captured by an endoscope, and / or video streams captured by another camera or microscope (e.g., those used in open surgery)) and / or other information to assist the operator (e.g., the surgeon) in performing the surgery. The display may be two-dimensional (2D) or three-dimensional (3D).

[0003] The control system 128 converts the movement of the input device (and actions performed on / via the input device) into control signals to move the arm joints and / or end effectors of the surgical robot. In some cases, the control system 128 is configured to generate control signals for moving the arm joints and / or end effectors based on the spatial position and orientation of the input device.

[0004] although Figure 1 The exemplary surgical robot system includes a single surgical robot, but in other instances, the surgical robot system may include multiple surgical robots. For example, Figure 2A surgical robot system 200 is shown, in which multiple robots 202, 204, 206 operate in a shared workspace on a patient 208.

[0005] Since the surgical robot systems 100 and 200 are used to perform surgical procedures on patients, it is important that the system's components or elements communicate with each other as intended, and that the control system 128 issues accurate commands to the surgical robot arm based on the status of the surgical robot arm and other components of the system, as well as inputs received from the input devices. If the system does not operate as intended, it could have serious, even catastrophic, consequences. Therefore, it may be desirable to implement one or more safety mechanisms that can determine whether a fault exists in the surgical robot system, particularly the control system 128, and, if a fault is detected, place the system or one or more components of the system into a safe state.

[0006] The embodiments described below are provided as examples only and do not limit the implementation of any or all disadvantages of known surgical robot systems and / or methods for controlling surgical robot systems. Summary of the Invention

[0007] This summary is provided to introduce the choice of concepts further described below in the detailed description. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter.

[0008] This document describes a control system for controlling a surgical robot system, the surgical robot system including a surgical robot, the surgical robot including a base and an arm extending from the base to an attachment for instruments, the arm including multiple joints thereby enabling changes in the configuration of the arm. The control system includes: a main controller configured to: receive communication identifying input from an operator of the surgical robot; generate control signals based on the input for controlling movement of the surgical robot arm; and send communication identifying the control signals to the surgical robot; and a safety device positioned such that communication to and from the main controller passes through the safety device, the safety device being operable to selectively filter communication to and / or from the main controller.

[0009] A first aspect provides a control system for controlling a surgical robot system, the surgical robot system including a surgical robot, the surgical robot including a base and an arm extending from the base to an attachment for instruments, the arm including a plurality of joints thereby enabling changes in the configuration of the arm, the control system including: a main controller configured to: receive communication identifying input from an operator of the surgical robot; generate control signals based on the input for controlling movement of the surgical robot arm; and send communication identifying the control signals to the surgical robot; and a safety device positioned such that communication to and from the main controller passes through the safety device, the safety device being operable to selectively filter communication to and / or from the main controller.

[0010] The safety device can be configured to filter at least a portion of communications destined for and / or originating from the main controller in response to a malfunction in the surgical robot system.

[0011] The security device may include one or more filters, and the one or more filters are configured to filter out communications destined for and / or originating from the master controller by comparing received communications with one or more filter criteria.

[0012] The one or more filters may include receive filters, and the one or more filter criteria may include one or more receive filter criteria, the receive filters being configured to filter communication from the master controller by comparing communication from the master controller with the one or more receive filter criteria.

[0013] The receive filter may include a buffer for storing communications received from the main controller.

[0014] The receive filter may include a manifold and one or more matchers, the manifold being configured to extract relevant information from the received communication before storing the received communication in the buffer, and the one or more matchers being configured to compare the relevant information with the one or more receive filter criteria.

[0015] The one or more receive filter standards may include up to N receive filter standards, where N is an integer based on the number of comparisons that can be performed between the communication and the filter standards in one cycle and the number of cycles spent receiving the communication.

[0016] Receiving communication may require up to X cycles, and N can be selected so that communication within X cycles can be compared with N filter standards.

[0017] The one or more filter criteria may include one or more transmit filter criteria, and the at least one filter includes a transmit filter that can be configured to filter communication destined for the master controller by comparing it with the one or more transmit filter criteria.

[0018] The transmit filter may include a buffer for storing the communication in the main controller.

[0019] The transmit filter may include a manifold and one or more matchers, the manifold being configured to extract relevant information from the communication destined for the master controller before storing the communication in the buffer, and the one or more matchers being configured to compare the relevant information with the one or more transmit filter criteria.

[0020] The one or more transmit filter standards may include up to K receive filter standards, where K is an integer based on the number of comparisons that can be performed between the communication and the filter standards in one cycle and the number of cycles spent receiving the communication.

[0021] Receiving communication may require X cycles, and K can be selected so that communication within X cycles can be compared with K filter standards.

[0022] The one or more filter criteria can be configurable.

[0023] The one or more filter standards can be configured to cause the security device to filter all communications destined for and from the main controller.

[0024] The one or more filter standards can be configured to enable the safety device to filter communication between the main controller and specific devices in the surgical robot system.

[0025] Each of the one or more filter standards may include one or more of a source address, a destination address, a source port, and a destination port.

[0026] The security device may include one or more registers, and each filter standard may be stored in a set of the one or more registers.

[0027] The one or more filters can be configured to reject the communication in response to determining that the communication matches at least one of the one or more filter criteria.

[0028] The one or more filters can be configured to reject the communication by discarding it.

[0029] The one or more filters can be configured to reject the communication by disrupting it.

[0030] The one or more filters can be configured to disrupt the communication by altering the error detection portion of the communication.

[0031] The control system may also include a safety monitor, and the safety device may be configured to send copies of at least a portion of communications destined for and / or from the main controller to the safety monitor.

[0032] The safety monitor can be configured to analyze received communications to determine whether the surgical robot system is in a faulty state, and in response to determining that the surgical robot system is in a faulty state, cause the safety device to filter at least a portion of communications destined for and / or from the main controller.

[0033] A second aspect provides a method for selectively filtering communications destined for and / or from a master controller of a surgical robot system, the surgical robot system including a surgical robot, the surgical robot including a base and an arm extending from the base to an attachment for instruments, the arm including a plurality of joints thereby enabling changes in the configuration of the arm, the master controller being configured to receive communications identifying input from an operator of the surgical robot, generate control signals based on the input for controlling movement of the surgical robot arm, and send communications identifying the control signals to the surgical robot, the method comprising: receiving communications destined for or from the master controller at a safety device; determining whether at least one filter criterion has been specified; in response to determining that at least one filter criterion has been specified, comparing the received communications with at least one specified filter criterion; in response to determining that the received communications match at least one of the at least one filter criterion, rejecting the received communications; and in response to determining that the received communications do not match any of the at least one filter criterion, outputting the communications to an associated device.

[0034] The above features can be combined appropriately, as will be obvious to those skilled in the art, and can be combined with any aspect of the examples described herein. Attached Figure Description

[0035] The examples will now be described in detail with reference to the accompanying drawings, in which:

[0036] Figure 1 This is a schematic diagram of an exemplary surgical robot system, including a surgical robot, an operator console, and a control system.

[0037] Figure 2 This is a schematic diagram of an exemplary surgical robot system that includes multiple surgical robots;

[0038] Figure 3 This is a block diagram of an exemplary control system for a surgical robot system;

[0039] Figure 4 This is a schematic diagram of an exemplary surgical robotic arm;

[0040] Figure 5 yes Figure 3 A block diagram of an exemplary embodiment of a security device including a Tx filter and an Rx filter;

[0041] Figure 6 yes Figure 5 Block diagram of exemplary implementations of Tx and Rx filters;

[0042] Figure 7 It selectively filters destinations and / or sources. Figure 3 A flowchart illustrating an exemplary method for communication with the master controller, the exemplary method being... Figure 3 Safety devices are implemented;

[0043] Figure 8 yes Figure 3 A block diagram of an exemplary implementation of a security monitor;

[0044] Figure 9 This is a flowchart of an exemplary method for monitoring destinations and communications from the main controller to detect faults in the system. The exemplary method can be derived from... Figure 8 The implementation of safety monitoring devices; and

[0045] Figure 10 This is a schematic diagram showing the virtual pivot point of the port.

[0046] The accompanying drawings illustrate various examples. Those skilled in the art will understand that the element boundaries (e.g., boxes, groups of boxes, or other shapes) shown in the drawings represent one instance of a boundary. In some instances, one element may be designed as multiple elements, or multiple elements may be designed as one element. Where appropriate, common reference numerals are used throughout the drawings to indicate similar features. Detailed Implementation

[0047] The following description is presented by way of example to enable those skilled in the art to make and use the invention. The invention is not limited to the embodiments described herein, and various modifications to the disclosed embodiments will be apparent to those skilled in the art. The embodiments are described by way of example only.

[0048] This document describes a control system for a surgical robot system, comprising a remote operator console through which an operator can provide input, and a surgical robot arm comprising a series of joints extending from a base to an end for attaching surgical instruments. The control system includes a main controller and a safety device. The main controller is configured to receive communications recognizing operator input from the operator console, convert these operator inputs into control commands for controlling movement of the surgical robot, and to send communications recognizing the control commands to the surgical robot arm. The safety device is located between the main controller and other components of the system, such that communications to and from the main controller pass through the safety device. The safety device is operable to selectively filter communications to and / or from the main controller. The safety device can be configured to filter at least a portion of communications to and / or from the main controller in response to the safety device itself or another device detecting a fault condition in the surgical robot system. A fault condition may be that the main controller or another device in the system is not operating as expected.

[0049] In some cases, the control system may also include a safety monitor configured to verify the operation of the main controller and / or one or more other components of the system. In these cases, a safety device may be configured to send copies of at least a portion of communications destined for and from the main controller to the safety monitor, and the safety monitor may analyze the received communications to verify whether the main controller and / or one or more other components are operating as intended. In response to detecting that the main controller and / or one or more other components of the system are not operating as intended, the safety monitor may cause the safety device to filter at least a portion of communications destined for and from the main controller.

[0050] Now for reference Figure 3 The illustration shows an exemplary surgical robot system 300. The surgical robot system 300 includes: a surgical robot 302; an operator console 304 for providing operator input for controlling the surgical robot 302; and a control system 306 for driving the surgical robot 302 according to the operator input. The surgical robot 302 includes a base and an arm extending from the base to an attachment for instruments. The arm includes multiple joints, thereby allowing for changes in the arm's configuration. The following section discusses... Figure 5 The description can be used for implementation. Figure 3 An exemplary surgical robot 302.

[0051] The operator console 304 may be located in the same room (e.g., an operating room) as the surgical robot 302 or remotely. The operator console 304 allows the operator to provide input commands to the control system 306 to control the movement of the surgical robot 302. The operator console 304 may include input devices for controlling the state of the surgical robot arm and / or instruments attached to it. Input devices may be, for example, handles or manual controllers (e.g., one per hand) with one or more buttons mounted on parallelogram links. Each input device may include an input device controller 305 configured to transmit input received via the input device to the control system 306. The operator console 304 may also include a display. This display is used to show video streams of the surgical site (e.g., video streams captured by an endoscope, and / or video streams captured by another camera or microscope (e.g., those used in open surgery)) and / or other information to assist the operator (e.g., a surgeon) in performing the surgery. The display may include a display controller 307 configured to receive display information from the control system 306 and provide related inputs to the control system 306. (The above refers to...) Figure 1 Describes what can be implemented Figure 3 An example operator console 304.

[0052] The control system 306 is connected to the operator console 304 (e.g., input device controller 305 and its display controller 307) via one or more communication links 308, and receives communications identifying operator input from the operator console 304 (e.g., input device controller 305 and its display controller 307) via one or more communication links 308. Operator input may be generated by an input device (e.g., a manual controller) and / or other components of the operator console (e.g., foot pedal input, voice recognition system, gesture recognition system, eye recognition system, etc.). The control system 306 is also connected to the surgical robot 302 (e.g., its arm controller 309, which may also be referred to as an arm-based controller (ABC)) via one or more communication links 310. The control system 306 may receive communications identifying the status or condition of the surgical robot 302 from the surgical robot 302 via one or more communication links 310. The state of the surgical robot 302 can be identified, for example, by one or more of the following: sensor data from position sensors and / or torque sensors located on the robot arm joints, force feedback data, and data from or relating to surgical instruments attached to the surgical robot.

[0053] Control system 306 is configured to move surgical robot 302 and instruments attached to it in response to operator input received from operator console 304 and surgical robot status data received from surgical robot 302. Control system 306 includes a main controller 312 configured to: receive communications identifying operator input from operator console 304 and communications including surgical robot status data from surgical robot 302; generate control signals from the operator input and surgical robot status data to move the surgical robot and / or any instruments attached to it; and communicate identifying command signals to the surgical robot. In other words, main controller 312 is responsible for moving the surgical robot and any instruments attached to it according to user input. In the example described herein, main controller 312 is configured to receive input from operator console 304 and generate from it a desired robot wrist position and desired positions of actuating elements to enable the instrument end effector to achieve desired yaw, pitch, and / or deployment. The desired wrist posture and actuating element positions are then provided to the surgical robot arm (e.g., a surgical robot arm controller). As described in more detail below, the surgical robot arm (e.g., its arm controller) can then determine the joint positions for achieving the desired wrist posture based on joint information received from torque and / or position sensors, and issue commands to the respective joint controllers to move to the desired joint positions. However, this is merely one example, and in other surgical robot systems, the main controller 312 may perform different and / or additional functions.

[0054] For example, in some cases, the main controller 312 may perform one or more additional functions. For example, in some cases, the main controller 312 may also be configured to provide and / or control at least a portion of a graphical user interface provided to an operator for input. The main controller 312 may include one or more processors (not shown) and a memory (not shown). The memory stores software code in a non-transitory manner, which can be executed by one or more processors to generate control signals for the surgical robot 302 and optionally perform one or more additional functions.

[0055] exist Figure 3In this example, the control system 306 also includes a safety device 314 and optionally a safety monitor 316. The safety device 314, also known as the core safety oversight device (CSS), is a hardware device located between the main controller 312 and other components 302, 304 of the surgical robot system 300, allowing communication to and from the main controller 312 to pass through the safety device 314. Because communication to and from the main controller 312 passes through the safety device 314, the safety device 314 can control communication to and from the main controller 312. Specifically, when a fault condition is detected in the surgical robot system 300, the safety device 314 can prevent communication between the main controller 312 and one or more (or portions or components) of components 302, 304. In some cases, components or devices in the system communicating with the main controller 312 can be configured to receive communication from the main controller at predetermined intervals or frequencies, and automatically transition to a safe state if they stop receiving such communication for a period of time (e.g., a predetermined number of intervals). Therefore, cutting off communication between the main controller and the component or device can automatically switch the component or device to a safe state.

[0056] In some cases, safety device 314 may be operable to selectively filter communications destined for and / or originating from main controller 312 based on one or more filter criteria. In some cases, safety device 314 may include one or more programmable filters that may be programmed or configured to filter certain communications destined for and / or originating from main controller 312. In some cases, filters may be programmed to: not filter any communications destined for and originating from main controller 312; filter all communications destined for and originating from main controller 312 (i.e., cut off communication between main controller 312 and other components and devices of the system); and / or filter communications between main controller 312 and one or more specific components or devices (e.g., between main controller 312 and operator console 304 or a portion thereof, or between main controller 312 and surgical robot 302 or a portion thereof). As described in more detail below, when components and devices in surgical robot system 300 communicate with main controller 312 using TCP / IP packets, one or more filters may be configured to filter communications based on IP source, IP destination address, source UDP port, and / or destination UDP port.

[0057] In some cases, safety device 314 may be configured to filter at least a portion of communications destined for and / or from the main controller in response to detecting a fault in the surgical robot system 300. For example, if the main controller 312 sends a control signal to the surgical robot 302 that is inconsistent with the state of the surgical robot 302, the surgical robot system 300 may be considered to be in a fault state. Further examples of detectable fault states of the surgical robot system 300 are described below. In some cases, safety device 314 itself may be configured to detect when the surgical robot system 300 is in a fault state. In other cases, another device, such as safety monitor 316 (described below), may also be configured, or alternatively, to detect when the surgical robot system 300 is in a fault state.

[0058] In some cases, the main controller 312 can be implemented using a field-programmable gate array (FPGA). However, it will be apparent to those skilled in the art that this is merely one example. The following section discusses... Figure 5 An exemplary embodiment of the safety device 314 is described.

[0059] In some cases, such as Figure 3 As shown, the control system 306 may further include a safety monitor 316, which may also be referred to as a core safety monitor (CSM). The safety monitor 316 is configured to independently verify the operation of the main controller 312 and / or one or more other components and devices in the system by monitoring communications destined for and from the main controller 312. In these cases, a safety device 314 may be configured to send a copy of at least a portion of the communications destined for and / or from the main controller 312 to the safety monitor 316. The safety monitor 316 is then configured to analyze the received communications to determine whether the surgical robot system 300 is in a fault state. If the safety monitor 316 detects that the surgical robot system 300 is in a fault state, the safety monitor 316 may be configured to cause the safety device 314 to filter at least a portion of the communications destined for and / or from the main controller 312. See below for reference. Figure 8 An exemplary implementation of the security monitor 316 is described.

[0060] The communication links 308 and 310 between the control system 306 and other components (e.g., the operator console 304 and the surgical robot 302) can be any suitable communication link that enables data communication between the control system 306 and the components. Communication links 308 and 310 may all be of the same type, or at least two of them may be of different types. Examples of suitable communication links include, but are not limited to, wired communication links (e.g., Ethernet, Token Ring, or RS232 links) or wireless communication links (e.g., Wi-Fi, Bluetooth, Bluetooth LE, or NFC links).

[0061] Although Figure 3 An exemplary surgical robot system 300 includes a single surgical robot 302 with a single arm; however, it will be apparent to those skilled in the art that this is merely an example, and the methods and techniques described herein are equally applicable to surgical robot systems with more than one surgical robot or surgical robots with more than one arm.

[0062] Although Figure 3 The exemplary control system 306 includes a safety device 314 and a safety monitor 316, but in other instances, the control system 306 may include only the safety device 314 or only the safety monitor 316.

[0063] In some cases, the control system can be physically integrated into the operator console 304. In other cases, the main controller 312, safety device 314, and safety monitor 316 can be located on a single printed circuit board (PCB).

[0064] Surgical robots

[0065] Now for reference Figure 4 It shows that it can be used for implementation Figure 3 An exemplary surgical robot 400 is described above, comprising a surgical robot 302. The surgical robot 400 includes an arm 402 extending from a base 404, which is secured in place when a surgical procedure is being performed. In some cases, the base 404 may be mounted to a chassis. The chassis may be a trolley, such as a bedside trolley for mounting the robot at bed height. Alternatively, the chassis may be a device mounted on the ceiling or on the bed.

[0066] Arm 402 extends from the robot's base 404 to an attachment 406 for surgical instruments 408. The arm is flexible. It is hinged by means of a plurality of flexible joints 410 along its length. Between the joints is a rigid arm member 412. Figure 4The arm in the robot has seven joints. These joints include one or more roll joints (each having a rotational axis on either side of the joint along the longitudinal direction of the arm member), one or more pitch joints (each having a rotational axis transverse to the longitudinal direction of the preceding arm member), and one or more yaw joints (each also having a rotational axis transverse to the longitudinal direction of the preceding arm member and also transverse to the co-located pitch joint). However, the arm may engage differently. For example, the arm may have fewer or more joints. The arm may include joints that allow movement other than rotation between corresponding sides of the joint, such as telescopic joints. The robot includes a set of actuators 414, each actuator 414 driving one or more joints 410.

[0067] The attachment 406 allows the surgical instrument 408 to be releasably attached to the distal end of the arm. The surgical instrument 408 has a linear rigid axis and a working tip located at the distal end of this axis. The working tip includes an end effector for participating in a medical procedure. The surgical instrument can be configured to extend linearly parallel to the axis of rotation of the distal joint of the arm. For example, the surgical instrument can extend along an axis coinciding with the axis of rotation of the distal joint of the arm. The surgical instrument 408 can be, for example, a cutting device, a grasping device, a cauterizing device, or an image capturing device (e.g., an endoscope).

[0068] The robotic arm includes a series of sensors 416, 418. For each joint, these sensors include a position sensor 416 for sensing the position of the joint, and a torque sensor 418 for sensing the torque applied about the axis of rotation of the joint. One or both of the position sensor and the torque sensor for the joint may be integrated with a motor for that joint.

[0069] Safety devices

[0070] Now for reference Figure 5 It shows Figure 3 An exemplary embodiment of the safety device 314. As described above, the safety device 314 is located between the main controller 312 and other components of the surgical robot system 300, allowing communication to and / or from the main controller 312 to pass through the safety device 314. The safety device 314 is operable to selectively filter communication to and / or from the main controller 312.

[0071] exist Figure 5In one example, safety device 314 includes a receive (Rx) filter 502 and a transmit (Tx) filter 504, which are programmable filters that can be configured to selectively filter communications originating from and destined for the main controller 312, respectively. When the main controller 312 communicates with other components in the surgical robot system 300 using UDP, the Rx and Tx filters can be configured to filter UDP packets. However, it will be apparent to those skilled in the art that this is merely an example.

[0072] Rx filter 502 receives communication from host controller 312 and, if no Rx filter standard is specified, forwards all communication to other components, or filters communication according to one or more specified Rx filter standards. Rx filter standards specify rules for selecting, filtering, rejecting, or disallowing communication through security device 314. In some cases, one or more Rx filter standards may specify that all communication from host controller 312 will be filtered, or one or more Rx filter standards may specify that only communication matching a specified standard (e.g., source / destination IP address, source / destination UDP port, or a combination thereof) will be filtered. When an Rx filter standard specifies that all communication from host controller 312 will be filtered, Rx filter 502 may simply reject all communication it receives. However, when an Rx filter standard specifies that only communication matching a specified standard will be filtered, Rx filter 502 may be configured to compare each received communication with the specified standard to determine if a match exists. Specifically, in some cases, Rx filter 502 may be configured to compare each communication (e.g., a packet) with up to N different Rx filter standards, where N is an integer greater than or equal to one. As described in more detail below, N can be selected based on the number of comparisons that can be performed per cycle and the number of cycles spent receiving communication (e.g., packets).

[0073] The Rx filter standard is configurable. For example, in some cases, such as... Figure 5As shown, security device 314 may include a set of registers 506 specifying the criteria for the Rx filter. For example, when the main controller 312 communicates with other components in the surgical robot system 300 using UDP, the Rx filter 502 can filter communications (e.g., packets) based on one or more of the source IP address, destination IP address, source UDP port, and destination UDP port. In these cases, the set of registers 506 may include: a register indicating whether all communications will be filtered; and one or more registers for each possible comparison, indicating which combination of source IP address, destination IP address, source UDP port, and destination port will be compared with each communication (e.g., packet); and identifying the source IP address, destination IP address, source UDP port, and / or destination UDP port that will be used for comparison. For example, Table 1 shows an exemplary set of four 32-bit registers that can be used to specify the combination of source IP address, destination IP address, source UDP port, and destination UDP port to be compared with each communication (e.g., packet). The set of registers 506 may include four registers for each of the N comparisons that the Rx filter can perform on each communication (e.g., packet).

[0074] Table 1

[0075]

[0076] In some cases, such as Figure 5 As shown, the Rx filter 502 may include a buffer 508, such as a first-in-first-out (FIFO) queue, for storing received communications before they are forwarded to the main controller 312. (See below for more details.) Figure 6 In more detail, complete communications (e.g., packets) can be received over several cycles (e.g., clock cycles). To avoid introducing any delay when retransmitting the communications to other components or devices, the Rx filter 502 can be configured to complete its filter determination once the complete communications have been received. For example, if eight cycles are required to receive communications, the Rx filter 502 can be configured to determine whether to filter the communications over those eight cycles.

[0077] When Rx filter 502 identifies communication (e.g., packets) that will be filtered out (i.e., any communication, or any other communication that matches a specified filter criterion, if filtering is directed to master controller 312), Rx filter 502 is configured to reject the communication. In some cases, Rx filter 502 can reject communication by dropping it, i.e., not outputting or forwarding the communication to the appropriate device. However, in other cases, Rx filter 502 can be configured to reject communication by invalidating or destroying it. In some cases, Rx filter 502 can be configured to invalidate or destroy communication by altering the error detection portion of the communication, such as, but not limited to, the periodic redundancy check (CRC) portion of the communication. In contrast to dropping communication, invalidating or destroying communication can allow filtering to be performed more quickly (e.g., in real time).

[0078] Tx filter 504 operates in a similar manner to Rx filter 502. Specifically, Tx filter 504 receives communication directed to or addressed to host controller 312 and, if no Tx filter standard is specified, forwards all communication to host controller 312, or filters communication according to one or more specified Tx filter standards. Tx filter standards specify rules for selecting, filtering, rejecting, or disallowing communication through security device 314. In some cases, one or more Tx filter standards may specify that communication destined for host controller 312 will not be filtered, all communication destined for host controller 312 will be filtered, or only communication matching a specified standard (e.g., source / destination IP address, source / destination UDP port, or a combination thereof) will be filtered. When no Tx filter standard is specified, Tx filter 504 may forward all communication it receives to host controller 312. When a Tx filter standard specifies that all communication destined for host controller 312 will be filtered, Tx filter 504 may simply reject all communication it receives. However, when the Tx filter standard specifies that only communications matching the specified standard will be filtered, Tx filter 504 can be configured to compare each received communication with the specified standard to determine if a match exists. Similar to Rx filter 502, Tx filter 504 can be configured to compare each communication (e.g., a packet) with up to N distinct Tx filter standards, where N is an integer greater than or equal to one.

[0079] Like the Rx filter standard, the Tx filter standard is configurable. For example, a set of registers 506 can be used to specify which standards (if any) will be used to filter communication destined for the main controller 312. For instance, when the main controller 312 communicates with other components and devices in the surgical robot system 300 using UDP, the Tx filter 504 can filter communication (e.g., packets) based on one or more of the following: source IP address, destination IP address, source UDP port, and destination UDP port. In these cases, the set of registers 506 may include registers indicating whether all communication from the main controller 312 will be filtered; and one or more registers for each comparison, indicating which combination of source IP address, destination IP address, source UDP port, and destination port will be compared with each communication (e.g., packet); and identifying the source IP address, destination IP address, source UDP port, and / or destination UDP port to be used for comparison. For example, Table 1 shows an exemplary set of four 32-bit registers that can be used to specify the combination of source IP address, destination IP address, source UDP port, and destination UDP port to be compared with each communication (e.g., packet). A set of registers 506 may include four registers for each of the N comparisons that the Tx filter 504 can perform for each communication (e.g., packet).

[0080] In some cases, such as Figure 5 As shown, the Tx filter 504 may include a buffer (e.g., a first-in-first-out (FIFO) queue) 510 for storing communications received from other components or devices in the system before they are forwarded to the main controller 312. (See below for more details.) Figure 6 In more detail, complete communications (e.g., packets) can be received over several cycles (e.g., clock cycles). To avoid introducing any delay when retransmitting the communications to the master controller 312, the Tx filter 504 can be configured to complete its filter determination once the complete communications have been received. For example, if receiving communications requires 8 cycles, the Tx filter 504 can be configured to determine whether to filter the communications over those 8 cycles.

[0081] When Tx filter 504 identifies communication (e.g., packets) that will be filtered out (i.e., any communication, or otherwise, that matches a specified filter criterion if filtering is directed to the main controller 312), Tx filter 504 is configured to reject the communication. In some cases, Tx filter 504 can reject communication by dropping it, i.e., not outputting or forwarding the communication to the appropriate component or device. However, in other cases, Tx filter 504 can be configured to reject communication by invalidating or destroying it. In some cases, Tx filter 504 can be configured to invalidate or destroy communication by altering the error detection portion of the communication, such as, but not limited to, the periodic redundancy check (CRC) portion of the communication. In contrast to dropping communication, invalidating or destroying communication can allow filtering to be performed more quickly (e.g., in real time).

[0082] The following text is about Figure 6 describe Figure 5 An exemplary implementation of the transmit (Tx) filter 504 and the receive (Rx) filter 502.

[0083] In certain circumstances, the safety device 314 can receive and transmit communications from other devices or components in the system via the first communication interface 512; and can receive and transmit communications from the main controller 312 via the second communication interface 514. Figure 5 In the example shown, the first communication interface 512 and the second communication interface 514 are Ethernet interfaces. However, it will be apparent to those skilled in the art that this is merely an example, and in other examples, different communication interfaces may be used, and / or the first communication interface 512 and the second communication interface 514 may not be the same type of communication interface. In some cases, such as Figure 5 As shown, the first communication interface 512 can be connected to or coupled to a switch 515 (e.g., an Ethernet switch), through which the first communication interface receives communication from other components and devices of the system. For example, the operator console 304 and / or the surgical robot 302 can be directly or indirectly connected to the switch 515.

[0084] In cases where the control system 306 also includes a safety monitor 316, the receive (Rx) filter 502 and transmit (Tx) filter 504 can also be configured to forward copies of at least a portion of communications destined for and from the main controller to the safety monitor 316, allowing the safety monitor 316 to check whether the main controller 312 and / or one or more other components or devices in the surgical robot system 300 are operating as intended. In some cases, the Rx filter 502 and Tx filter 504 can be configured to forward all received communications between the main controller 312 and other components / devices in the system to the safety monitor 316, regardless of whether the communications are filtered by the Rx filter 502 or the Tx filter 504. However, in some cases, if filters 502, 504 forward filtered communications to the safety monitor 316, filters 502, 504 can notify the safety monitor 316 that the communications have been filtered.

[0085] In some cases, such as Figure 5 As shown, security device 314 can be configured to receive communications from security monitor 316 and transmit communications to security monitor 316 via a separate communication link 517 (e.g., a PCIe link) through security monitor communication interface 516. In some cases, such as Figure 5 As shown, the security monitor communication interface 516 can be a different type of communication interface from the first communication interface 512 and the second communication interface 514. For example, as Figure 5 As shown, the first communication interface 512 and the second communication interface 514 can be Ethernet interfaces, while the security monitor communication interface 516 can be a Peripheral Component Interconnect Fast (PCIe) interface. In such cases, the destination and / or communication from the host controller 312 forwarded to the security monitor 316 can be encapsulated in another protocol for provision to the security monitor 316. In some cases, such as Figure 5 As shown, security device 314 may include a set of buffers (e.g., FIFO queues) 518, 520 for storing copies of destinations and communications from host controller 312 that will be forwarded to security monitor 316. As those skilled in the art know, a PCIe link is a high-speed communication link or bus. Using a PCIe link allows for the fast and efficient transmission of destinations and copies of communications from host controller 312 to security monitor 316.

[0086] In addition to allowing for fast and efficient data transfer, using a separate communication link 517 (e.g., a PCIe link) instead of a shared Ethernet network to communicate with the security monitor 316 allows the security monitor 316 to be isolated from the rest of the devices in the system. This ensures that other devices do not interfere with the operation of the security monitor 316. Furthermore, using a separate communication link between the security device 314 and the security monitor 316 allows the security monitor 316 to listen to outgoing and incoming communications from the main controller 312, whereas if the security monitor 316 were simply connected to a main (e.g., Ethernet) network, the security monitor 316 would only be able to read communications (e.g., packets) addressed to it.

[0087] As described above, the safety monitor 316 is configured to analyze destinations and communications from the main controller 312 to determine whether the surgical robot system 300 is in a fault state. For example, the safety monitor 316 can be configured to determine that the surgical robot system 300 is in a fault state if communications from the main controller indicate that the surgical robot arm is linked to a manual controller other than the manual controller shown on the operator console display as being linked to that surgical robot arm. The following section discusses... Figure 8-10 An exemplary implementation of the safety monitor 316 is described, along with example fault states that the safety monitor 316 may detect.

[0088] In certain circumstances, if the safety monitor 316 detects that the surgical robot system 300 is in a fault state, the safety monitor 316 can be configured to cause the safety device 314 to filter all or a portion of the communication destined for and from the main controller 312. Depending on the type of fault detected, the safety monitor 316 can cause the safety device 314 to filter all communication destined for and / or from the main controller 312; or only filter a portion of the communication destined for and / or from the main controller 312 (e.g., communication between the main controller 312 and one or more devices / components). For example, if the fault state is one that can affect all parts of the system, then the safety monitor 316 can be configured to cause the safety device 314 to filter all communication destined for and from the main controller 312. In some cases, each device or component communicating with the main controller 312 can be configured to transition to a safe state if it does not receive regular communication (e.g., heartbeat communication) from the main controller 312. In these cases, filtering all communication destined for and from the main controller 312 can transition all other devices communicating with the main controller 312 to a safe state. In contrast, if the fault appears to be related to a specific device (e.g., a particular robot arm among multiple robot arms), the safety monitor 316 can be configured to cause the safety device 314 to filter only the communication between the main controller 312 and that specific device.

[0089] In some cases, the security monitor 316 can be configured to enable the security device 314 to filter all or part of the communication to and from the main controller by writing to the register 506 of the security device 314 with a specified filter standard.

[0090] In some cases, such as Figure 5 As shown, to allow high-throughput data transfer between the security device and the security monitor 316 to occur efficiently, the security device 314 may include direct memory access (DMA) 522 between the security monitor communication interface 516 and buffers (e.g., FIFO queues) 518, 520 and register 506. As those skilled in the art know, DMA is a means that allows input / output (I / O) devices to bypass the main processor and send data directly to or receive data directly from a memory unit (e.g., memory or buffer). DMA allows the main processor to perform other functions while performing data transfers. In this example, DMA allows data transfer between the security device 314 and the security monitor 316 with minimal interaction between the security device 314 and the security monitor 316.

[0091] exist Figure 5 In one example, the safety monitor 316 is configured to: identify that the surgical robot system 300 is in a fault state; cause the safety device 314 to filter at least a portion of the communications destined for and from the main controller 312; and specify filter criteria. However, in other examples, additionally or alternatively, one or more other components may be present in the surgical robot system 300 that are configured to detect that the surgical robot system 300 is in a fault state and cause the safety device 314 to filter all or a portion of the communications destined for and / or from the main controller; and / or additionally or alternatively, the safety device 314 itself may be capable of detecting that the surgical robot system 300 is in a fault state, which may trigger the safety device 314 to filter all or a portion of the communications destined for and / or from the main controller.

[0092] In some cases, such as Figure 5As shown, the safety device 314 may further include an alarm finite state machine (FSM) 524 for triggering alarms in the system, such as, but not limited to, audio alarms and / or visual alarms. For example, in some cases, the alarm FSM 524 may be connected to a control panel of an audio alarm device that can be used to issue audible alarms and / or a console that can be used to display visual alarms. In some cases, the alarm FSM may be controlled by the configuration of one or more registers in a set of registers 506. Specifically, in some cases, writing a value or set of values ​​to certain registers in a set of registers 506 may cause the alarm FSM 524 to trigger a first type of alarm, and writing a different value or set of values ​​to different registers in a set of registers may cause the alarm FSM 524 to trigger a second type of alarm. In some cases, the safety monitor 316 may be able to control the alarm FSM 524 by, for example, writing to appropriate registers in a set of registers 506, and thus control the alarms triggered by the safety device 524.

[0093] Now for reference Figure 6 It shows Figure 5 An exemplary implementation of the Rx filter 502 and Tx filter 504 is provided. In this example, each filter 502, 504 includes manifolds 602, 604, one or more matchers 606, 608, 610, 612, combinational logic 614, 616, buffers (e.g., FIFO queues) 508, 510, and MAC address control (MAC) logic 618, 620.

[0094] As those skilled in the art know, MAC logic is responsible for transmitting data packets to and from the communication interface. In this example, each MAC logic 618, 620 is configured to receive communication addressed to or from the main controller 312 from the communication interface and to provide the received communication to the corresponding manifold 602, 604. Specifically, the MAC logic 618 of the Rx filter 502 is configured to receive communication from the main controller 312 via the second communication interface 514 (e.g., Ethernet interface 0) and forward the received communication to the first manifold 602. Similarly, the manifold 604 of the Tx filter 504 is configured to receive communication addressed to the main controller 312 from other components or devices in the surgical robot system 300 via the first communication interface 512 (e.g., Ethernet interface 1) and forward the received communication to the second manifold 604.

[0095] Each manifold 602, 604 is configured to store a copy of each received communication in a corresponding buffer (e.g., FIFO queue) 508, 510. Specifically, manifold 602 of Rx filter 502 is configured to receive communication from main controller 312 and store a copy of each received communication in buffer (e.g., FIFO queue) 508. Communication stored in buffer (e.g., FIFO queue) 508 (e.g., if they are not filtered) can then be forwarded to another component or device. Similarly, manifold 604 of Tx filter 504 is configured to receive communication directed to main controller 312 from other components or devices in surgical robot system 300 and store a copy of each received communication in buffer (e.g., FIFO queue) 510. Communication stored in buffer (e.g., FIFO 510) (e.g., if they are not filtered) can then be forwarded to main controller 312.

[0096] Each manifold 602, 604 is also configured to extract information related to filtering the communication from each received communication and provide the extracted information to the corresponding matchers 606, 608, 610, 612. The information related to filtering is information or data in the communication used to determine whether the communication should be filtered. For example, in some cases, the master controller 312 can be configured to communicate via UDP and can filter each communication (e.g., each UDP packet) based on one or more of the following: source IP address, destination IP address, source UDP port, and destination UDP port. In these cases, each manifold 602, 604 can be configured to extract the source IP address, destination IP address, source UDP port, and / or destination UDP destination from the header of each received UDP packet and provide this information to the corresponding matchers 606, 608, 610, 612.

[0097] Each manifold 602, 604 is also configured to receive information from corresponding matchers 606, 608, 610, and 612 for each communication, indicating whether the communication matches at least one of the filter criteria and should therefore be rejected. If manifold 602, 604 receives information from corresponding matchers 606, 608, 610, and 612 indicating that a communication will be rejected, manifold 602, 604 may mark or identify a communication in buffers (e.g., FIFO queues) 508, 510 as a rejected communication. In some cases, manifold 602, 604 may store a token next to each communication (or each part of a communication) stored in buffers (e.g., FIFO queues) 508, 510. The token can identify whether a communication will be rejected, and if the communication has multiple parts, it can identify the parts of the communication. For example, when a communication can be received in a single cycle, the token stored next to the communication can simply indicate whether the communication will be rejected. However, when communication can be received over multiple cycles, tokens can be stored next to each part of the communication (e.g., the part received in each cycle). For example, a token can specify whether a part of the communication is the beginning of a communication (e.g., a packet), whether a part of the communication is the middle part of a communication (e.g., a packet), whether a part of the communication is the end of a communication (e.g., a packet) and has not been rejected, or whether a part of the communication is the end of a communication (e.g., a packet) and will be rejected.

[0098] If the control system 306 also includes a safety monitor 316, then as follows Figure 5 As shown, each manifold 602, 604 can also be configured to store a copy of each received communication in security monitor buffers (e.g., FIFO queues) 520, 518 for transmission to security monitor 316. Specifically, manifold 602 of Rx filter 502 can be configured to store a copy of each communication received from master controller 312 (e.g., those received via the first communication interface) in the first security monitor buffer (e.g., FIFO queue) 520. The communication stored in the first security monitor buffer (e.g., FIFO queue) 520 can then be transmitted to security monitor 316 (e.g., via security monitor communication interface 516). Similarly, manifold 604 of Tx filter 504 can be configured to store a copy of each communication destined for master controller 312 (e.g., those received via the second communication interface) in the second security monitor buffer (e.g., FIFO queue) 518. Then, the communication in the second security monitor buffer (e.g., FIFO queue) 518 can subsequently be transmitted to the security monitor 316 (e.g., via the security monitor communication interface 516).

[0099] Each matcher 606, 608, 610, 612 is configured to compare information received from manifolds 602, 604 for each communication with filter criteria to determine if a match exists. As described above, the filter criteria used by matchers 606, 608, 610, 612 can be identified by a set of registers 506. In some cases, each matcher 606, 608, 610, 612 can compare relevant information for a communication with multiple different sets of filter criteria. Each communication can be filtered based on one or more of the following: source IP address, destination IP address, source UDP port, and destination UDP port, and each set of filter criteria can include any combination of source IP address, destination IP address, source UDP port, and destination UDP port. However, it will be apparent to those skilled in the art that this is merely an example, and other criteria can be used to filter communications.

[0100] In some cases, matchers 606, 608, 610, and 612 can perform multiple comparisons within a single cycle (e.g., a clock cycle). For example, matchers 606, 608, 610, and 612 can compare communication-related information with two different sets of filter criteria within a single cycle (e.g., a clock cycle). However, in other cases, matcher 606 may only be able to compare communication-related information with a single set of filter criteria within a single cycle (e.g., a clock cycle).

[0101] In some cases, receiving a complete communication may require a single cycle (e.g., a clock cycle). However, in other cases, due to the limited amount of data that can be received per clock cycle, receiving a complete communication may require multiple cycles (e.g., clock cycles). In either case, it may be desirable to be able to determine whether a communication will be rejected (e.g., matching any filter criteria) before the communication ends, because it is permissible to mark or identify a communication as rejected (and optionally, the CRC will be modified or corrupted) before storing the entire communication in the corresponding buffers (e.g., FIFO queues) 520, 518. This can be described as performing filtering in real time. For example, if receiving a complete communication requires eight cycles, it may be desirable to perform all comparisons within those eight cycles (e.g., clock cycles). This can limit the number of comparisons that can be performed for each communication.

[0102] Therefore, in some cases, each filter 502, 504 may include multiple matchers 606, 608, 610, 612 to increase the number of comparisons that can be performed for each communication (e.g., packet). For example, in Figure 6In the example shown, each filter 502 and 504 includes two matchers 606, 608 and 610, 612. Given that receiving a complete communication requires eight cycles, and each matcher 606, 608, 610, and 612 can perform one comparison per cycle, this means that up to 16 comparisons can be performed for each communication. However, it will be apparent to those skilled in the art that this is merely one example, and in other examples, there may be more or fewer matchers 606, 608, 610, and 612.

[0103] If matchers 606, 608, 610, and 612 determine that the received information matches at least one set of filter criteria, then matchers 606, 608, 610, and 612 can output information indicating the existence of a match. In some cases, once matchers 606, 608, 610, and 612 have received a set of relevant information from the manifold, they can continue to output indications of whether the matcher has found relevant information for a matching filter criterion up to that point in time.

[0104] As in Figure 6 In an example where each filter 502, 504 includes multiple matchers 606, 608, 610, 612, each filter 502, 504 may include combinational logic 614, 616, configured to combine the outputs of the corresponding matchers 606, 608, 610, and 612 to provide a single input to the corresponding manifold 602, 604 indicating whether any of the matchers has identified a match for the communication. Figure 6 In this document, each combinational logic 614, 616 is implemented as an OR gate, but it will be apparent to those skilled in the art that this is merely an example and that combinational logic 614, 616 can be implemented in any suitable manner.

[0105] Each MAC logic 618, 620 is also configured to send all unrejected communications in the buffer of another filter to the main controller / another device via a communication link, and to reject all communications stored in that buffer that are marked or identified as rejected. MAC logic 618, 620 can reject a communication by not outputting it, or by corrupting the communication (e.g., by corrupting error codes in the communication, such as CRC codes). Specifically, MAC logic 618 of Rx filter 502 is configured to send all unrejected communications in buffer 510 of Tx filter 504 to the main controller via a second communication interface (e.g., Ethernet interface 0), and to reject all communications stored in buffer 510 that are marked or identified as rejected. Similarly, MAC logic 620 of Tx filter 504 is configured to send all unrejected communications in buffer 508 of Rx filter 502 to another device via a first communication interface (e.g., Ethernet interface 1), and to reject all communications stored in buffer 508 that are marked or identified as rejected.

[0106] With manifolds 602 and 604 configured to store tokens indicating whether a communication will be rejected alongside each communication and / or each part of a communication, each filter 502 and 504 may also include token (TKN) logic 622 and 624, which is configured to analyze the tokens associated with each communication or each part of a communication to determine whether a communication output from a buffer will be rejected, and if the token indicates that a communication will be rejected, cause the corresponding MAC logic 618 and 622 to reject the communication.

[0107] Now for reference Figure 7 It illustrates an exemplary method 700 for selectively filtering communications destined for and / or from the main controller 312, which can be provided by... Figure 3 The safety device 314 is implemented. Method 700 begins at block 702, where the safety device 314 receives communication destined for or from the main controller 312. Method 700 then proceeds to block 704, where the safety device 314 determines whether at least one filter standard is specified. In some cases, the safety device 314 may determine whether at least one filter standard is specified based on the configuration of one or more registers 506. If it is determined at block 704 that no filter standard is specified, method 700 proceeds to block 706. However, if it is determined at block 704 that at least one filter standard has been specified, method 700 proceeds to block 708.

[0108] At block 706, the safety device 314 outputs the received communication to the relevant device. For example, if the received communication is directed to the main controller 312, the received communication may be output to the main controller 312 (e.g., via a communication interface or communication connection). Similarly, if the received communication originates from the main controller 312, the received communication may be output to the appropriate device or component (e.g., via a communication interface or communication connection). Once the received communication has been output, method 700 may terminate, or method 700 may return to block 702, where the destination and / or another communication from the main controller 312 is received.

[0109] At block 708, security device 314 compares the received communication with one or more filter criteria to determine if a match exists and therefore the communication is rejected. Comparing the communication with one or more filter criteria may include extracting relevant information from the communication and comparing the relevant information with the filter criteria to determine if a match exists. The relevant information for the communication used for filtering purposes may be based on the filter criteria. For example, in the case where each communication is a UDP packet that can be filtered based on one or more of the following: source IP address, destination IP address, source UDP port, and destination UDP port, the relevant information for the communication (e.g., packet) is the source IP address, destination IP address, source UDP port, and destination UDP port. It will be apparent to those skilled in the art that this is merely an example and that communication may be filtered based on any of the data or information contained herein. Once the received communication has been compared with the filter criteria, method 700 proceeds to block 710.

[0110] At block 710, security device 314 determines whether the received communication matches at least one filter standard. If it is determined at block 710 that the communication matches at least one filter standard, method 700 proceeds to block 712. However, if it is determined at block 710 that the communication does not match any filter standard, method 700 proceeds to block 706, where security device 314 outputs the communication.

[0111] At block 712, after determining that communication matches at least one filter criterion, security device 314 rejects the communication. In some cases, rejecting communication may include discarding the communication (e.g., not outputting the communication). In other cases, rejecting communication may include destroying the communication so that it is not processed by the receiving device or component before being output. In some cases, destroying the communication may include destroying error codes in the communication (e.g., CRC codes). In some cases, error codes can be destroyed by setting all error codes to zero. As mentioned above, discarding communication may take more time than destroying communication. Therefore, destroying communication, in contrast to discarding communication, can allow filtering to be performed in real time. In other words, destroying communication that matches the filter criterion can allow filtering to be performed without adding any (or only adding minimal) delay. Once the received communication has been rejected, method 700 may end, or method 700 may return to block 702, where another communication is received, either destined for or from the main controller 312.

[0112] Safety monitor

[0113] Now for reference Figure 8 It shows Figure 3 An exemplary implementation of the safety monitor 316. The safety monitor 316 is a dedicated and physically separate component for monitoring the operation of a surgical robot system, particularly the main controller 312, based on communications destined for and / or from the main controller 312. Specifically, the safety monitor 316 is configured to receive copies of at least a portion of communications destined for and / or from the main controller 312; analyze the communications to determine whether the surgical robot system 300 is in a fault state; and, if the surgical robot system is determined to be in a fault state, to transition one or more devices in the system to a safe state. In some cases, the safety monitor 316 may be configured to transition one or more devices or components in the system to a safe state by having a safety device 314 filter at least a portion of communications destined for and / or from the main controller 312.

[0114] exist Figure 8In one example, the safety monitor 316 includes: a first buffer 802 and a second buffer 804 (e.g., a FIFO queue), the first and second buffers being used to store destinations and communications from the main controller 312, respectively; a memory 806; and a processor 808. In cases where the control system 306 includes a safety device 314, destinations and / or communications from the main controller 312 can be received from the safety device 314. The memory 806 is configured to store fault analysis code 810, which, when executed by the processor 808, causes the processor 808 to analyze the communications stored in the first buffer 802 and the second buffer 804 to determine whether the surgical robot system 300 is in a fault state based on one or more fault state criteria 812; and in response to determining that the surgical robot system 300 is in a fault state, to transition one or more devices in the surgical robot system 300 to a safe state. One or more devices transitioning to a safe state can be selected based on the type of fault state detected. For example, in some cases, only a single device in the surgical robot system 300 can be switched to a safe state, while in other cases, more than one or all of the devices in the surgical robot system 300 can be switched to a safe state.

[0115] As described above, in certain circumstances, devices in the surgical robot system 300 communicating with the main controller 312 (e.g., input device controller 305, display controller 307, or arm controller 309) can be configured to receive communication (e.g., heartbeat communication, etc.) from the main controller 312 at predetermined intervals or frequencies, and if a device (e.g., input device controller 305, display controller 307, or arm controller 309) does not receive such communication for a period of time (e.g., a predetermined number of intervals), the device can be configured to transition to a safe state. In some cases, a device can be said to be in a safe state when it no longer has any control or function in the movement of any part of the surgical robot. When the device is in a safe state, the patient will not be harmed due to device malfunction. In these cases, the safety monitor 316 can be configured to transition the device to a safe state by cutting off communication between the main controller 312 and the device.

[0116] like Figure 3As shown, when the control system 306 includes a safety device 314, which can be configured to filter communications destined for and / or from the main controller 312, a safety monitor 316 can be configured to transition the device to a safe state by causing the safety device 314 to filter communications between the main controller 312 and the device. The safety monitor 316 can be configured to cause the safety device 314 to filter communications between the main controller and a specific device by sending a control signal to the safety device 314, the control signal adjusting one or more filter criteria such that such communications are filtered. See reference... Figure 5 As described above, when the security monitor 316 includes a set of registers 506 specifying filter criteria for filtering communications, the security device 314 can be configured to filter communications by writing data to the set of registers 506 to filter communication between the main controller 312 and the device. (See above reference...) Figure 5 When a set of registers 506 includes a set of receive registers for each of a plurality of receive filter standards and a set of transmit registers for each of a plurality of transmit filter standards, the security monitor 316 may be configured to: (i) identify a set of currently unused receive registers and configure the identified set of registers to indicate filtering of communications from the master controller based on the source address and destination address, setting the source address to the address of the master controller and setting the destination address to the address of the relevant device; (ii) identify a set of currently unused transmit registers and configure the identified set of registers to indicate filtering of communications destined for the master controller based on the source address and destination address, setting the source address to the address of the relevant device and setting the destination address to the address of the master controller 312.

[0117] In some cases, such as Figure 8 As shown, the safety monitor 316 can receive communication and / or send control signals through one or more communication interfaces 812. Figure 8 In the example shown, the communication interface 812 is a PCIe interface; however, it will be apparent to those skilled in the art that this is merely an example and any suitable wired or wireless communication interface can be used.

[0118] Now for reference Figure 9 It shows a surgical robot system 300 for detecting (e.g., Figure 3An exemplary method 900 for diagnosing a surgical robot system 300 in a fault state, which may be implemented by a safety monitor 316. Method 900 begins at block 902, where the safety monitor 316 receives a copy of at least a portion of communications destined for and / or from the main controller 312. As described above, in the case where the control system 306 includes a safety device 314, a copy of at least a portion of communications destined for and / or from the main controller 312 may be received from the safety device 314. Method 900 then proceeds to block 904, where the safety monitor 316 analyzes the received communications to determine whether the devices in the system are operating as intended. Method 900 then proceeds to block 906, where it is determined based on the analysis performed in block 904 whether the surgical robot system 300 is in a fault state. If it is determined at block 906 that the surgical robot system 300 is in a fault state, method 900 proceeds to block 908, where the safety monitor 316 transitions one or more devices in the surgical robot system to a safe state. However, if it is determined at box 906 that the surgical robot system is not in a faulty state, then method 900 can end, or method 900 can return to box 902.

[0119] The safety monitor 316 can be configured to detect exemplary fault states, including but not limited to:

[0120] • A device that runs a software version that is incompatible with the software version running on the main controller;

[0121] • The communication frequency from the device to the main controller is lower than a predetermined threshold, or the communication frequency from the device's main controller is lower than a predetermined threshold;

[0122] • The main controller sends position or orientation commands to the surgical robot arm that is not in a predetermined state (e.g., engaged state);

[0123] • The calculations performed by the main controller are inconsistent with the system state — To verify the calculations performed by the main controller, the security monitor can perform the reverse calculations of the main controller;

[0124] More than one surgical robotic arm reported the same unique identifier;

[0125] The surgical robotic arm is reporting a unique identifier that does not match the unique identifier associated with the surgical robotic arm displayed in the graphical user interface on the operator's console monitor; and

[0126] • The surgical robot arm is commanded to move between a first position and a second position, wherein the movement between the first position and the second position will cause the surgical robot arm to exceed its maximum speed.

[0127] It will be apparent to those skilled in the art that these are merely examples, and that the safety monitor 316 can be configured to detect additional and / or different fault states based on destination and / or communication from the main controller 312. More detailed exemplary fault states that can be detected by the safety monitor 316 are described below.

[0128] In some cases, the security monitor 316 can also confirm that its own characteristics (e.g., software version) are compatible with the characteristics of the main controller 312 and / or the security device 312.

[0129] Main controller — Surgical robot arm — General purpose

[0130] In some cases, both the surgical robot arm (e.g., its arm controller) and the main controller can run or execute software, and the version of the software currently running on the arm or main controller can be included in communications from the device. In some cases, certain versions of the arm controller software may only be compatible with certain versions of the main controller software. In these cases, the safety monitor 316 can be configured to: determine, based on the destination and communications from the main controller, whether the main controller has established a communication connection with the surgical robot arm (e.g., its arm controller); and if it is determined that the main controller has established a communication connection with the surgical robot arm, determine, based on the destination and communications from the main controller, whether the version of the software running on the surgical robot arm is compatible with the version of the software running on the main controller. If it is determined that the software versions are incompatible, the safety monitor 316 can be configured to determine that a fault state exists. In response to determining the existence of such a fault state, the safety monitor 316 can transition the surgical robot arm to a safe state. In some cases, the safety monitor 316 can be configured to transition the surgical robot arm to a safe state by having the safety device 314 filter all communications between a specific surgical robot arm and the main controller.

[0131] In some cases, the surgical robot arm (e.g., its arm controller) is expected to respond to control communications from the main controller within a predetermined time period (e.g., 1000 microseconds) when operating as intended. In these cases, the safety monitor 316 can be configured to verify that the delay between the control communication from the main controller 312 to the surgical robot arm (e.g., its arm controller) and the return communication does not exceed a predetermined threshold (e.g., 1000 milliseconds). In some cases, the main controller can be configured to include a delay count in the communication when it issues a control command to the surgical robot arm, and the surgical robot arm (e.g., its arm controller) is configured to include a delay count when it responds to the control communication. In these cases, the safety monitor 316 can be configured to identify the delay between the control packet issued by the main controller 312 to the surgical robot arm (e.g., its arm controller) and the surgical robot's response based on the delay count. If the safety monitor 316 determines that the delay exceeds the predetermined threshold, the safety monitor 316 can determine that the surgical robot system 300 is in a fault state. In response to determining such a fault state, the safety monitor 316 can be configured to transition the surgical robot arm to a safe state. In some cases, the safety monitor 316 can be configured to transition the surgical robot arm to a safe state by having the safety device 314 filter all communication between a particular surgical robot arm and the main controller.

[0132] In certain situations, when the main controller issues a command (which may be referred to herein as a posture command) to the surgical robot arm (e.g., its arm controller) to move the surgical robot arm, the main controller can be configured to issue the posture command to the surgical robot arm at a specific frequency (e.g., 2.5 kHz + / - 20%) when operating as intended, and the surgical robot arm is configured to generate a response to the posture command at the same frequency (e.g., 2.5 kHz + / - 20%) when operating as intended. In these cases, the safety monitor 316 can be configured to determine the timing of the posture command issued by the main controller 312 to the surgical robot arm based on the destination and communication from the main controller. In some cases, the communication from the main controller and the surgical robot arm may have a field indicating whether the communication includes a posture command, and the safety monitor 316 can be configured to determine whether the main controller issued a posture command to the surgical robot arm based on this field. If the safety monitor 316 determines that the main controller 312 is issuing attitude commands to the surgical robot arm, the safety monitor can determine, based on the destination and communication from the main controller, whether the main controller 312 is issuing attitude commands at a predetermined frequency; and whether the associated surgical robot arm is issuing or sending responses to the attitude commands at a predetermined frequency. In some cases, the safety monitor can be configured to determine that the main controller 312 or the associated surgical robot arm is not issuing attitude commands or responses at a predetermined frequency if the frequency of the attitude commands or responses is lower than the predetermined frequency within a predetermined number (e.g., 3) of consecutive time windows of a predetermined length (e.g., 5 ms).

[0133] If the safety monitor 316 determines that the main controller 312 is not issuing attitude commands at a predetermined frequency, or that the relevant surgical robot arm is not sending responses to attitude commands at a predetermined frequency, the safety monitor 316 can determine that the surgical robot system 300 is in a fault state. In response to determining the existence of such a fault state, the safety monitor 316 can be configured to transition the relevant surgical robot arm to a safe state. In some cases, the safety monitor 316 can be configured to transition the surgical robot arm to a safe state by having the safety device 314 filter all communication between the relevant surgical robot arm and the main controller.

[0134] In some cases, communication transmitted from the main controller to the surgical robot arm may include a field indicating the time elapsed since the main controller began transmitting the communication. When the main controller is operating as expected, the time indicated in this field should increase. In these cases, the safety monitor 316 can be configured to monitor this field and, if the time does not increase, determine that the surgical robot system 300 is in a fault state. In response to determining this fault state, the safety monitor 316 can be configured to transition all surgical robot arms to a safe state. In some cases, the safety monitor can be configured to transition the surgical robot arms to a safe state by having the safety device 314 filter all communication between the main controller and all surgical robot arms.

[0135] In some cases, the main controller 312 can be configured to send attitude commands only to surgical robotic arms in a specific mode when operating as intended, a mode which may be referred to herein as a surgically engageable mode. In some cases, the surgical robotic arm may be in a surgically engageable mode if it is currently linked to an input device controlled by an operator (e.g., a manual controller). In these cases, a safety monitor can be configured to determine, based on destination and communication from the main controller, whether the main controller stops sending attitude commands to any surgical robotic arm within a predetermined time (e.g., 2 ms) after the surgical robot is no longer in a specific mode (e.g., surgically engageable mode). If the safety monitor determines that the main controller has sent attitude commands to the surgical robotic arm outside a predetermined time period after the arm is no longer in a specific mode (e.g., surgically engageable mode), the safety monitor 316 can determine that the surgical robot system is in a fault state. In response to determining the existence of such a fault state, the safety monitor can be configured to transition the relevant surgical robotic arm to a safe state. In some cases, the safety monitor can be configured to transition the relevant surgical robot arm to a safe state by having safety device 314 filter all communication between the main controller and the relevant surgical robot arm.

[0136] As described above, the main controller 312 can be configured to receive information indicating the position and orientation of an input device (e.g., a manual controller) when linked to the surgical robot arm. The main controller 312 can then be configured to generate the position and orientation of the surgical robot arm's wrist (which may be collectively referred to as wrist pose) based on the position and orientation of the input device, and send wrist position and orientation command information to the surgical robot arm (e.g., its arm controller) to cause the surgical robot arm (e.g., its arm controller) to move the robot such that the robot's wrist has the desired position and orientation. The surgical robot arm (e.g., its arm controller) can then determine joint positions and angles to achieve the desired wrist position and orientation, and move the joints to the determined positions. The surgical robot arm (e.g., its arm controller) can then report the final wrist position and orientation based on data received from sensors (e.g., position and / or torque sensors). In some cases, the wrist orientation can be defined by a wrist orientation matrix R. In some cases, when the main controller 312 is working as intended, it should not command the surgical robot arm wrist to move its position beyond a predetermined amount (e.g., 2 mm) or move its orientation beyond a predetermined amount (relative to matrix R, 1.0e-2 element level).

[0137] In these cases, the safety monitor 316 can be configured to determine, based on the destination and communication from the main controller, whether the main controller 312 has commanded a wrist position or orientation exceeding a predetermined amount (e.g., 2 mm) of a reference wrist position reported by the surgical robot arm (e.g., its arm controller) or a predetermined amount (e.g., 1.0e-2 element level) of a reference wrist orientation reported by the surgical robot arm before the main controller 312 issued the command. If the safety monitor 316 determines that the main controller has sent a wrist position or wrist orientation command to the surgical robot arm, wherein the difference between the position or orientation and the reported wrist reference position or orientation is greater than a predetermined threshold, the safety monitor 316 can determine that the surgical robot system 300 is in a fault state. In response to determining the existence of such a fault state, the safety monitor can be configured to transition the relevant surgical robot arm (e.g., its arm controller) to a safe state. In some cases, the safety monitor can be configured to transition the relevant surgical robot arm to a safe state by having the safety device 314 filter all communication between the main controller and the relevant surgical robot arm.

[0138] In some cases, the safety monitor 316 can also be configured to verify, based on the destination and communication from the main controller, whether any wrist orientation matrix R transmitted as part of a wrist orientation command to the surgical robot arm (e.g., its arm controller) is properly formed—that is, orthogonal. The main controller 312 may generate non-orthogonal matrices due to, for example, computational errors, signal interference, or other types of errors. If R*transpose(R) = identity matrix within a certain threshold (e.g., on the order of 1.0e-6 elements), the wrist orientation matrix R can be considered properly formed (i.e., orthogonal). If the safety monitor 316 determines that the wrist orientation matrix R transmitted as part of a wrist orientation command to the surgical robot arm (e.g., its arm controller) is not properly formed, the safety monitor 316 can determine that the surgical robot system is in a fault state. In response to detecting such a fault state, the safety monitor can be configured to transition the relevant surgical robot arm (e.g., its arm controller) to a safe state. In some cases, the safety monitor can be configured to transition the relevant surgical robot arm to a safe state by having safety device 314 filter all communication between the main controller and the relevant surgical robot arm.

[0139] As mentioned above Figure 1 As described above, when the surgical robot system is being used to perform a surgical procedure, surgical instruments attached to the surgical robot arm can pass through the patient's body at the port to approach the surgical site. In some cases, such as... Figure 10 As shown, a point 1002 within the port 1004 through which the axis 1006 of the surgical instrument 1008 should preferably pass can be determined in order to minimize the force or pressure applied to the port and thus to the patient. This point 1002 may be referred to herein as a virtual pivot point (VPP). An exemplary method for identifying a VPP is described in the applicant's UK Patent No. GB2533004, which is incorporated herein by reference in its entirety. In such cases, a master controller can be configured to control the surgical robotic arm such that the axis of any instrument attached to it passes through the corresponding VPP.

[0140] Safety monitor 316 may be configured to identify the VPP of each port and to monitor destinations and communications from the main controller to determine whether the main controller issues instructions or commands to the surgical robot arm that would move the surgical robot arm to a position where the vertical distance 1010 from the centerline 1012 of the axis 1006 of the instrument 1008 attached to the surgical robot arm to the VPP 1002 is greater than a predetermined threshold (e.g., 35 mm). If safety monitor 316 determines that the vertical distance exceeds the predetermined threshold, then safety monitor 316 can determine that the surgical robot system 300 is in a fault state. In response to detecting such a fault state, safety monitor 316 may be configured to transition the relevant surgical robot arm to a safe state. In some cases, safety monitor 316 may be configured to transition the relevant surgical robot arm to a safe state by having safety device 314 filter all communications between the main controller and the relevant surgical robot arm.

[0141] To ensure that the surgical instrument attachment portion of the surgical robot arm does not press against the surgical port and therefore not against the patient, the safety monitor 316 may also, or alternatively, be configured to monitor the direction of travel and communication from the main controller 312 to determine whether the main controller issues an instruction or command to the surgical robot arm that would move the surgical robot arm to a position where the distance between the base of the axis (the portion of the axis closest to the surgical instrument attachment) and the VPP of the corresponding port is less than a predetermined threshold (e.g., 10 mm). If the safety monitor 316 determines that this distance has fallen below the predetermined threshold, the safety monitor 316 can determine that the surgical robot system 300 is in a fault state. In response to determining the existence of such a fault state, the safety monitor 316 can be configured to transition the relevant surgical robot arm to a safe state. In some cases, the safety monitor can be configured to transition the relevant surgical robot arm to a safe state by having the safety device 314 filter all communication between the main controller and the relevant surgical robot arm.

[0142] In some cases, each surgical robot arm in a surgical robotic system can be assigned a unique identifier presented to the operator. For example, in some cases, each surgical robot in a surgical robotic system can be assigned a unique color, and the surgical robot arm is configured to display its assigned color, and each surgical robot arm can be identified by its unique color on the operator's console display. For example, each surgical robot may have a light-emitting diode (LED) or a set of LEDs that can be configured to display one of a variety of colors. In these cases, the surgical robot can be configured to include its assigned unique identifier (e.g., the assigned color) in communications to the main controller. If multiple surgical robot arms indicate that they have been assigned the same unique identifier (e.g., color), this can cause problems or confusion when the operator (e.g., a surgeon) is trying to select which arm to control. Therefore, a safety monitor 316 can be configured to monitor communications to and from the main controller to determine whether multiple surgical robots indicate the same unique identifier (e.g., color) within a predetermined window (e.g., 100 milliseconds). If safety monitor 316 determines that more than one surgical robot arm has reported the same unique identifier (e.g., color), then safety monitor 316 can determine that the surgical robot system 300 is in a fault state. In response to detecting such a fault state, safety monitor 316 can be configured to transition the relevant surgical robot arm (i.e., the surgical robot arm reporting the same unique identifier) ​​to a safe state. In some cases, the safety monitor can be configured to transition the relevant surgical robot arm to a safe state by having safety device 314 filter all communication between the main controller and the relevant surgical robot arm.

[0143] As described above, in some cases, the main controller may provide a unique identifier for each surgical robot arm to the operator console's display (e.g., its video processor), allowing each surgical robot arm to be identified by the unique identifier in the display. In these cases, as a supplement or alternative to detecting that more than one surgical robot arm is reporting the same unique identifier, the safety monitor 316 may be configured to monitor destinations and communications from the main controller to determine whether the unique identifier reported by each surgical robot arm matches the unique identifier reported to the operator console display for that surgical robot arm. If the safety monitor 316 determines that the unique identifier (e.g., color) reported by the surgical robot arm does not match the unique identifier (e.g., color) provided to the display for the surgical robot arm, the safety monitor 316 may determine that the surgical robot system 300 is in a fault state. In response to detecting such a fault state, the safety monitor 316 may be configured to transition the relevant surgical robot arm (i.e., the surgical robot arm with the mismatched unique identifier) ​​to a safe state. In some cases, the safety monitor 316 may be configured to transition the relevant surgical robot arm to a safe state by having the safety device 314 filter all communications between the main controller and the relevant surgical robot arm.

[0144] Surgical robotic systems are commonly used in endoscopic surgeries (e.g., laparoscopic surgery), which can also be referred to as minimally invasive surgery. As those skilled in the art know, during an endoscopic procedure, a surgeon inserts an endoscope through a small incision or natural opening in the body (e.g., but not limited to the mouth or nostril). The endoscope is a rigid or flexible tube to which a tiny camera is attached, transmitting real-time images to a video monitor (e.g., display 206), which the surgeon uses to help guide his instruments through the same incision / opening or through different incisions / openings. Endoscopy allows surgeons to view relevant areas of the body in detail without having to cut openings and expose those areas. This technology allows surgeons to see inside the patient's body and operate through incisions much smaller than would be expected in conventional open surgery. Therefore, in a typical robotic endoscopic surgery, an endoscope is attached to a surgical robotic arm, and one or more surgical instruments (e.g., a pair of forceps and / or a scalpel) are attached to one or more other surgical robotic arms. Because endoscopes provide the operator (e.g., a surgeon) with a view of the surgical site, operating a surgical robot may be unsafe unless the endoscope is attached to one of the surgical robot arms and is operated as intended.

[0145] When a surgical robot arm is configured to report the type of tool attached to it (e.g., surgical instrument or endoscope), safety monitor 316 can be configured to determine, based on destination and communication from the main controller, whether an endoscope is attached to one of the surgical robot arms, and if so, whether the endoscope is operating as intended. If safety monitor 316 determines that an endoscope is not attached to one of the surgical robot arms, or that the attached endoscope is not operating as intended, then safety monitor 316 can determine that the surgical robot system 300 is in a fault state. In response to detecting such a fault state, safety monitor 316 can be configured to transition all surgical robot arms to a safe state. In some cases, the safety monitor can be configured to transition the surgical robot arms to a safe state by having safety device 314 filter all communication between the main controller and the surgical robot arms.

[0146] As described above, in some cases, an operator (e.g., a surgeon) can control the movement and / or position of a surgical robotic arm (and the surgical instruments / endoscopes attached thereto) by providing input via an input device (e.g., but not limited to, a manual controller). In some cases, a surgeon can control a specific surgical robotic arm by linking an input device (e.g., a manual controller) to that specific surgical robotic arm (e.g., via an operator console). In some cases, if the surgical robotic system detects that an endoscope is not attached to the surgical robotic arm, or that the attached endoscope is not functioning as intended, any manual controllers should be disconnected from the surgical robotic arm within a predetermined time period (e.g., 5 ms). In these cases, the safety monitor 316 can be configured to determine, based on destination and communication from the main controller, whether an endoscope is attached to one of the surgical robotic arms, and if so, whether the endoscope is functioning as intended. If safety monitor 316 determines that an endoscope is not attached to one of the surgical robot arms, or that the attached endoscope is not functioning as expected, then safety monitor 316 can determine, based on destination and communication from the main controller, that the surgical robot system 300 is in a fault state if an input device remains linked to the surgical robot system after a predetermined time (e.g., 5 ms) following the detection. In response to detecting such a fault state, safety monitor 316 can be configured to transition all surgical robot arms to a safe state. In some cases, the safety monitor can be configured to transition the surgical robot arms to a safe state by having safety device 314 filter all communication between the main controller and the surgical robot arms.

[0147] In some cases, it may not be desirable to move the surgical robot arm too quickly or too rapidly. Therefore, the main controller 312 can be configured to move the surgical robot arm (e.g., the wrist of the surgical robot arm) no more than a predetermined speed limit (e.g., 0.25 m / s) when operating as intended. In such cases, the safety monitor 316 can be configured to determine, based on the destination and communication from the main controller, whether the main controller is causing the surgical robot arm to move faster than the predetermined speed limit (within acceptable tolerances, such as, but not limited to, + / - 10%). In some cases, the main controller 312 can be configured to move the surgical robot arm by issuing a sequence of position or orientation commands, each command indicating the position or orientation to which the surgical robot arm (or the wrist of the surgical robot arm) will move. In these cases, the safety monitor 316 can be configured to determine that the main controller has issued a command to move the surgical robot arm faster than the predetermined speed limit if the safety monitor detects that the difference between two consecutive orientations commanded by the main controller 312 results in a speed exceeding the predetermined speed limit (e.g., within a 10% threshold).

[0148] If the safety monitor 316 determines that the main controller has issued a command that causes the surgical robot arm (e.g., its wrist) to exceed a predetermined speed limit, the safety monitor 316 can determine that the surgical robot system 300 is in a fault state. In response to detecting such a fault state, the safety monitor 316 can be configured to transition the relevant surgical robot arm (which would cause the surgical robot to exceed the predetermined speed threshold) to a safe state. In some cases, the safety monitor can be configured to transition the surgical robot arm to a safe state by having the safety device 316 filter all communication between the main controller and the relevant surgical robot arm.

[0149] Main controller—the surgical robotic arm with the surgical instruments attached to it.

[0150] In some cases, different rules may be applied to surgical robotic arms with surgical instruments attached to them, compared to surgical robotic arms with endoscopes attached to them.

[0151] As described above, in some cases, each surgical robotic arm can be assigned a unique identifier (e.g., a unique color) by the main controller 312. In some cases, surgical robotic arms with an endoscope attached to them can be consistently assigned the same unique identifier. In other words, in some cases, a specific unique identifier can be reserved for surgical robotic arms with an endoscope attached to them. For example, a surgical robotic arm with an endoscope attached to it can be assigned white. As described above, the surgical robotic arm can be configured to include the unique identifier assigned to it in at least some communications to the main controller 312. If a surgical robotic arm without an endoscope attached to it (e.g., one with surgical instruments attached to it) does not report the specific unique identifier (e.g., color) reserved for the endoscope arm, the system may not function as intended.

[0152] Therefore, safety monitor 316 can be configured to determine, based on destination and communication from main controller 312, whether a surgical robot arm without an attached endoscope reports as having a unique identifier (e.g., color) reserved for a surgical robot arm with an attached endoscope. If safety monitor 316 determines that a surgical robot arm without an attached endoscope reports as having a unique identifier (e.g., color) reserved for a surgical robot arm with an attached endoscope, safety monitor 316 can determine that surgical robot system 300 is in a fault state. In response to detecting such a fault state, safety monitor 316 can be configured to transition the relevant surgical robot arm (the surgical robot incorrectly reported as having a unique identifier reserved for a surgical robot arm with an attached endoscope) to a safe state. In some cases, safety monitor 316 can be configured to transition the relevant surgical robot arm to a safe state by having safety device 314 filter all communication between the main controller and the relevant surgical robot arm.

[0153] In some cases, the main controller 312 can be configured to control a maximum number (e.g., three or four) of instrumental robotic arms (i.e., robotic arms with surgical instruments attached to them, relative to an endoscope) when it is operating as intended. In these cases, the safety monitor 316 can be configured to determine, based on destination and communication from the main controller 312, whether the main controller 312 has issued control commands to more than the maximum number of instrumental robotic arms within a predetermined time period (e.g., a 1-millisecond window). If the safety monitor 316 determines that the main controller 312 has issued commands to more than the maximum number of instrumental robotic arms, then the safety monitor 316 can determine that the surgical robot system 300 is in a fault state. In response to detecting such a fault state, the safety monitor 316 can be configured to transition all robotic arms to a safe state. In some cases, the safety monitor 316 can be configured to transition the robotic arms to a safe state by having a safety device 314 filter all communication between the main controller and the robotic arms.

[0154] In some cases, one or more surgical instruments attached to a surgical robot arm may be actuable; that is, the end effector of the surgical instrument may be actuable or movable. In some cases, actuation may be transmitted from the surgical robot to the instrument to move the end effector through one or more drive interface elements on the instrument attachment, which engage corresponding instrument interface elements on the instrument. In some cases, the drive interface elements may be linearly movable. The main controller 316 may be configured to command the surgical robot arm to move the end effector of the attached instrument to a desired pose or position based on input received from the input device by commanding the surgical robot arm to move one or more of the drive interface elements to certain positions. To ensure that the main controller 316 does not issue commands that would cause the instrument end effector to move at a speed exceeding a predetermined threshold, a safety monitor 316 may be configured to determine, based on destination and / or communication from the main controller 316, whether the commanded position of any of the drive interface elements differs from a reference position of that drive interface element reported by the surgical robot arm (e.g., its arm controller) prior to the command by more than a predetermined amount (e.g., 0.1 mm). If the safety monitor 316 determines that the main controller 312 has issued a command causing one or more drive interface elements to move beyond a predetermined amount, the safety monitor 316 can determine that the surgical robot system 300 is in a fault state. In response to detecting such a fault state, the safety monitor 316 can be configured to transition the relevant surgical robot arm to a safe state. In some cases, the safety monitor 316 can be configured to transition the surgical robot arm to a safe state by having the safety device 314 filter all communication between the main controller and the relevant surgical robot arm.

[0155] As described above, in some cases, an operator (e.g., a surgeon) can control the movement and / or position of a surgical robotic arm (and the surgical instruments / endoscopes attached thereto) by providing input via an input device (e.g., but not limited to, a manual controller). In some cases, a surgeon can control a specific surgical robotic arm by linking an input device (e.g., a manual controller) to that specific surgical robotic arm (e.g., via an operator console). If the system is functioning as intended, the input device (e.g., the manual controller) is linked to the surgical robotic arm; then, the operator (e.g., the surgeon) provides input to the main controller via the input device, instructing the desired position / movement of the surgical robotic arm; and then the main controller issues commands to the surgical robotic arm to move it as needed. Thus, when the main controller is functioning as intended, control commands are only issued to the surgical robotic arm actively linked to the input device (e.g., the manual controller).

[0156] In some cases, the main controller 312 can be configured to include the input device currently linked to the surgical robot arm (e.g., a manual controller) in any communication sent to the surgical robot arm to cause its movement. The safety monitor 316 can then be configured to determine, based on the destination and communication from the main controller 312, whether the main controller 312 has issued a control command to the surgical robot arm without specifying the input device currently linked to it (e.g., a manual controller). If the safety monitor 316 determines that the main controller 312 has issued a command to the surgical robot arm without specifying the input device currently linked to it (e.g., a manual controller), the safety monitor 316 can determine that the surgical robot system 300 is in a fault state. In response to detecting such a fault state, the safety monitor 316 can be configured to transition the relevant surgical robot arm to a safe state (e.g., a surgical robot arm to which the main controller has issued a posture command without specifying the input device linked to it (e.g., a manual controller)). In some cases, the safety monitor 316 can be configured to bring the relevant surgical robot arm into a safe state by having the safety device 314 filter all communications between the main controller and the relevant surgical robot arm.

[0157] As described above, in some cases, the operator can select which surgical robot arm to control using a specific input device (e.g., a manual controller) via a graphical user interface presented to the operator, for example, on a monitor on an operator console. In some cases, the safety monitor 316 can be configured to identify which surgical robot arm the operator has linked to an input device (e.g., a manual controller) based on destination and communication from the main controller 312, and determine whether the main controller considers the surgical robot arm to be linked to a different input device (e.g., a manual controller). If the safety monitor 316 determines that the main controller 312 has instructed the operator to connect the surgical robot arm to an input device (e.g., a manual controller) different from the input device linked to the surgical robot arm, the safety monitor 316 can determine that the surgical robot system 300 is in a fault state. In response to detecting such a fault state, the safety monitor 316 can be configured to transition all surgical robot arms to a safe state. In some cases, the safety monitor 316 can be configured to transition the surgical robot arms to a safe state by having the safety device 314 filter all communication between the main controller and the surgical robot arms.

[0158] In some cases, even after the surgical robot arm has been linked to an input device (e.g., a manual controller) by an operator (e.g., via a graphical user interface), the input device (e.g., the manual controller) may only be used to control the linked surgical robot arm if it is in a specific state, which may be referred to herein as the engaged state. In other cases, the input device (e.g., the manual controller) may only be in a specific state (e.g., the engaged state) if one or more conditions are met, such as, but not limited to, operator contact with the input device (e.g., operator's palm engaging the manual controller), the manual controller being fault-free, and the operator not (e.g., via pressing a specific button) indicating that they wish to place the input device in a disengaged state. Therefore, if the main controller 312 issues a movement command (e.g., a posture command) to the surgical robot, and the input device (e.g., the manual controller) linked to the surgical robot is not in a predetermined state (e.g., the engaged state) for controlling the surgical robot arm, this may indicate that the main controller is not operating as intended.

[0159] Therefore, the safety monitor 316 can be configured to identify the current state of the input device based on its destination and communications from the main controller 312, and determine whether the main controller has issued a movement command (e.g., a posture command) to the surgical robot arm, to which the input device is linked is not in a predetermined state (e.g., an engaged state) for controlling the surgical robot arm. If the safety monitor 316 determines that the main controller 312 has issued a movement command to the surgical robot arm, and the input device linked to the surgical robot is not in a predetermined state, the safety monitor 316 can determine that the surgical robot system 300 is in a fault state. In response to detecting such a fault state, the safety monitor 316 can be configured to transition the relevant surgical robot arm (the surgical robot arm to which the main controller has incorrectly issued a movement command) to a safe state. In some cases, the safety monitor 316 can be configured to transition the relevant surgical robot arm to a safe state by having the safety device 314 filter all communications between the main controller and the relevant surgical robot arm.

[0160] In some cases, the main controller 312 can be configured to translate the movement of an input device (e.g., a manual controller) into movement of an instrument end effector by applying a scaling factor to the movement of the input device. For example, if the movement of the input device is represented by X, the main controller 312 can cause the end effector to move kX, where k is the scaling factor. In some cases, for the benefit of the safety monitor 316, the scaling factor can be included in communications from the main controller and the surgical robot arm (e.g., its controller). In such cases, the safety monitor 316 can be configured to determine, based on the destination and / or communications from the main controller 312, whether the main controller 312 has issued a posture command to the surgical robot arm that is inconsistent with one of a plurality of acceptable or possible scaling factors. If the safety monitor 316 determines that the main controller 312 has issued a command instruction to the surgical robot arm that is inconsistent with one of a plurality of acceptable or possible scaling factors, the safety monitor 316 can determine that the surgical robot system 300 is in a fault state. In response to the detection of such a fault condition, the safety monitor 316 can be configured to transition the relevant surgical robot arm (the surgical robot arm to which the main controller erroneously issues movement commands) to a safe state. In some cases, the safety monitor 316 can be configured to transition the relevant surgical robot arm to a safe state by having the safety device 314 filter all communication between the main controller and the relevant surgical robot arm.

[0161] In some cases, an operator (e.g., a surgeon) can be configured to instruct the desired position and / or movement of a surgical instrument attached to a robotic arm via a motion input device (e.g., a manual controller). The controller 312 can then be configured to determine the instrument tip orientation (i.e., position (x, y, z) and orientation) based on input received from the input device (e.g., the manual controller), the endoscope pose (i.e., position (x, y, z) and orientation), and a scaling factor (described above) associated with the operator input; then, based on the VPP, determine the wrist orientation and instrument yaw and instrument pitch to achieve the calculated instrument tip orientation, and command the robotic arm to move to the determined wrist orientation. As described above, the VPP is the point through which the instrument's axis should preferably pass to reduce the forces applied to the port and thus to the patient.

[0162] In some cases, the main controller 312 can be configured to output its calculated instrument tip posture. In such cases, the safety monitor 316 can be configured to verify the main controller 312's calculation of the surgical instrument tip posture based on the destination and communication from the main controller. Specifically, the safety monitor 316 can be configured to identify, based on the destination and communication from the main controller 312, the input provided by the input device (e.g., manual controller input), the endoscope posture (i.e., position and orientation), the scaling factor (described above), and the surgical instrument tip posture calculated by the main controller 312. The safety monitor 316 can then perform a reverse calculation from the calculated instrument tip posture to identify an estimate of the input. The safety monitor 316 can then be configured to compare the actual input with the estimated input to determine whether they are within each other's predetermined acceptable range. If the safety monitor determines that the actual input and the estimated input are not within each other's predetermined acceptable range, then the safety monitor 316 can determine that the surgical robot system 300 is in a fault state. In response to the detection of such a fault condition, the safety monitor 316 can be configured to transition the relevant surgical robot arm (the surgical robot arm to which the main controller erroneously issues movement commands) to a safe state. In some cases, the safety monitor 316 can be configured to transition the relevant surgical robot arm to a safe state by having the safety device 314 filter all communication between the main controller and the relevant surgical robot arm.

[0163] In some cases, the safety monitor 316 can also be configured to verify the main controller's calculations of instrument yaw, instrument pitch, and wrist posture (i.e., position and orientation) based on destination and communication from the main controller 312. Specifically, the safety monitor 316 can be configured to identify the surgical instrument tip posture (i.e., position and orientation), the instrument pitch and yaw calculated by the main controller 312, and the wrist position calculated by the main controller 312, based on destination and communication from the main controller. The safety monitor 316 is then configured to perform a reverse calculation based on the calculated instrument pitch, instrument yaw, wrist posture, and VPP to identify an estimate of the surgical instrument tip posture. The safety monitor 316 can then be configured to compare the estimated instrument tip posture with the instrument tip posture calculated by the main controller and determine whether they are within each other's predetermined acceptable range. If the safety monitor 316 determines that the instrument tip orientation calculated by the main controller and the estimated instrument top orientation are not within each other's predetermined acceptable range, the safety monitor 316 can determine that the surgical robot system 300 is in a fault state. In response to detecting this fault state, the safety monitor 316 can be configured to transition the relevant surgical robot arm (the surgical robot arm to which the main controller issues movement commands) to a safe state. In some cases, the safety monitor 316 can be configured to transition the relevant surgical robot arm to a safe state by having the safety device 314 filter all communication between the main controller and the relevant surgical robot arm.

[0164] As described above, some instruments can be actuated by transmitting drive from the surgical robot arm to the attached instrument via one or more drive interface elements that interact with the corresponding instrument interface element of the surgical instrument. In some cases, once the main controller 312 has calculated the instrument pitch, instrument yaw, and instrument deployment (e.g., jaw deployment), the main controller 312 can be configured to calculate the drive element positions to achieve the desired instrument pitch, yaw, and deployment. In such cases, the safety monitor 316 can be configured to verify the main controller's calculation of the drive element positions based on destination and communication from the main controller.

[0165] Specifically, safety monitor 316 can be configured to identify instrument pitch, instrument yaw, instrument deployment, and drive element positions calculated by main controller 312 based on destination and communication from main controller. Safety monitor 312 can then be configured to calculate an estimate of the drive element position based on instrument pitch, yaw, and deployment, and determine whether the estimated drive element position is within a predetermined distance (1.0e-6m) of the calculated drive element position. If the safety monitor determines that the estimated drive element position is not close enough to the calculated drive element position, safety monitor 316 can determine that the surgical robot system 300 is in a fault state. In response to detecting such a fault state, safety monitor 316 can be configured to transition the relevant surgical robot arm to a safe state. In some cases, safety monitor 316 can be configured to transition the relevant surgical robot arm to a safe state by having safety device 314 filter all communication between the main controller and the relevant surgical robot arm.

[0166] In some cases, one or more surgical instruments attached to a surgical robotic arm can be actuated. Some actuated instruments, such as grippers (which may alternatively be called clamps), comprise multiple elements (e.g., jaws) that can move between open and closed positions. The movement of the elements can be controlled by specific inputs on input devices. For example, each input device may have a lever, or another movable part or set of parts (e.g., a slider that can move in at least two directions, or opposing members that can be compressed together or brought close together), which moves the element toward the closed position when moved in one direction or in one manner (e.g., pressing inward), and moves the element toward the open position when moved in different directions or in different manners (e.g., pressing outward or pulling). The main controller can be configured to map the position of the lever to the position of the instrument's element via one or more control parameters and move the element to the calculated position. In such cases, a safety monitor 316 can be configured to verify the main controller's calculation of the element's position based on the destination and communications from the main controller.

[0167] Specifically, safety monitor 316 can be configured to identify (i) the desired position of a component (e.g., jaws) as calculated by the main controller, and (ii) the position of a related input (e.g., lever), based on the destination and communication from the main controller; and independently calculate the position of the component (e.g., jaws) based on the related input (e.g., lever). Safety monitor 316 can then be configured to determine whether the desired position of the component (e.g., jaws) as calculated by the main controller is within a predetermined distance (e.g., 0.015 radians) of the position of the component (e.g., jaws) as calculated by safety monitor 315. In some cases, the position of the component may be defined by the angle between the components. If safety monitor 316 determines that the desired position of the component (e.g., jaws) as calculated by the main controller is not within a predetermined distance (e.g., 0.015 radians) of the position of the component (e.g., jaws) as determined by safety monitor 316, then safety monitor 316 can determine that the surgical robot system is in a fault state. In response to the detection of such a fault condition, the safety monitor 316 can be configured to transition the relevant surgical robot arm (e.g., a surgical robot arm attached to a relevant actuable instrument) to a safe state. In some cases, the safety monitor 316 can be configured to transition the relevant surgical robot arm to a safe state by having the safety device 314 filter all communication between the main controller and the relevant surgical robot arm.

[0168] Main controller—a surgical robotic arm with an endoscope attached to it.

[0169] As mentioned above, in some cases, different rules may be applied to surgical robotic arms compared to surgical robotic arms with surgical instruments attached to them.

[0170] As described above, in some cases, each surgical robotic arm can be assigned a unique identifier (e.g., a unique color) by the main controller 312. In some cases, surgical robotic arms with an endoscope attached to them can be consistently assigned the same unique identifier. In other words, in some cases, a specific unique identifier can be reserved for surgical robotic arms with an endoscope attached to them. For example, a surgical robotic arm with an endoscope attached to it can be assigned white. As described above, the surgical robotic arm can be configured to include the unique identifier assigned to it in at least some communications to the main controller 312. If a surgical robotic arm without an endoscope attached to it (e.g., one with surgical instruments attached to it) does not report the specific unique identifier (e.g., color) reserved for the endoscope arm, the system may not function as intended.

[0171] Therefore, safety monitor 316 can be configured to determine, based on destination and communication from main controller 312, whether a surgical robotic arm with an endoscope attached thereto has not reported a unique identifier (e.g., color) reserved for a surgical robotic arm with an endoscope attached thereto. If safety monitor 316 determines that a surgical robotic arm with an endoscope attached thereto has not reported a unique identifier (e.g., color) reserved for a surgical robotic arm with an endoscope attached thereto, then safety monitor 316 can determine that surgical robot system 300 is in a fault state. In response to detecting such a fault state, safety monitor 316 can be configured to transition the relevant surgical robotic arm (the surgical robotic arm attached to the endoscope) to a safe state. In some cases, safety monitor 316 can be configured to transition the relevant surgical robotic arm to a safe state by having safety device 314 filter all communication between the main controller and the relevant surgical robotic arm.

[0172] As described above, surgical instruments and / or endoscopes can be releasably attached to the surgical robotic arm, allowing them to be detached even when the surgical robotic arm is currently being used in a surgical procedure. The surgical robotic arm itself is capable of determining when a surgical instrument or endoscope has been attached to it and when it has been detached, and reports the detected attachment or detachment to the main controller. To ensure that the main controller 312 does not issue endoscope position or orientation commands to the surgical robotic arm from which the endoscope has been detached, a safety monitor 316 can be configured to determine when the endoscope has been detached from the surgical robotic arm based on its destination and communications from the main controller. If the safety monitor 316 detects that the endoscope has been detached from the surgical robotic arm, it can determine whether the main controller has issued an endoscope position command to the surgical robotic arm after a predetermined period of time (e.g., 2 milliseconds) following the detachment. If the safety monitor 316 determines that the main controller has issued an endoscope position command to the surgical robotic arm after the predetermined period of time, it can determine that the surgical robotic system 300 is in a faulty state. In response to determining the existence of such a fault condition, safety monitor 316 can be configured to transition the relevant surgical robot arm (the surgical robot arm from which the endoscope is detached) to a safe state. In some cases, safety monitor 316 can be configured to transition the relevant surgical robot arm to a safe state by having safety device 314 filter all communication between the main controller and the relevant surgical robot arm.

[0173] As described above, in certain situations, an operator (e.g., a surgeon) can control the movement and / or position of a surgical robotic arm (and the surgical instruments / endoscopes attached thereto) by providing input via an input device (e.g., but not limited to, a manual controller). In some cases, even after the surgical robotic arm has been linked to the input device (e.g., the manual controller) by the operator (e.g., via a graphical user interface), if the input device (e.g., the manual controller) is in a specific state, it may be used solely to control the endoscope attached to the linked surgical robotic arm; this specific state may be referred to herein as the engaged state. When the input device (e.g., the manual controller) is not in a specific state (e.g., the manual controller), the manual controller may be used for another purpose, such as, but not limited to, providing input to the graphical user interface. In some cases, if one or more conditions are met, such as, but not limited to, the operator contacting the input device (e.g., the operator's palm engaging the manual controller), the manual controller being fault-free, and the operator not (e.g., via pressing a specific button) indicating that they wish to place the input device in a disengaged state, the input device (e.g., the manual controller) may only be in a specific state (e.g., the engaged state).

[0174] However, unlike surgical instruments that may be entirely controlled by a single input device (e.g., a manual controller), endoscopes may be partially controlled by one input device (e.g., a manual controller) and partially by another input device (e.g., a manual controller). For example, a first input device (e.g., a left manual controller) may be used to control a first set of features of the endoscope (e.g., pitch and yaw), and a second input device (e.g., a right manual controller) may be used to control a second set of features of the endoscope (e.g., roll and depth). In such cases, if the first input device (e.g., the left manual controller) is not in a specific state (e.g., engaged), and the master controller issues commands to the associated surgical robotic arm (the surgical robotic arm attached to the endoscope) related to the first set of features, and / or if the second input device (e.g., the right manual controller) is not in a specific state (e.g., engaged), and the master controller issues commands to the associated surgical robotic arm related to the second set of features, the master controller may not function as intended.

[0175] Therefore, the safety monitor 316 can be configured to determine, based on destination and communication from the main controller 312, whether the first or second input device (e.g., the left or right manual controller) is not in a specific state. If the safety monitor 316 determines that the first input device (e.g., the left manual controller) is not in a specific state, the safety monitor 316 can determine whether the main controller has issued a command to the associated surgical robot arm (i.e., the surgical robot arm attached to the endoscope) associated with the first set of features. If the safety monitor 316 determines that the second input device (e.g., the right manual controller) is not in a specific state, the safety monitor 316 can determine whether the main controller has issued a command to the associated surgical robot arm associated with the second set of features. If the safety monitor 316 detects either condition, the safety monitor 316 can determine that the surgical robot system 300 is in a fault state. In response to detecting such a fault state, the safety monitor 316 can be configured to transition the associated surgical robot arm (i.e., the surgical robot arm attached to the endoscope) to a safe state. In some cases, the safety monitor 316 can be configured to bring the relevant surgical robot arm into a safe state by having the safety device 314 filter all communications between the main controller and the relevant surgical robot arm.

[0176] In some cases, the safety monitor 316 can also be configured to verify that when the main controller instructs a change in attitude of the surgical robotic arm attached to the endoscope, the indicated attitude change is consistent with a change in pitch, yaw, roll, and depth of the endoscope motion requested by the operator (e.g., via an input device, such as a manual controller). In one instance, the indicated attitude can be considered consistent with the requested endoscope motion if the requested pitch, yaw, and roll are within a predetermined distance (e.g., 0.00001 radians) of the indicated pitch, yaw, and roll, respectively, and the requested depth is within 2.0e-7 meters of the indicated depth. Specifically, the safety monitor 316 can be configured to determine, based on destination and communications from the main controller 312, when the operator (e.g., a surgeon) requests an attitude change of the endoscope (e.g., via an input device such as a manual controller). If an operator (e.g., a surgeon) has requested a change in the endoscope's orientation, safety monitor 316 can be configured to determine, based on the destination and communications from main controller 312, the indicated orientation sent to the relevant surgical robotic arm (i.e., the surgical robotic arm to which the endoscope is attached). Safety monitor 316 determines whether the indicated orientation is consistent with the requested endoscope movement. If it is determined that the indicated orientation is inconsistent with the requested endoscope movement, safety monitor 316 can determine that the surgical robotic system is in a fault state. In response to detecting such a fault state, safety monitor 316 can be configured to transition the relevant surgical robotic arm (i.e., the surgical robotic arm attached to the endoscope) to a safe state. In some cases, safety monitor 316 can be configured to transition the relevant surgical robotic arm to a safe state by having safety device 314 filter all communications between the main controller and the relevant surgical robotic arm.

[0177] In some cases, the optical angle of the endoscope can be adjustable. In some cases, the optical angle can be adjusted to one of a plurality of (e.g., three) predetermined optical angles. In some cases, the conversion of operator movement (e.g., movement of an input device (e.g., a manual controller)) to commands controlling the movement of the surgical robot arm (and the surgical instruments attached thereto) can be based on the endoscope optical angle. In these cases, safety monitor 316 can be configured to determine, based on destination and communication from the main controller, whether the optical angle of the endoscope has changed. If safety monitor 316 determines that the optical angle of the endoscope has changed, safety monitor 316 can determine, based on destination and communication from the main controller, that the main controller has not issued attitude commands to the surgical robot arm, and optionally determine whether the new optical angle of the endoscope is one of a plurality of predetermined optical angles. If any of these conditions are met, safety monitor 316 can determine that the surgical robot system is in a fault state. In response to detecting such a fault state, safety monitor 316 can be configured to transition the entire system to a safe state. In some cases, the safety monitor 316 can be configured to transition the entire system to a safe state by having the safety device 316 filter all communications to and from the main controller.

[0178] Main controller—input device control unit

[0179] In some cases, the input device (e.g., a manual controller) may include a controller configured to receive sensor data from one or more sensors within the input device (e.g., the manual controller), thereby determining the position and orientation of the manual controller within a manual controller reference frame, and transmitting the determined position and orientation to a main controller. The main controller then translates the position and orientation into commands to control the surgical arm and the surgical instruments / endoscopes attached thereto. In some cases, the input device controller may not include a built-in safety monitor. In such cases, the safety monitor may be configured to verify the operation of the input device controller based on destination and communications from the main controller.

[0180] In some cases, both the input device (e.g., its controller) and the main controller can run or execute software, and the version of the software currently running on the input device or the main controller can be included in communications from that device. In some cases, certain versions of the input device controller software may only be compatible with certain versions of the main controller software. In these cases, the safety monitor 316 can be configured to: determine, based on the destination and communications from the main controller, whether the main controller has established a communication connection with the input device (e.g., its controller); and if it is determined that the main controller has established a communication connection with the input device, determine, based on the destination and communications from the main controller, whether the version of the software running on the input device is compatible with the version of the software running on the main controller. If it is determined that the software versions are incompatible, the safety monitor 316 can be configured to determine that the surgical robot system 300 is in a fault state. In response to determining the existence of such a fault state, the safety monitor 316 can transition the relevant input device (e.g., a manual controller) to a safe state. In some cases, the safety monitor 316 can be configured to transition the relevant input device to a safe state by having the safety device 314 filter all communication between the relevant input device (e.g., a manual controller) and the main controller.

[0181] In some cases, the main controller can be configured to send a heartbeat signal to each input device (e.g., each input device controller) at a predetermined frequency (e.g., 2.5 kHz). In these cases, the input device (e.g., the input device controller) can be configured to transition to a safe state if it does not receive the heartbeat signal at the predetermined frequency. In these cases, the safety monitor 316 can be configured to determine, based on the destination and communication from the main controller, whether the main controller sends a heartbeat signal to each input device within a predetermined time window (e.g., 5 milliseconds) and within predetermined constraints, such as a predetermined threshold (e.g., + / - 20%) at a predetermined frequency (e.g., 2.5 kHz). If it is determined that the main controller has not sent a heartbeat signal to the input device within the predetermined constraints, the safety monitor 316 can be configured to determine that the surgical robot system 300 is in a fault state. In response to determining the existence of such a fault state, the safety monitor 316 can transition the relevant input device (e.g., a manual controller) to a safe state. In some cases, the safety monitor 316 can be configured to transition the relevant input device to a safe state by having the safety device 314 filter all communication between the relevant input device (e.g., a manual controller) and the main controller.

[0182] In some cases, an input device (e.g., its controller) is expected to respond to control communications from the main controller within a predetermined time period (e.g., 1000 microseconds) when operating as intended. In these cases, the safety monitor 316 can be configured to verify that the delay between the control communication from the main controller 312 to the input device (e.g., its controller) and the return communication does not exceed a predetermined threshold (e.g., 1000 milliseconds). In some cases, the main controller can be configured to include a delay count (e.g., a timestamp) in the communication when it issues a control command to the surgical robot arm, and the surgical robot arm (e.g., its arm controller) is configured to include a delay count in its response to the control communication. In these cases, the safety monitor 316 can be configured to identify the delay between the control packet issued by the main controller 312 to the input device (e.g., its controller) and the response of the input device from the delay count. If the safety monitor 316 determines that the delay exceeds the predetermined threshold, the safety monitor 316 can determine that the surgical robot system is in a fault state. In response to detecting such a fault state, the safety monitor 316 can be configured to transition the relevant input device to a safe state. In some cases, the safety monitor 316 can be configured to transition the relevant input device to a safe state by having the safety device 314 filter all communication between the relevant input device and the main controller.

[0183] As described above, if an input device (e.g., a manual controller) is linked to a surgical robot arm in a surgical mode (e.g., a mode where the surgical robot arm can be controlled by the input device), the input device can be considered engaged. For each input device, an engagement ok signal generated by the main controller 312 can exist, indicating whether the input device is engaged with the surgical robot arm. In such cases, the safety monitor 316 can be configured to verify, based on destination and communication from the main controller, that if the engagement ok signal turns into a false signal within a predetermined time period (e.g., 1 ms), the relevant input device (e.g., its controller) indicates that it is in a disengaged state. If the safety monitor determines that the relevant input device (e.g., its controller) has not transitioned to a disengaged state within the predetermined time period, the safety monitor 316 can determine that the surgical robot system 300 is in a fault state. In response to detecting such a fault state, the safety monitor 316 can be configured to transition the relevant input device to a safe state. In some cases, the safety monitor 316 can be configured to transition the relevant input device to a safe state by having the safety device 314 filter all communication between the relevant input device and the main controller.

[0184] As described above, the operator console display can be used to provide the user with a real-time image stream or representation of the surgical site captured by an image capture device (e.g., but not limited to, an endoscope). In some cases, the operator console display can also be used to provide the user with a graphical user interface (GUI) that allows the user to configure and otherwise change the system. In some cases, it can be used to provide input to the system via the GUI when input devices (e.g., manual controllers) are not engaged (e.g., they are not used to control the surgical robot arm). In some cases, no input device should be engaged when the display is in a mode that displays a GUI or aspects of a GUI, in which the user can make changes to the system (e.g., but not limited to, user interface menus). In such cases, the safety monitor 316 can be configured to verify, based on destination and communication from the main controller, that if the display device is in a mode that displays a GUI or aspects of a GUI, in which the user can make changes to the system, all input devices are disengaged. If the safety monitor determines that the surgical robot system 300 is in a faulty state when the display is in a state where the input device still indicates that it is engaged, the safety monitor 316 can determine that the surgical robot system 300 is in a faulty state. In response to the detection of such a fault condition, the safety monitor 316 can be configured to transition the relevant input device to a safe state. In some cases, the safety monitor 316 can be configured to transition the relevant input device to a safe state by having the safety device 314 filter all communication between the relevant input device and the main controller.

[0185] As described above, in some cases, the input device (e.g., a manual controller) may include a first controller (which may be referred to as a hand-arm base controller (HABC)) that generates input posture information from the input and provides this information to the main controller 312. In some cases, each input device may also have a second controller (which may be simply referred to as a manual controller (HC)) that receives input from the operator and provides this input to the first controller (e.g., the HABC). In some cases, in addition to providing a copy of at least a portion of the original information, the first controller (e.g., the HABC) may also provide the main controller with information about the status of the second controller (e.g., the HC). In these cases, the safety monitor 316 is also configured to determine, based on the destination and communication from the main controller, whether the second controller (e.g., the HC) of the input device is reporting a fault, but the first controller is not reporting a fault. If the safety monitor 316 identifies this discrepancy, then the safety monitor 316 can determine that the surgical robot system 300 is in a fault state. In response to detecting such a fault state, the safety monitor 316 can be configured to transition the relevant input device to a safe state. In some cases, the safety monitor 316 can be configured to transition the relevant input device to a safe state by having the safety device 314 filter all communication between the relevant input device and the main controller.

[0186] In some cases, in addition to outputting the calculated input device posture, each input device may also output the joint angle of the input device based on its calculated posture. In these cases, the safety monitor 316 may also be configured to verify calculations performed by the input device (e.g., its controller). For example, the safety monitor 316 may be configured to determine a fault state if it determines, based on destination and communication from the main controller 312, that the input device posture calculated by the input device controller is inconsistent with any input device joint angle by more than a predetermined amount (e.g., 0.1 degrees). If the safety monitor 316 determines that the posture output by the input device controller is inconsistent, it may transition the relevant input device controller to a safe state. In some cases, the safety monitor 316 may be configured to transition the relevant input device to a safe state by having the safety device 314 filter all communication between the relevant input device controller and the main controller.

[0187] Electrical Equipment Monitoring

[0188] In certain situations, specific malfunction conditions may exist when energized instruments, such as electrosurgical instruments, are attached to a surgical robotic arm. Energized instruments are devices that can be powered by electrical energy, such as electric current, to perform surgical procedures (e.g., but not limited to, cutting or cauterization).

[0189] In some cases, a surgical robotic arm with an attached energized device can be configured to periodically send a timestamp token to a main controller 312. Upon receiving the token, the main controller 312 can be configured to generate a modified token, which may be referred to as a valid token, and pass the valid token to an input device controller. If the input device receives input from the operator that the energized device will be energized (e.g., by pressing a special button on the input device), the input device controller can send the valid token back to the main controller 312. If the main controller determines that the relevant surgical robotic arm is engaged, the main controller can send the valid token to the relevant surgical robotic arm, which will energize the energized device in response to receiving the valid token. This token-based activation method for energized devices is described in co-pending UK patent applications 1803379.5 and 1902811.7, which are incorporated herein by reference in their entirety.

[0190] In these cases, safety monitor 316 can be configured to detect, based on destination and communication from the main controller, whether the main controller sends a valid token to the surgical robot arm that does not match a valid token received from an input device (e.g., an input device controller) within a predetermined time period (e.g., 3 milliseconds). If safety monitor 316 detects a mismatch between the sent and received valid tokens, it can determine that the surgical robot system is in a fault state. In response to detecting such a fault state, safety monitor 316 can be configured to transition the relevant input device (e.g., the input device controller) to a safe state. In some cases, safety monitor 316 can be configured to transition the relevant input device (e.g., the input device controller) to a safe state by having safety device 314 filter all communication between the relevant input device (e.g., the input device controller) and the main controller.

[0191] In these cases, the safety monitor can be configured to detect whether the main controller has sent a valid token to a surgical robot arm not connected to an input device, based on the destination and communication from the main controller 312. If the safety monitor 316 detects that the main controller has sent a valid token to a surgical robot arm not linked to an input device, then the safety monitor 316 can determine that the surgical robot system 300 is in a fault state. In response to detecting such a fault state, the safety monitor 316 can be configured to transition the relevant surgical robot arm (e.g., the arm controller) to a safe state. In some cases, the safety monitor 316 can be configured to transition the relevant surgical robot arm (e.g., the arm controller) to a safe state by having a safety device 314 filter all communication between the relevant surgical robot arm (e.g., the arm controller) and the main controller.

[0192] In these cases, the safety monitor 316 can be configured to detect, based on destination and communication from the main controller 312, whether an input device (e.g., an input device controller) transmits a valid token to the main controller 312 before the user has indicated that the energized instrument will be energized (e.g., before the user has pressed a special power-on button on the manual controller). If the safety monitor 316 detects that the input device has transmitted a valid token but the user has not indicated that the energized instrument will be energized, the safety monitor 316 can determine that the surgical robot system 300 is in a fault state. In response to detecting such a fault state, the safety monitor 316 can be configured to transition the relevant input device (e.g., the input device controller) to a safe state. In some cases, the safety monitor 316 can be configured to transition the relevant input device (e.g., the input device controller) to a safe state by having a safety device 314 filter all communication between the relevant input device (e.g., the input device controller) and the main controller.

[0193] The applicant hereby independently discloses each individual feature described herein, as well as any combination of two or more such features, provided that such features or combinations can be implemented based on this specification as a whole in accordance with common general knowledge of those skilled in the art, regardless of whether such features or combinations of features solve any problem disclosed herein. In view of the foregoing description, it will be apparent to those skilled in the art that various modifications can be made within the scope of this invention.

Claims

1. A control system (306) for controlling a surgical robot system (300), the surgical robot system (300) including surgical robots (302, 400), the surgical robots (302, 400) including a base (404) and an arm (402) extending from the base (404) to an attachment (406) for instruments (408), the arm (402) including a plurality of joints (410) thereby enabling changes in the configuration of the arm (402), the control system (306) including: Main controller (312), the main controller is configured to: The operator of the surgical robot receives communication that identifies the input. Based on the input, control signals are generated for controlling the movement of the surgical robot arm; as well as Sending communication to the surgical robot to identify the control signals; as well as A safety device (314) is configured to allow communication to and from the main controller to pass through the safety device (314), the safety device (314) being operable to selectively filter communication to and / or from the main controller (312).

2. The control system (306) according to claim 1, wherein the safety device (314) is configured to filter at least a portion of communications destined for and / or from the main controller (312) in response to a fault state of the surgical robot system (300).

3. The control system (306) according to claim 1 or claim 2, wherein the safety device (314) includes one or more filters (502, 504), and the one or more filters (502, 504) are configured to filter out communications destined for and / or from the main controller (312) by comparing received communications with one or more filter criteria.

4. The control system (306) of claim 3, wherein the one or more filters include a receiving filter (502), and the one or more filter criteria include one or more receiving filter criteria, the receiving filter (502) being configurable to filter communication from the main controller (312) by comparing communication from the main controller (312) with the one or more receiving filter criteria.

5. The control system (306) according to claim 4, wherein the receiving filter (502) includes a buffer (508) for storing communications received from the main controller (312).

6. The control system (306) of claim 5, wherein the receiving filter (502) includes a manifold (602) and one or more matchers (606, 608), the manifold (602) being configured to extract relevant information from the received communication before storing the received communication in the buffer (508), and the one or more matchers (606, 608) being configured to compare the relevant information with the one or more receiving filter criteria.

7. The control system (306) according to claim 4, wherein the one or more receiving filter standards include up to N receiving filter standards, where N is an integer based on the number of comparisons that can be performed between communication and filter standards in one cycle and the number of cycles spent receiving communication.

8. The control system (306) according to claim 7, wherein receiving communication requires at most X cycles, and N is selected such that communication can be compared with N filter standards within X cycles.

9. The control system (306) of claim 4, wherein the one or more filter criteria include one or more transmit filter criteria, and the one or more filters include a transmit filter (504) configured to filter communication destined for the main controller (312) by comparing communication destined for the main controller (312) with the one or more transmit filter criteria.

10. The control system (306) according to claim 9, wherein the transmit filter (504) includes a buffer (510) for storing communications destined for the main controller (312) in the main controller (312).

11. The control system (306) of claim 10, wherein the transmit filter (504) includes a manifold (604) and one or more matchers (610, 612), the manifold (604) being configured to extract relevant information from communications destined for the master controller (312) before storing communications destined for the master controller (312) in the buffer (510), and the one or more matchers (610, 612) being configured to compare the relevant information with the one or more transmit filter criteria.

12. The control system (306) of claim 9, wherein the one or more transmit filter standards include up to K receive filter standards, wherein K is an integer based on the number of comparisons that can be performed between communication and filter standards in one cycle and the number of cycles spent receiving communication.

13. The control system (306) according to claim 12, wherein receiving communication requires at most X cycles, and K is selected such that communication can be compared with K filter standards within X cycles.

14. The control system (306) according to claim 3, wherein the one or more filter criteria are configurable.

15. The control system (306) according to claim 14, wherein the one or more filter standards are configured to cause the safety device (314) to filter all communications to and from the main controller (312).

16. The control system (306) of claim 14, wherein the one or more filter criteria are configurable to cause the safety device (314) to filter communication between the main controller (312) and one or more devices in the surgical robot system (300).

17. The control system (306) according to claim 3, wherein each of the one or more filter standards includes one or more of a source address, a destination address, a source port, and a destination port.

18. The control system (306) according to claim 3, wherein the safety device (314) includes one or more registers, and each filter standard is stored in a set of the one or more registers.

19. The control system (306) of claim 3, wherein the one or more filters are configured to reject communication in response to determining that communication matches at least one of the one or more filter criteria.

20. The control system (306) of claim 19, wherein the one or more filters are configured to reject communication by dropping communication.

21. The control system (306) of claim 19, wherein the one or more filters are configured to reject communication by disrupting communication.

22. The control system (306) of claim 21, wherein the one or more filters are configured to disrupt communication by altering the error detection portion of the communication.

23. The control system (306) according to claim 1 or claim 2 further includes a safety monitor (316), and the safety device (314) is configured to send a copy of at least a portion of communications destined for and / or from the main controller (312) to the safety monitor (316).

24. The control system (306) of claim 23, wherein the safety monitor (316) is configured to analyze received communications to determine whether the surgical robot system (300) is in a fault state, and in response to determining that the surgical robot system (300) is in a fault state, to cause the safety device (314) to filter at least a portion of communications destined for and / or from the main controller (312).

25. A method (700) for selectively filtering communications destined for and / or from a master controller of a surgical robot system, the surgical robot system including a surgical robot, the surgical robot including a base and an arm extending from the base to an attachment for instruments, the arm including a plurality of joints thereby enabling changes in the configuration of the arm, the master controller being configured to receive communications identifying input from an operator of the surgical robot, generate control signals based on the input for controlling movement of the surgical robot arm, and send communications identifying the control signals to the surgical robot, the method (700) comprising: Receive destination or communication from the main controller at the safety device (702); Determine whether at least one filter standard has been specified (704); In response to determining that at least one filter standard has been specified, the received communication is compared with at least one specified filter standard (708). In response to determining that the received communication matches at least one of the at least one filter criteria, the received communication is rejected (710, 712); and In response to determining that the received communication does not match any of the at least one filter standard, the received communication is output to the relevant device (710, 706).

Images