Surgical robot system and method for transferring control to a secondary robot controller

Abstract

A robotic surgical system and method for transferring control to a secondary robotic arm controller are disclosed. In one embodiment, the robotic surgical system includes: a user console including a display device and a user input device; a robotic arm configured to be coupled to an operating table; a primary robotic arm controller configured to move the robotic arm in response to signals received from the user input device at the user console; and a secondary robotic arm controller configured to move the robotic arm in response to signals received from a user input device remote from the user console. Control of the movement of the robotic arm is transferred from the primary robotic arm controller to the secondary robotic arm controller in response to a failure in the primary robotic arm controller. Other embodiments are provided.

Description

Technical Field

[0001] The present subject matter generally relates to robotic and surgical systems, and more particularly to system architectures and components of a surgical robotic system for minimally invasive surgery. Background Art

[0002] Minimally invasive surgery (MIS) such as laparoscopic surgery involves techniques designed to reduce tissue damage during a surgical procedure. For example, laparoscopic surgery typically involves making a plurality of small incisions in a patient's body (e.g., in the abdomen) and introducing one or more surgical tools (e.g., an end effector and an endoscope) into the patient's body through the incisions. The introduced surgical tools can then be used to perform the surgical procedure, with visualization assistance provided by the endoscope.

[0003] Generally speaking, MIS provides multiple benefits such as reduced patient scarring, less patient pain, shorter patient recovery periods, and lower medical costs associated with patient recovery. Recent technological developments have allowed for the use of robotic systems to perform more MIS, which robotic systems include one or more robotic arms configured to manipulate surgical tools based on commands from a remote operator. The robotic arms can support various devices, such as surgical end effectors, imaging devices, cannulas for providing access to a patient's body cavity and organs, etc., for example, at their distal ends. In a robotic MIS system, it may be desirable to establish and maintain a high positioning accuracy for surgical instruments supported by the robotic arms.

[0004] Existing robotic-assisted surgical systems typically consist of a surgeon's console residing in the same operating room as the patient and a patient-side cart having four interactive robotic arms controlled from the console. Three of these arms hold instruments, such as a surgical scalpel, scissors, or gripper, while the fourth arm supports an endoscopic camera. To reposition the patient during surgery, the surgical staff may have to disconnect the instrument / arm, reposition the arm / patient cart, and re-dock the instrument / arm. Summary of the Invention

[0005] In some aspects, a surgical robot disclosed herein includes: a user console; a primary controller configured to control the surgical robot in response to a first input from the user console; and a secondary controller configured to control the surgical robot in response to a second input remote from the user console. The secondary controller is configured to receive communication from the primary controller and, in response to a failure of the communication from the primary controller, transfer control of the surgical robot from the primary controller to the secondary controller.

[0006] In some variations, the primary controller includes a first coordinator, and the secondary controller includes a second coordinator. The communication from the primary controller includes heartbeat messages sent by the first coordinator at a predetermined rate. When the second coordinator fails to receive one or more heartbeat messages, a failure of the communication from the primary controller is detected. The primary controller further includes a supervisor process configured to notify the first coordinator whether the primary controller is in a functional state, and the first coordinator is configured to send the heartbeat messages to the second coordinator only when the primary controller is in the functional state. The primary controller includes a first plurality of processes for controlling the surgical robot, and the secondary controller includes a dormant copy of the first plurality of processes. Transferring control of the surgical robot to the secondary controller includes activating the dormant copy of the first plurality of processes for controlling the surgical robot. The primary controller is further configured to receive status information from the surgical robot when controlling the surgical robot. Transferring control of the surgical robot to the secondary controller includes routing the status information from the surgical robot to the secondary controller.

[0007] In some variations, the surgical robot further includes a backup controller configured to receive heartbeat messages from the secondary controller at a predetermined rate when the secondary controller is controlling the surgical robot, and the control of the surgical robot is transferred from the secondary controller to the backup controller in response to the loss of one or more heartbeat messages. The secondary controller includes a second plurality of processes for controlling the surgical robot, and the backup controller includes a dormant copy of the second plurality of processes, and transferring control of the surgical robot to the backup controller includes activating the dormant copy of the second plurality of processes for controlling the surgical robot. The secondary controller is configured to receive status information from the surgical robot when controlling the surgical robot, and transferring control of the surgical robot to the backup controller includes routing the status information from the surgical robot to the backup controller. The backup controller is further configured to instruct a power distribution component to shut off power to the secondary controller.

[0008] In some aspects, the robotic methods disclosed herein include: controlling the movement of a surgical robot by a primary robot controller based on input from a first input device; when the primary robot controller is controlling the surgical robot, receiving, by a secondary robot controller, heartbeat messages from the primary robot controller; transferring control of the surgical robot to the secondary robot controller in response to a failure to receive one or more heartbeat messages; and controlling the movement of the surgical robot by the secondary robot controller based on input from a second input device different from the first input device.

[0009] In some variations, the failure to receive the heartbeat message from the primary robot controller is caused by at least one of a power failure, a hardware failure, a software failure, and a communication failure in the primary robot controller. Transitioning control of the surgical robot includes waking up the process in the secondary robot controller, where the process in the secondary robot controller is a copy of the process in the primary robot controller for controlling the surgical robot. Transitioning control of the surgical robot includes routing communication from the surgical robot to the secondary robot controller instead of the primary robot controller. In response to determining that the secondary robot controller is unable to control the movement of the surgical robot, control of the surgical robot is transitioned to a backup robot controller coupled to the secondary input device, where transitioning control of the surgical robot to the backup robot controller includes waking up the process in the backup robot controller and routing the communication from the surgical robot to the backup controller instead of the secondary robot controller.

