Invented by Klaus R. Zietlow, Philip L. Graves, Qiong Wu, Roth K. Wiedrick, Verb Surgical Inc

The market for robotic surgical systems has been growing rapidly in recent years, with an increasing number of hospitals and medical centers adopting these advanced technologies to improve patient outcomes and reduce surgical complications. One of the latest developments in this field is the use of a ring-topology communication system, which allows multiple robotic surgical systems to communicate with each other in a seamless and efficient manner. A ring-topology communication system is a type of network architecture where each robotic surgical system is connected to its neighboring systems in a circular pattern, forming a ring-like structure. This allows for quick and reliable communication between the systems, as data can be transmitted in both directions around the ring. This type of communication system is particularly useful in surgical settings where multiple robotic systems are used simultaneously, as it ensures that all systems are working together in a coordinated manner. The method for using these robotic surgical systems with a ring-topology communication system involves several steps. First, the surgical team must ensure that all robotic systems are properly connected to the communication network and that each system is functioning correctly. Next, the team must coordinate the movements of each robotic system to ensure that they are working together in a synchronized manner. This requires careful planning and communication between the surgical team and the robotic systems. Once the surgical procedure begins, the robotic systems can be controlled remotely by the surgical team using specialized software and interfaces. The ring-topology communication system ensures that all systems are receiving the same commands and that they are responding in a coordinated manner. This allows for precise and accurate movements of the robotic systems, which can greatly improve the accuracy and safety of the surgical procedure. The market for robotic surgical systems with a ring-topology communication system is expected to continue to grow in the coming years, as more hospitals and medical centers adopt these advanced technologies. These systems offer numerous benefits, including improved surgical outcomes, reduced complications, and increased efficiency. As the technology continues to evolve, we can expect to see even more advanced features and capabilities in these robotic surgical systems, further improving patient care and outcomes.

The Verb Surgical Inc invention works as follows

A robotic surgery system with a ring-network for communication between a controller, and the nodes of at least one robotic arm is disclosed.” The communication protocol described here allows synchronous and non-synchronous information to be sent and received by the nodes. “Various aspects of a physical network layer are also disclosed.

Background for Robotic surgical systems having a communication system of a ring-topology and a method for using them

Robotic surgery systems” allow healthcare professionals to achieve greater accuracy and automation while performing diagnostic and/or therapy procedures. These technologies can be used in a wide range of medical fields, from anesthesiology and ophthalmology to orthopedics, interventional radiology, and more. Robotic surgical systems can be used to perform minimally-invasive surgery that results in fewer scars and faster recovery times. Laparoscopic surgery is an example of minimally-invasive surgeries. This involves making a few small incisions on the patient’s body (e.g. in the abdomen) and inserting one or more cameras and tools through these incisions. A camera is used to visualize the surgical procedure. The introduced tools are then used. One or more robotic arms may be operated remotely by the user, such as a surgeon.


The following embodiments describe an automated surgical system with a ring-network for communicating information from a controller to nodes on one or more robotic arms. The communication protocol described here allows synchronous and non-synchronous information to be sent and received between the nodes and the robotic arms. A physical layer can also be used in conjunction with the network. The following sections, before moving on to embodiments of the invention, provide examples of a robot surgical system and robotic arm.

Examples of Robotic Surgical Systems

Now, turning to the drawings. FIG. The diagram 1 illustrates an example of a surgical robot system 100 in a typical operating room, according to aspects of the technology. This is only an illustration and other components and arrangements can be used. The details shown here should not be incorporated into the claims, unless they are explicitly stated.

As shown in FIG. The surgical robotic system 100 includes a surgeon console, a control panel, and a number of surgical robotic arms located on a surgical robot platform 110. The robotic arms 112 are equipped with surgical instruments and end effectors at their distal ends for performing a surgical procedure. The robotic arms are shown mounted on a table, but they can also be mounted on a cart or ceiling, sidewall or any other suitable surface.

In general, an operator or surgeon can use the console 120 to remotely operate the robotic arms 112 (e.g. teleoperation) and/or surgical tools. As shown in FIG., the user console 120 can be placed in the same room as the robot system 100. 1. In other environments the console may be in another room or in close proximity, or it can be tele-operated remotely from a location outside of a building, city or country. The user console may include a seat, foot-operated control 124, handheld user interface device 126 and at least one display 128 that can display, for instance, a surgical site view inside a patient. In the exemplary console 120, the surgeon seated in the seat 122 can use the foot-operated control 124 or handheld user interface device 126 to remotely operate the robotic arms 112. This includes surgical instruments attached to the distal end of the arms.