[0010] In some aspects, the surgical robot system disclosed herein includes: one or more robotic arms mounted to an operating table; a user console including a first user interface device remote from the operating table; a primary controller configured to control the one or more robotic arms in response to input received from the first user interface device at the user console; and means for transitioning control of the one or more robotic arms from the primary controller to a secondary controller located within the operating table in response to a failure in the primary controller, where the secondary controller is configured to manipulate the one or more robotic arms in response to input received from a second user interface device coupled to the one or more robotic arms and the secondary controller. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Figure 1 is a diagram showing an exemplary operating room environment with a surgical robot system in accordance with aspects of the present subject technology.

[0012] Figure 2 is a block diagram showing exemplary hardware components of a surgical robot system in accordance with aspects of the present subject technology.

[0013] Figure 3 is a diagrammatic illustration of a network topology of an embodiment.

[0014] Figure 4 is a block diagram of a surgical robot system of an embodiment.

[0015] Figure 5 is a flowchart of a method of an embodiment for detecting a failure in a process in a primary robotic arm controller.

[0016] Figure 6 It is a flowchart of a method for an implementation scheme of monitoring heartbeat messages. Detailed implementation

[0017] Examples of various aspects and variations of the present subject technology are described herein and illustrated in the accompanying drawings. The following description is not intended to limit the invention to these implementation schemes, but rather to enable those skilled in the art to prepare and use the invention.

[0018] Systematic review

[0019] Disclosed herein is a robot-assisted surgical system, which is an electromechanical system controlled by software and designed for a surgeon to perform minimally invasive surgery (MIS). The surgical robot system can be composed of three main subsystems: a surgeon subsystem - a user console (surgeon console or surgeon bridge), a central control subsystem - a control tower, and a patient subsystem - a table arm and a robotic arm. A surgeon sitting in the surgeon's seat of the user console can use the main user input device (UID) and a footswitch to control the movement of the compatible instruments. The surgeon can observe three-dimensional (3D) endoscopic images on a high-resolution open stereoscopic display, which provides the surgeon with views of the patient's anatomy and instruments, as well as icons, applications, and other user interface functions. The user console can also provide the option of an immersive display using a periscope, which can be pulled out from the back of the surgeon's seat.

[0020] The control tower can be used as the control and communication center of the surgical robot system. It can be a mobile point-of-care cart housing a touchscreen display and includes a computer that controls the robotic-assisted manipulation of the surgeon on the instruments, safety systems, graphical user interface (GUI), advanced light engine (also known as a light source), and video and graphics processors, as well as other supporting electronic and processing devices. The control tower can also house third-party devices, such as an electrosurgical generator device (ESU), as well as a blower and a CO2 tank.

[0021] The patient subsystem can be an articulated operating room (OR) table with up to four integrated robotic arms positioned, for example, above the target patient anatomy. The robotic arms of the surgical system can incorporate a remote center design, i.e., each arm rotates about a fixed point in the space where the cannula passes through the patient body wall. This reduces the lateral movement of the cannula and minimizes the stress at the patient body wall. A set of compatible tools can be attached to / detached from the instrument driver mounted at the distal end of each arm, enabling the surgeon to perform various surgical tasks. The instrument driver can provide in-vivo access to the surgical site, mechanical actuation of the compatible tools through a sterile junction, and communication with the compatible tools through the sterile junction and user contact points. An endoscope can be attached to any arm and provide the surgeon with a high-resolution three-dimensional view of the patient anatomy. The endoscope can also be used at the beginning of the surgery through an endoscopic (handheld) technique and then mounted on any one of the four arms. Additional accessories such as trocars (also known as cannulas, seal cartridges, and packers) and drapes may be required to perform surgery using the surgical robot system.

[0022] The surgical robot system can be used with an endoscope, compatible endoscopic instruments, and accessories. The system can be used by a trained doctor in an operating room environment to assist in the accurate control of compatible endoscopic instruments during robot-assisted urological surgery, gynecological surgery, and other laparoscopic surgeries. The system also allows the surgical staff to reposition the patient by adjusting the operating table during urological surgery, gynecological surgery, and other laparoscopic surgeries without disconnecting the robotic arms. The compatible endoscopic instruments and accessories used with the surgical system are for endoscopic manipulation of tissue, including grasping, cutting, blunt dissection, sharp dissection, retraction, anastomosis, electrocautery, and suturing.

[0023] Turning now to the drawings, Figure 1 is a diagram showing an exemplary operating room environment with a surgical robot system 100 in accordance with aspects of the present subject technology. As Figure 1 shown, the surgical robot system 100 includes a user console 110, a control tower 130, and a surgical robot 120 having one or more surgical robotic arms 122 mounted on a surgical platform 124 (e.g., a table or a bed, etc.), where a surgical tool having an end effector (e.g., a surgical scalpel, scissors, or grasper) is attached to the distal end of the robotic arm 122 for performing a surgical procedure. The robotic arm 122 is shown as table-mounted, but in other configurations, the robotic arm can be mounted on a cart, ceiling, sidewall, or other suitable support surface.

[0024] Generally speaking, a user (such as a surgeon or other operator) can sit at the user console 110 to remotely manipulate the robotic arm 122 and / or surgical instruments (e.g., teleoperation). The user console 110 can be located in the same operating room as the robotic system 100, as Figure 1 shown. In other environments, the user console 110 can be located in an adjacent or nearby room, or remotely operated from a remote location in a different building, city, or country. The user console 110 can include a seat 112, pedals 114, one or more handheld user interface devices (UIDs) 116, and an open display 118 configured to display, for example, a view of the surgical site within the patient. As shown in the exemplary user console 110, a surgeon sitting in the seat 112 and viewing the open display 118 can manipulate the pedals 114 and / or the handheld user interface device 116 to remotely control the robotic arm 122 and / or the surgical instrument mounted to the distal end of the arm 122.

[0025] In some variations, the user can also operate the surgical robotic system 100 in an "on the bed" (OTB) mode, where the user is located on one side of the patient and simultaneously manipulates a robot-driven tool / end effector attached thereto (e.g., holding a handheld user interface device 116 in one hand) and a manual laparoscopic tool. For example, the user's left hand can manipulate the handheld user interface device 116 to control the robotic surgical components, while the user's right hand can manipulate the manual laparoscopic tool. Thus, in these different scenarios, the user can perform both robot-assisted MIS on the patient and manual laparoscopic surgery.

[0026] During an exemplary procedure or surgery, the patient is prepared and draped in a sterile manner to achieve anesthesia. The initial approach to the surgical site can be manually performed using the robotic system 100 in a stowed configuration or a retracted configuration to facilitate access to the surgical site. Once the access is completed, the initial positioning and / or preparation of the robotic system can be carried out. During the surgery, the surgeon in the user console 110 can use the pedal 114 and / or the user interface device 116 to manipulate various end effectors and / or imaging systems to perform the surgery. Manual assistance can also be provided by a person wearing a sterile gown at the operating table, and the tasks that the person can perform include, but are not limited to, retracting tissue, or performing manual repositioning or tool change involving one or more robotic arms 122. There can also be non-sterile personnel to assist the surgeon at the user console 110. When the procedure or surgery is completed, the robotic system 100 and / or the user console 110 can be configured or set to a state that facilitates one or more post-operative processes, including but not limited to cleaning and / or disinfecting the robotic system 100, and / or medical record entry or printout via the user console 110, whether in electronic copy or paper copy.

[0027] In some aspects, the communication between the surgical robot 120 and the user console 110 can be carried out through the control tower 130, which can convert user inputs from the user console 110 into robotic control commands and transmit the control commands to the surgical robot 120. The control tower 130 can also transmit status and feedback from the robot 120 back to the user console 110. The connections between the surgical robot 120, the user console 110, and the control tower 130 can be wired connections and / or wireless connections, and can be proprietary and / or use any one of a variety of data communication protocols to perform. Any wired connection can optionally be built into the floor and / or walls or ceiling of the operating room. The surgical robotic system 100 can provide video output to one or more displays, which include displays in the operating room and remote displays accessible via the Internet or other networks. The video output or feed can also be encrypted to ensure privacy, and all or part of the video output can be saved to a server or an electronic health record system.

[0028] Before beginning a surgical procedure using a surgical robot system, a surgical team may perform pre-operative setup. During the pre-operative setup, the main components of the surgical robot system (the table 124 and robotic arms 122, the control tower 130, and the user console 110) are positioned in the operating room, connected, and powered on. The configuration of the table 124 and robotic arms 122 may be fully retracted, with the arms 122 beneath the table 124 for storage and / or transportation. The surgical team may extend the arms from their retracted positions for draping. After draping, the arms 122 may be partially retracted until needed again. Multiple conventional laparoscopic steps may need to be performed, including trocar placement and insufflation. For example, each cannula may be inserted into a small incision with a trocar and passed through the body wall. The cannula and trocar allow light to enter to visualize tissue layers during insertion, minimizing the risk of injury during placement. Typically, an endoscope is placed first to provide hand-held camera visualization for placement of the other trocars. After insufflation, if needed, manual instruments may be inserted through the cannulas to perform any laparoscopic steps by hand.

[0029] Next, the surgical team may position the robotic arms 122 over the patient and attach each arm 122 to its corresponding cannula. The surgical robot system 100 is capable of uniquely identifying each tool (endoscope and surgical instrument) immediately once attached and displaying the tool type and arm position on the open or immersive display 118 at the user console 110 and on the touchscreen display at the control tower 130. The corresponding tool functions are enabled and can be activated using the main UID 116 and the footswitch 114. The patient-side assistant may attach and detach tools as needed throughout the procedure. The surgeon sitting at the user console 110 may begin the procedure using the tools controlled by the two main UIDs 116 and the footswitch 114. The system translates the surgeon's hand, wrist, and finger movements into precise real-time movements of the surgical tools via the main UID 116. Thus, the system continuously monitors each surgical operation of the surgeon and pauses instrument movement if the system cannot accurately reflect the surgeon's hand movements. During the surgical procedure, in the case where the endoscope is moved from one arm to another, the system may adjust the main UID 116 to perform instrument calibration and continue to control the instrument's movement. The footswitch 114 can be used to activate various system modes, such as endoscope control and various instrument functions, including monopolar cautery and bipolar cautery, without the surgeon having to remove their hand from the main UID 116.

[0030] The table 124 can be repositioned during the surgery. For safety reasons, all the tool tips should be in the view of the surgeon at the user console 110 and under the active control of the surgeon. Instruments not under the active control of the surgeon must be removed, and the table feet must be locked. During table movement, the integrated robotic arm 122 can passively follow the movement of the table. Audio cues and visual cues can be used to guide the surgical team during table movement. The audio cues can include tones and voice prompts. Visual messages on the displays at the user console 110 and the control tower 130 can inform the surgical team of the table movement status.