In some variations, the user can also operate the surgical robot system 100 “over the bed” In the OTB mode, the user stands at the side of the patient and simultaneously manipulates both a robotically driven tool/end-effector (e.g. with a handheld interface device 126 in one hand), and a laparoscopic manual tool. The user may, for example, use his left hand to manipulate a handheld interface device 126 in order to control a robotic component while using his right hand to manipulate a manual tool. In these variations, a user can perform both robotically-assisted minimally invasive surgery (MIS), and manual laparoscopic surgeries on a patient.

During a typical procedure or surgery, a patient is prepared and draped in an anesthetic fashion. The robotic system 100 may be manually manipulated to gain access to the surgical area in the stowed or withdrawn configuration. After the initial access, the robotic system can be prepared or positioned. During the procedure, the surgeon may use the foot-operated control 124 or user interface device 126 in the user console to manipulate end effectors and/or image systems to perform surgery. Manual assistance can also be provided by sterile-gowned staff at the procedure table. They may perform tasks such as but not limited, to retracting tissues, performing manual repositioning, or tool exchange using one or more robotic arm 112. The surgeon may be assisted by non-sterile personnel at the user console. “After the surgery or procedure is complete, the robot system 100 or user console can be set up or configured to facilitate one or several post-operative tasks, including but without limitation, cleaning or sterilizing the robotic system, or printing or entering healthcare records, electronic or hardcopy, via the user console.

In some cases, communication between the robot platform 110 and user consoles 120 can be done via the control tower 130. This tower may translate the commands of the user consoles 120 into robotic commands, and then transmit them to the robot platform 110. The control tower may also send status and feedback back from the robotic platform to the user console. The connection between the robotic platform 120, the user console and the control tower can be made via wireless or wired connections. They may also be proprietary, and/or use a variety data communication protocols. Wired connections can be built into the walls, ceiling or floor of the operating room. The surgical robot system 100 can output video to one or multiple displays. These displays may be located in the operating room or remote displays that are accessible over the Internet or other networks. Video output or feed can also be encrypted for privacy, and portions or all of it may be stored on a server system or electronic health record system.

FIG. The diagram in Figure 2 illustrates one example of a robot arm, tool drive and cannula with a surgical instrument, according to aspects of the subject technologies. As shown in FIG. As shown in FIG. The joint modules can include different types such as a roll or pitch joint which can constrain the movement between adjacent links. In the example design of FIG. A tool drive 210 can be attached to a distal end of a robotic arm 112. The tool drive may include a stage or base 212, and a cannula (e.g. endoscopes, staplers etc.) coupled to its distal end to receive and guide the surgical instrument 220. The surgical tool (or instrument) 220 can include a robotic arm 222, and one or more distal end effectors at the distal tip of the tool. The robotic arm 112’s joint modules can be moved to position and align the tool drive 210. This actuates both the robotic wrist and one or more end effectsors for robotic surgery.

The robotic hand 112 includes also a plurality nodes between adjacent link. A ‘node’ is used in this document. A component that is able to communicate with the controller of a robotic surgical system can be referred to as a?node. A “node” A ‘node,’ The joint module can be used to actuate one link in the robotic arm relative to another. (e.g. by using a motor that moves a series pulleys, and a set of bands connecting the pulledeys for four-bar movement). The nodes, in response to commands received from an external controller (discussed below in greater detail), can be used in order to articulate the various robotic links to manipulate the arm during a surgical procedure.

Nodes can be any of the following, without limitation: a single or dual motor (e.g. a servomotor or a motor that drives a joint or pivot), a wireless interface for a robotic arm (e.g. an encoder which detects and transmits signals indicating at least one force or torque applied between the links/segments of the robotic arm), an input/output panel, an electronic component that monitors the power or communication links or another component capable of receiving/transmitting data Nodes can also contain various electronics such as a motor driver/controller, signal processors and/or communication electronics on a board. The nodes, as will be explained in greater detail below can be arranged into a ring-like network to communicate with an external controller. In one embodiment, control of the tool on the robotic arm can be done using a wireless tool. This is to ensure electrical isolation between the tool, and other components of robot, for safety purposes.

Example of a Communication Network of a Robotic Surgical System”.