[0031] System architecture

[0032] Figure 2 FIG. 7 is a block diagram showing exemplary hardware components of a surgical robot system 600 in accordance with aspects of the present subject matter. The exemplary surgical robot system 600 can include a user console 110, a surgical robot 120, and a control tower 130. The surgical robot system 600 can include other hardware components or additional hardware components; thus, this figure is provided by way of example and is not a limitation on the system architecture.

[0033] As described above, the user console 110 includes a console computer 611, one or more UIDs 612, console actuators 613, a display 614, a UID tracker 615, a foot switch 616, and a network interface 618. The user or surgeon sitting at the user console 110 can manually adjust the ergonomic settings of the user console 110 or can automatically adjust the settings according to a user profile or user preferences. The manual adjustment and the automatic adjustment can be achieved by driving the console actuators 613 based on user input or a configuration stored in the console computer 611. The user can perform robot-assisted surgery by controlling the surgical robot 120 using the two master UIDs 612 and the foot switch 616. The position and orientation of the UIDs 612 are continuously tracked by the UID tracker 615, and the state changes are recorded by the console computer 611 as user input and dispatched to the control tower 130 via the network interface 618. Real-time surgical videos of the patient anatomy, instruments, and relevant software applications can be presented to the user on a high-resolution 3D display 614 (including an open display or an immersive display).

[0034] Unlike other existing surgical robot systems, the user console 110 disclosed herein can be communicatively coupled to the control tower 130 via a single fiber optic cable. The user console also provides additional features for improving ergonomics. For example, both an open display and an immersive display are provided as opposed to only providing an immersive display. Additionally, a height-adjustable surgeon's seat and a master UID tracked by an electromagnetic tracker or an optical tracker are included at the user console 110 for improving ergonomics. To improve safety, eye tracking, head tracking, and / or seat rotation tracking can be implemented to prevent accidental movement of the tool, e.g., by pausing or locking remote operation when the user's line of sight is not focused on the surgical site on the open display for a predetermined period of time.

[0035] The control tower 130 can be a mobile point-of-care cart housing a touchscreen display, a computer controlling the surgeon's manipulation of the robotic-assisted instruments, a safety system, a graphical user interface (GUI), a light source, and a video computer and a graphics computer. As Figure 2 shown, the control tower 130 can include a central computer 631 (including at least a visualization computer, a control computer, and an auxiliary computer), various displays 633 (including a team display and a nurse display), and a network interface 638 coupling the control tower 130 to both the user console 110 and the surgical robot 120. The control tower 130 can also house third-party devices, such as an advanced light engine 632, an electrosurgical generator unit (ESU) 634, and a blower and a CO2 tank 635. The control tower 130 can provide additional features for user convenience, such as a nurse display touchscreen, a soft power and an E hold button, a user-facing USB for videos and still images, and an electronic caster control interface. The auxiliary computer can also run a real-time Linux, thereby providing logging / monitoring and interaction with cloud-based web services.

[0036] The surgical robot 120 includes an articulated operating table 624 having a plurality of integrated arms 622 that can be positioned over a target patient's anatomy. A set of compatible tools 623 includes tools 623 that can be attached to / detached from the distal ends of the arms 622, enabling a surgeon to perform various surgical procedures. The surgical robot 120 may also include a control interface 625 for manually controlling the arms 622, the table 624, and the tools 623. The control interface may include items such as, but not limited to, a remote control, buttons, a panel, and a touch screen. Other accessories such as trocars (cannulas, seal cartridges, and packers) and drapes may also be required to perform a surgery using the system. In some variations, the plurality of arms 622 includes four arms mounted on both sides of the operating table 624, with two arms on each side. For a particular surgical procedure, an arm mounted on one side of the table can be positioned on the other side of the table by stretching and crossing under the table and the arms mounted on the other side, so that a total of three arms are positioned on the same side of the table 624. The surgical tool may also include a table computer 621 (such as the table adapter controller 700 to be discussed below) and a network interface 628 that can place the surgical robot 120 in a position to communicate with the control tower 130.

[0037] Network topology

[0038] In one embodiment, the control tower, the table controller, and the robotic arms communicate with each other via a network (such as a ring network, although other types of networks may also be used). Figure 3 is an illustration of the network topology of the embodiment. As Figure 3 shown, the control computer 631 of the control tower uses the Controller RingNet Interface (CRI) 638 to communicate with the table computer (here the table adapter controller (TAC) 700, also referred to as the "base controller" in this document) using a protocol designated as RingNet-C herein, where "C" refers to "Controller RingNet Interface." The TAC 700 uses a different protocol designated as RingNet-A herein to communicate with the robotic arms 622, where "A" refers to "arm." As Figure 3 shown, the TAC 700 can also communicate with a cluster of components of the table 624 (sometimes referred to as the "TAC cluster" in this document). For example, in this embodiment, the table 624 is articulated and has drive motors controlled by a table pivot controller (TPC) 710 to tilt, move, etc. the top of the table. Also as Figure 3 shown, the table power distribution board (TPD) 720, the table base controller board (TBC) 730, and the table speaker board (TSB) 735 communicate with the TAC 700 via a Controller Area Network (CAN). Of course, other components and network protocols that exist now or will be developed in the future may be used. The various table components in the TAC cluster are sometimes referred to as table endpoints.

[0039] Each robotic arm in the present embodiment includes a plurality of nodes between adjacent connectors. As used herein, a "node" generally may refer to a component that communicates with a controller of a robotic surgical system (e.g., TAC 700). The "nodes", sometimes referred to herein as "joint modules", can be used to move one connector of a robotic arm relative to another (e.g., by using a motor to move a series of pulleys and a series of belts connecting the pulleys to facilitate four-bar linkage motion). In response to commands from an external controller (discussed in more detail below), the nodes can be used to articulate the various connectors in the robotic arm to manipulate the arm for surgery. Examples of nodes include, but are not limited to, one or more of the following: a single motor (e.g., a servo motor, a pivot link motor, a joint motor, and a tool drive motor), a dual motor (e.g., having a differential gear drive to combine the output of a single motor), a wireless tool interface (e.g., a tool wireless board), a position sensor (e.g., an encoder that measures the displacement of an arm connector / segment), a force / torque sensor, an input / output board, a component that monitors power, and / or a communication connector, or any other component that can receive / transmit data. The nodes can also include various electronics, such as, but not limited to, a motor controller / driver, a signal processor, and / or communication electronics on a circuit board.

[0040] It should be noted that any one of the controllers in the controller can be implemented in any suitable manner. For example, the controller can take the form of, for example, a processing circuit, a microprocessor or a processor, and a computer-readable medium storing computer-readable program code (e.g., firmware) executable by the (micro)processor, logic gate circuits, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. The controller can be configured with hardware and / or firmware to perform the various functions described below and shown in the flowcharts. More generally, a controller (or module) can include "circuits" configured to perform various operations. As used herein, the term "circuit" can refer to an instruction processor, such as a central processing unit (CPU), a microcontroller, or a microprocessor; or an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a field-programmable gate array (FPGA); or a collection of discrete logic components or other circuit components (including analog circuit components, digital circuit components, or both); or any combination thereof. As an example, a circuit can include discrete interconnected hardware components, or can be combined on a single integrated circuit die, distributed between multiple integrated circuit dies, or implemented in a multi-chip module (MCM) of multiple integrated circuit dies in a common package. Thus, a "circuit" can store or access instructions for execution, or can implement its functions in hardware alone.

[0041] The control PC (Master Controller) 631 can communicate with the robotic arm 622 or with components in the TAC cluster (e.g., TPD 720, TBC 730, and TSB 735). In operation, the control PC 631 sends frames of information to the TAC 700, and the FPGA in the TAC 700 determines whether to route the frame to the TAC cluster or to the robotic arm 622. In one embodiment, communication between the control PC 631 and the robotic arm 622 occurs in real time (or near real time), while communication with the various components in the cluster connected to the TAC 700 can occur in pseudo real time or non real time. Since the robotic arm 622 interacts with the patient, it is preferred that the command / response communication between the control PC 631 and the various nodes (e.g., DSP motor controllers) of the robotic arm 622 is unimpeded, has a very short delay or no delay, and has minimal jitter. In some embodiments, if the arm 622s do not receive communication from the control PC 631 within an expected amount of time, the arm can send an error message. As used herein, if the communication is received before the deadline set for receiving the communication, the communication occurs in real time. Near real time means communication that may be received after the deadline due to transmission delays but is still acceptable.

[0042] In contrast, while communication between the control PC 631 and the TAC cluster is important, it is not as urgent. For example, the hardware in the table base controller (TBC) 730 can detect that the angle of the table has changed (e.g., by detecting a change in the gravity vector), or the hardware in the table power distribution (TPD) board 720 can detect an overcurrent condition in one of the robotic arms in the robotic arm 622, and the software in these components can send an alert message back to the control PC 631 (e.g., which can display the alert on the graphical user interface of the control PC 631). Similarly, while this information is important, it can be delivered to the control PC 631 with a longer delay and / or jitter compared to the delays and / or jitter acceptable in command / response communication with the robotic arm 622. Such communication can be non real time or pseudo real time (i.e., it is not required to receive the communication before a specific deadline).

[0043] As described above, the TAC frame and the arm frame can be separate frames, where the TAC 700 routes the frames to the robotic arm 622 or to the TAC group cluster as appropriate. In one embodiment, the arm frame is a constant-length frame transmitted by the control PC 631 every 4 kHz (250 microseconds), and the TAC frame is a variable-length frame (since the control PC 631 can request information from multiple endpoints in the TAC cluster, and the response lengths can vary). Also, in one embodiment, the arm frame is transmitted in real-time or near real-time, and the TAC frame is transmitted in pseudo-real-time or non-real-time. The arm frame and the TAC frame can be time-division multiplexed in the optical fiber.

[0044] Transition control

[0045] It is possible that a failure may occur in the communication channel between the user console and the TAC, which can cause the surgeon to be unable to move the robotic arm via the user input device at the user console. If this occurs, the position of the robotic arm can be frozen, possibly inside the patient. This can lead to a dangerous situation where the patient is entrapped by the robotic arm. The following embodiments can be used to detect such failures and trigger / facilitate a transition of control from the failing primary computer in the control tower to a secondary computer in the TAC (and one or more backups, if desired) in order to mitigate patient entrapment due to the loss of the primary computer.