Returning back to the drawings, FIG. A communications network for a robotic surgery system is illustrated in FIG. As shown in FIG. As shown in FIG. The robotic surgical system of this embodiment comprises a master controller 302 (also referred to herein as?the robot controller? Or simply “the controller?” The base controller 304, also referred to as the “second controller” herein, is in communication with a plurality of robotic arms (ARM 1-ARM n). The base controller 304 (also referred to as ‘the second controller? The phrase “in communication with” is used in the following. The phrase “in communication with” can mean either directly or indirectly through one or more components that may or may be shown and described in the present invention. Signals from the base controller 304 and master controller 302 can be sent to the nodes via wired connections that are bundled together (e.g. in a cable harness) and pass through the internal volumes of arm links and joint module of the robotic arm. It should also be noted that FIG. In some embodiments, the base controller may not be needed even when a robotic surgery system has a plurality robotic arms. In some embodiments the base controller is not used when the robotic surgery system has multiple robotic arms. In one embodiment, the base control 304 is positioned near or on the patient’s bed or table (in this case, it may also be called the table adapter controller, or?TAC? In one embodiment, base controller 304 is located near or in the patient table or bed (in such situations, the base controller 304 may be referred to as the table adapter controller (?TAC?

It should be noted that all controllers can easily be implemented. A controller could be implemented as logic gates, switches or an ASIC, an application-specific integrated circuit, a programmable controller, an embedded microcontroller etc. A controller may be configured to perform various functions using hardware or firmware. A controller (or module), in general, can include?circuitry’. The circuitry can be configured to perform different operations. The term “circuitry” is used in this document. The term “circuitry” can be used to refer to a central processing unit (CPU), a microcontroller or a processor; an Application Specific Integrated Circuit, Programmable Logic Device, Field Programmable Gate Array, or a collection discrete logic components such as analog circuit components or digital circuit components; or any combination of these. Circuitry can be discrete hardware components, interconnected or distributed across multiple integrated dies or in a Multi Chip Module (MCM), which is a collection of integrated dies. Accordingly, ?circuitry? “Circuitry” can store or retrieve instructions to be executed or implement its functionality solely in hardware.

The master controller 302 is able to receive commands for manipulating the robotic arms from the user console 100. “The master controller 302 can receive commands from the user console 100 (FIG. As shown in FIG. In this embodiment, each robotic arm’s nodes are arranged into a ring-like network. Ring networks are used in this document to refer to a topology of a network where each node is connected to two other nodes to form a continuous signal path through each node. Each node on the path handles each packet of data. It is possible to balance the propagation delay, particularly for nodes located at the distal ends of the robotic arms. Although FIG. While FIG. The ring network, as will be discussed more in detail below, can be used to communicate both real-time information and asynchronous data across the robotic arms network.

The master controller 302 can communicate with the nodes of a robotic arm by using a multi node message. This message is composed of a number of packets. Each packet corresponds to a node of the robotic arm. The multi-node arm message is “multi-node” The arm multi-node message is?multi-node? Any suitable method can be used to associate a packet with a node. Each packet can be addressed (e.g. using the node’s identifier) to a separate node in the robotic arm, and/or nodes can be assigned to specific packet positions in a message. These are only examples. Other associations can also be used.

Each packet of the multi-node messages can be formatted any way that suits you. As shown in FIG. In one embodiment, the packet of a multi-node message may contain a header field, a payload data, and a CRC (cyclic redundancy checking) field. FIG. The packet includes a CRC field of 16 bits (e.g. CCITT), a 16 bit header, data payloads with a fixed length (e.g. 128 or 224 bits) that include asynchronous, non-cyclic and cyclic data. The packet framing can be used as a confirmation of the start of a packet. Payload data types can be used to determine data format (e.g. motor command, motor output, digital inputs and digital outputs). A node can use the channel ID to confirm that a packet is meant to be delivered to it. In one embodiment, each node on all robotic arms has a unique ID. The sequence field is used by a node to determine if the packet it receiving is new. Every time the master controller 302 sends a packet, it increments its sequence number. The master controller 302 can be interrupted and a node will see the same number twice, which is an indication that it’s a duplicate packet. The CRC field may cover the entire package. In one embodiment there are 80 frames with the same number of packets. This is only one example. Other configurations are possible.

If only one robotic hand is being used, the master control 302 can send a multi-node message to the arm directly. When multiple robotic arms are being used, the master control 302 can send the multi-node message for all arms in one single message to base controller 304. The base controller can separate each multi-node from the single message, and send each robotic arms its individual multi node messages. The base controller 304, for example, can send messages to different robotic arm based on their offset within the combined message.

After the individual multi-node message passes through the ring, the base control 304 can combine them into a returned merged single message and send it to the master control 302. Base controller 304 may be configured to perform additional functionality. The base controller 304, for example, can be used to move robotic arms when the master controller 302 has not been plugged in. (e.g. allowing a nursing assistant to move robotic arms before drapeing a patient).

Click here to view the patent on Google Patents.