[0046] Generally, software mechanisms can be used to interact with the enabling electrical infrastructure to detect, trigger, and transition from a remote operation mode (remote operation) to an independent mode in the event of a failure of the primary and / or secondary robotic control computers. Under normal operating conditions, the computer hosted by the control tower is the primary controller of the robot. Teleoperation (i.e., remote control or remote mode) is only allowed when the primary computer is healthy. The loss of the primary computer can lead to a dangerous situation related to patient entrapment. A standby secondary computer with a backup is provided as a hardware mitigation for such situations. Detection of software, hardware, and / or communication failures and triggering of the switch can be performed by hardware and / or software. For example, in one embodiment, the problem of detecting failures and triggering a switch to the secondary computer is via a software mechanism that, in conjunction with hardware, enables a remote-to-independent transition to the secondary computer. In one embodiment, if the secondary computer fails, a switch can be made to a backup computer. The following paragraphs describe an exemplary implementation of this embodiment. It should be understood that this is only an example and other implementations can be used.

[0047] Returning again to the drawings, Figure 4 is a block diagram of a surgical robotic system of an embodiment. Some components have been described previously in connection with other drawings. As Figure 4As shown, the entire system generally includes a user console 110, a main robotic arm controller 631 (which is sometimes referred to herein as the control PC and can be part of the control tower 130), a table adapter controller (TAC) 700, and one or more robotic arms 622.

[0048] In this embodiment, the user console 110 includes one or more user input devices 612 and a display 614. In the remote operation mode, the surgeon observes the surgical site on the display 614 and uses the user input device 612 to manipulate the robotic arm 622. For this purpose, signals generated by the manipulation of the user input device 612 are sent to the main robotic arm controller 631 in the control tower 130, which converts those signals into robotic control signals sent to the TAC 700 (e.g., on RingNet-C). Then, the TAC 700 issues robotic control signals to the robotic arm 622 via RingNet-A to move them according to the surgeon's movement of the user input device 612. Feedback and other information from the robotic arm 622 can be sent back to the main robotic arm controller 631 via the TAC 700 (e.g., also on RingNet-C).

[0049] As described above, there may be a failure in the message communication between the main robotic arm controller 631 and the TAC 700. If this occurs, the surgeon will not be able to move the robotic arm 622 through the user input device 612 at the user console 110, which can result in the patient being harmed by the robotic arm 622. To address this situation, this embodiment allows the control of the movement of the robotic arm 622 to be transferred from the main robotic arm controller 631 to a secondary robotic arm controller 400 in the TAC 700 in response to a failure in the main robotic arm controller 631. In this way, the secondary robotic arm controller 400 can move the robotic arm 622 in response to signals received from a user input device 420 (e.g., a keyboard on or near the robotic arm 622 or the operating table) that is remote from the user console 110.

[0050] More specifically, as Figure 4As shown, in this embodiment, the main robotic arm controller 631 includes a plurality of processes 430, a process supervisor 440, and a remote coordinator 450. The processes 430, which may be implemented in software (e.g., computer-readable program code executed by a processor) and / or hardware, convert signals provided by the user input device 612 in the user console 110 into commands for the movement of the robotic arm 622. The processes 430 may also perform other functions, such as but not limited to reacting to feedback or other information from the robotic arm 622. The processor supervisor 440, which may be implemented as a QNX High Availability Manager (HAM), is a software and / or hardware module that monitors the operation of the processes 430. The processor supervisor 440 notifies the remote coordinator 450 of the health status of the processes 430 (i.e., whether the processes 430 are in a functional state). One or more processes may not be in a functional state, for example, if there is a power failure, software failure, hardware failure, drive failure, communication interface / channel failure, etc.

[0051] As Figure 5 shown in the flowchart 500 in, the processor supervisor 440 monitors the processes 430 (action 510) and determines whether they are running (action 530). If the processes 430 are running, the processor supervisor 440 notifies the remote coordinator 450 (action 530), and the remote coordinator 450 sends messages (referred to herein as heartbeat messages) to the corresponding independent coordinator 463 in the secondary robotic arm controller 400 at a constant rate (e.g., at a predefined interval) (e.g., via RingNet-C) (action 540). However, if the processes 430 are not running, the processor supervisor 440 notifies the remote coordinator 450 (action 550), and the remote coordinator 450 does not send heartbeat messages to the independent coordinator 463 in the secondary robotic arm controller 400 (action 560).

[0052] As Figure 6 shown in the flowchart 600 in, the independent coordinator 463 monitors the heartbeat messages (action 610) and determines whether a heartbeat message is received (action 620). If a heartbeat message is received, the secondary robotic arm controller 400 continues to monitor for the presence of heartbeat messages. However, if one or more heartbeat messages are not received (e.g., three consecutive heartbeat messages), the independent coordinator 463 detects a failure in the main robotic arm controller 631 and transfers control of the movement of the robotic arm 622 from the main robotic arm controller 631 to the secondary robotic arm controller 400 (action 630).

[0053] This transition can be achieved in any suitable manner. In one embodiment, in addition to the independent coordinator 402, the secondary robotic arm controller 400 also includes a dormant copy of the process 406 in the primary robotic arm controller 631. By having two components with the same process, both the primary robotic arm controller 631 and the secondary robotic arm controller 400 have the ability to move the robotic arm 622 in response to user input. In this embodiment, when the robotic surgical system is powered on, both processes 406 and 430 are initialized, but the process 406 in the secondary robotic arm controller 400 is placed in a dormant state. When the independent coordinator 402 detects a failure by not receiving a heartbeat from the remote coordinator 450, the independent coordinator 402 activates the dormant process 406, thereby taking them out of the dormant state. This allows the process 406 to receive input from the remote user input device 420 to move the robotic arm 622. Again, this movement is performed without involving the primary robotic arm controller 631 in the user console 110 or the control tower 130.

[0054] In addition to causing the process 406 in the secondary robotic arm controller 400 to take over, other actions can be taken to effect the transition of control. For example, during normal operation, real-time information moves from the robotic arm 622 to the switch 460 via RingNet-A and then from the switch 460 to the robotic arm controller 631 via RingNet-C. For example, this information can include feedback information regarding the requested arm movement and error signals. If the primary robotic arm controller 631 is in a failed state, it may not be able to act on this information. Thus, in such a case, the information sent from the robotic arm 622 can instead be routed to the secondary robotic arm controller 400. In Figure 4 the embodiment shown, the TAC 700 includes a switch 460 (e.g., a field programmable gate array or other programmable logic) that is configured to route information from the robotic arm 622 to either the primary robotic arm controller 631 or the secondary robotic arm controller 400. When the secondary robotic arm controller 400 detects a failure in the primary robotic arm controller 631, the secondary robotic arm controller 400 programs the switch 460 to route information from the robotic arm 622 to the secondary robotic arm controller 400.

[0055] Turning now to another feature, it is possible that there could be a failure in process 406 of the secondary robotic arm controller 622, just as there could be a failure in the primary robotic arm controller 631, which could result in the patient being victimized by the robotic arm 400. To address this possibility, the TAC 700 can include a backup robotic arm controller 410 that has a dormant copy of the backup coordinator 412 and its own process 414. (The primary robotic arm controller 631 and the backup robotic arm controller 410 can be implemented on two different system-on-module (SOM) boards.) The process supervisor 404 in the secondary robotic arm controller 400 monitors the health of the processes 406 in the secondary robotic arm controller 400 and determines whether they are running. If the processes 406 are running, the processor supervisor 404 notifies the independent coordinator 402, and the independent coordinator 402 sends a heartbeat message to the backup coordinator 412 in the backup robotic arm controller 410. If the backup coordinator 412 does not receive the heartbeat, it knows that there is a failure and activates the copy of its process 414. The table power distribution panel (TPD) 720 (see Figure 3 ) can be instructed to turn off the power domain to the secondary robotic arm controller 400 (the lack of a heartbeat message from the secondary robotic arm controller 400 to the TPD 720 can accomplish this). Since the switch 460 has already routed information from the robotic arm 622 to the TAC 700, no action is required on the switch 460, and the information can be passed through the secondary robotic arm controller 400 to the backup robotic arm controller 410. Additional backup robotic arm controllers can be used.

[0056] For purposes of explanation, the foregoing description uses specific nomenclature to provide a thorough understanding of the invention. However, it will be apparent to those skilled in the art that the practice of the invention does not require specific details. For purposes of illustration and description, the foregoing description of specific embodiments of the invention has been provided. They are not intended to be exhaustive or to limit the invention to the specific forms disclosed; various modifications and changes are possible in light of the above teachings. The embodiments were chosen and described in order to best explain the principles of the invention and its practical application. Thus, these embodiments enable others skilled in the art to best utilize the invention and various embodiments with various modifications as are suited to the particular uses contemplated. The following claims and their equivalents are intended to define the scope of the invention.

[0057] The above methods, apparatuses, processes, and logic components can be implemented in a variety of different ways and in a variety of different combinations of hardware and software. The controller and estimator can include electronic circuits. For example, all or part of an embodiment can be a circuit that includes an instruction processor, such as a central processing unit (CPU), a microcontroller, or a microprocessor; an application specific integrated circuit (ASIC), a programmable logic device (PLD), or a field programmable gate array (FPGA); or a circuit that includes discrete logic components or other circuit components (including analog circuit components, digital circuit components, or both); or any combination thereof. As an example, the circuit can include discrete interconnected hardware components and / or can be implemented on a single integrated circuit die, distributed among multiple integrated circuit dies, or in a multi-chip module (MCM) of multiple integrated circuit dies in a common package.

[0058] The circuit can also include or access instructions that are executed by the circuit. The instructions can be stored in a tangible storage medium other than a transient signal, such as flash memory, random access memory (RAM), read only memory (ROM), erasable programmable read only memory (EPROM); or on a disk or optical disc, such as a compact disc read only memory (CDROM), a hard disk drive (HDD), or other disk or optical disc; or in or on another machine-readable medium. A product, such as a computer program product, can include a storage medium and instructions stored in the medium, and the instructions, when executed by a circuit in a device, can cause the device to implement any of the processes described above or shown in the drawings.

[0059] These embodiments can be distributed among multiple system components, such as among multiple processors and memories, optionally including multiple distributed processing systems. Parameters, databases, and other data structures can be stored and managed separately, can be combined into a single memory or database, can be organized logically and physically in a variety of different ways, and can be implemented in a variety of different ways, including as data structures, such as linked lists, hash tables, arrays, records, objects, or implicit storage mechanisms. Programs can be part of a single program (e.g., a subroutine), stand-alone programs, distributed across multiple memories and processors, or implemented in a variety of different ways, such as in a library, such as a shared library (e.g., a dynamic link library (DLL)). For example, when executed by a circuit, the DLL can store instructions that perform any of the processes described above or shown in the drawings.

[0060] Additionally, the various controllers discussed herein may take the form of, for example, processing circuitry, a microprocessor or processor, and a computer-readable medium storing computer-readable program code (e.g., firmware) executable by the (micro)processor, logic gate circuits, switches, application specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. The controller may be configured with hardware and / or firmware to perform the various functions described below and shown in the flowcharts. Additionally, some of the components shown as being within the controller may also be stored external to the controller and other components may be used.

Claims

1. A surgical robot, comprising: A user console; A primary controller configured to control the surgical robot in response to a first input from the user console; And A secondary controller configured to control the surgical robot in response to a second input remote from the user console; Wherein the secondary controller is configured to receive communication from the primary controller, and in response to a failure of the communication from the primary controller, transfer control of the surgical robot from the primary controller to the secondary controller; and Wherein the primary controller includes a first plurality of processes for controlling the surgical robot, and wherein the secondary controller includes a dormant copy of the first plurality of processes.

2. The surgical robot according to claim 1, wherein, The primary controller includes a first coordinator, and wherein the secondary controller includes a second coordinator.

3. The surgical robot according to claim 2, wherein, The communication from the primary controller includes a heartbeat message sent by the first coordinator at a predetermined rate.

4. The surgical robot according to claim 3, wherein, When the second coordinator fails to receive one or more heartbeat messages, the failure of the communication from the primary controller is detected.

5. The surgical robot according to claim 3, wherein, The primary controller further includes a supervisor process configured to notify the first coordinator whether the primary controller is in a functional state, and wherein the first coordinator is configured to send the heartbeat message to the second coordinator only when the primary controller is in the functional state.

6. The surgical robot according to claim 1, wherein, Transferring control of the surgical robot to the secondary controller includes activating the dormant copy of the first plurality of processes for controlling the surgical robot.

7. The surgical robot according to claim 1, wherein, The primary controller is further configured to receive status information from the surgical robot when controlling the surgical robot.

8. The surgical robot according to claim 7, wherein, Transferring control of the surgical robot to the secondary controller includes routing the status information from the surgical robot to the secondary controller.

9. The surgical robot according to claim 1, further comprising: A backup controller configured to receive heartbeat messages from the secondary controller at a predetermined rate when the secondary controller is controlling the surgical robot, and Wherein control of the surgical robot is transferred from the secondary controller to the backup controller in response to the loss of one or more heartbeat messages.

10. The surgical robot according to claim 9, wherein, The secondary controller includes a second plurality of processes for controlling the surgical robot, Wherein the backup controller includes a dormant copy of the second plurality of processes, and Wherein transferring control of the surgical robot to the backup controller includes activating the dormant copy of the second plurality of processes for controlling the surgical robot.

11. The surgical robot according to claim 9, wherein, The secondary controller is configured to receive status information from the surgical robot when controlling the surgical robot, and wherein transferring control of the surgical robot to the backup controller includes routing the status information from the surgical robot to the backup controller.

12. The surgical robot according to claim 9, wherein, The backup controller is further configured to instruct a power distribution component to shut off power to the secondary controller.

13. A surgical robot system, comprising: One or more robotic arms, the one or more robotic arms being mounted to an operating table; A user console, the user console including a first user interface device remote from the operating table; A primary controller configured to control the one or more robotic arms in response to input received from the first user interface device at the user console; Means for transferring control of the one or more robotic arms from the primary controller to a secondary controller located within the operating table in response to a failure in the primary controller, wherein the secondary controller is configured to manipulate the one or more robotic arms in response to input received from a second user interface device coupled to the one or more robotic arms and the secondary controller; Wherein the means for transferring control includes (1) activating a dormant copy of a process for controlling the surgical robot at the secondary controller, or (2) routing status information received from the surgical robot when controlling the surgical robot from the surgical robot to the secondary controller.

14. The surgical robot system according to claim 13, wherein, Transfer control of the one or more robotic arms from the primary controller to the secondary controller in response to a failure of communication from the primary controller.

15. The surgical robot system according to claim 14, wherein, The primary controller includes a first coordinator, and wherein the secondary controller includes a second coordinator, wherein the communication from the primary controller includes a heartbeat message sent at a predetermined rate by the first coordinator.

16. The surgical robot system according to claim 15, wherein, The primary controller further includes a supervisor process configured to notify the first coordinator whether the primary controller is in a functional state, and wherein the first coordinator is configured to send the heartbeat message to the second coordinator only when the primary controller is in the functional state.

17. The surgical robot system according to claim 14, wherein, The failure of communication from the primary controller is detected when the secondary controller fails to receive one or more heartbeat messages.

18. The surgical robot system according to claim 13, wherein, The coordinator is configured to transfer control of the surgical robot to the secondary controller by activating the dormant copy of the process for controlling the surgical robot.

19. The surgical robot system according to claim 13, further comprising: A backup controller configured to receive heartbeat messages from the secondary controller at a predetermined rate when the secondary controller is controlling the one or more robotic arms, and Wherein control of the surgical robot is transferred from the secondary controller to the backup controller in response to the loss of one or more heartbeat messages.

20. A surgical robot, comprising: A user console; A main controller, the main controller being configured to control the surgical robot in response to a first input from the user console; And A secondary controller configured to control the surgical robot in response to a second input remote from the user console; Wherein the secondary controller is configured to receive communication from the primary controller, Wherein control of the surgical robot is transferred from the primary controller to the secondary controller in response to a failure of communication from the primary controller; A backup controller configured to receive heartbeat messages from the secondary controller at a predetermined rate when the secondary controller is controlling the surgical robot; wherein control of the surgical robot transitions from the secondary controller to the backup controller in response to the loss of one or more heartbeat messages; and wherein the secondary controller is configured to receive status information from the surgical robot when controlling the surgical robot, and wherein transitioning control of the surgical robot to the backup controller includes routing the status information from the surgical robot to the backup controller.

Images