gms | German Medical Science

GMS Current Topics in Computer and Robot Assisted Surgery

Deutsche Gesellschaft für Computer- und Roboterassistierte Chirurgie (CURAC)

ISSN 1863-3153

Tool centered architecture for computer integrated surgery (CIS)

Research Article

Suche in Medline nach

  • corresponding author Helge Peters - Institute for Process Control and Robotics, Universität Karlsruhe (TH), Karlsruhe, Germany
  • author Heinz Woern - Institute for Process Control and Robotics, Universität Karlsruhe (TH), Karlsruhe, Germany

GMS CURAC 2006;1:Doc10

Die elektronische Version dieses Artikels ist vollständig und ist verfügbar unter:

Veröffentlicht: 9. Oktober 2006

© 2006 Peters et al.
Dieser Artikel ist ein Open Access-Artikel und steht unter den Creative Commons Lizenzbedingungen ( Er darf vervielfältigt, verbreitet und öffentlich zugänglich gemacht werden, vorausgesetzt dass Autor und Quelle genannt werden.


Today, surgical robot systems are huge and expensive. This is at least in part due to the monolithic architecture of such systems. Robot arm (manipulator) and the surgical tool - in this context we speak of the end effector - are considered as one tool, as well mechanically as from the software side. But only if one can separate robot and surgical tool and reuse the robot in other interventions with other end effectors, one can take it as the "automatically controlled, reprogrammable multipurpose manipulator" as it is defined by ANSI, RIA and ISO.

This article describes our architecture that takes the surgical instrument as the central component and that all the other devices or modules can easily connect to in order to form a system for computer integrated surgery (CIS). The article motivates and describes this architecture and explains an example implementation.

Keywords: architecture, medical robots, surgical instruments


Robotics in surgery is still evolving [1]. Although robots promise higher precision and dexterity in an operation, in most cases, the effort needed for using such systems exceeds their benefit.

While there are computer controlled surgical tools that can be guided manually, such as the “Intelligent Tool Drive” [2] or Navigated Control [3], there are also systems, where the use of a robot is useful. While some robots have very special kinematics, many systems use standard robots to handle a surgical tool. Examples are shown in Figure 1 [Fig. 1]. The “Otto” (top left) is a system for drilling holes into a patient’s skull for the fixation screws of ear prostheses. The robot has a tripod kinematic with additional joints. Attached is a drilling device. CyberKnife® for radiosurgery [4] (top right) uses a standard 6-dof serial kinematics robot arm that carries a large and heavy linear accelerator and localizes it in numerous positions and orientations very exactly, where it has to stay steadily for sometimes more than 30 seconds. The system “Evolution 1“ [5] (bottom left) uses a robot with hexapod kinematics mounted onto a big stand. The last system (bottom right) uses a standard 6-dof industry robot as well. Carrying a laser beam scanning head, it is a system for laser osteotomy [6], where a laser beam is fired on the same tiny spot several hundred times for cutting just 1 mm into the bone at that position. The beam is fired with very high frequency, but in order to avoid local heating, thus necroses, the beam must not hit the same spot twice within a specific period of time. Therefore the beam fires a well defined pattern, treating other spots before returning to the first one. The required precision for this can not be reached by a human. Thus the rapid deflection of the laser beam is carried out by a 3D beam scanning head, which has a small working range and itself must be mounted very steadily. So, to have a larger operating range, it has to be carried by a robot, too.

Yet, robot systems for surgery are very expensive. One reason is certainly the monolithic architecture of such systems. The whole robot system is regarded as one tool for the surgeon; although, in fact, the system consists of at least two separate devices: A robot arm and the surgical tool - in this context we speak of the end effector.

Acknowledging robot and surgical tool as two separate devices would make it possible to reuse each robot in other interventions with other end effectors. This way it can be seen as the "automatically controlled, reprogrammable multipurpose manipulator" as defined by ANSI, RIA and ISO [7]. So, while the robot is just a support, the surgical tool has to be the central component of any CIS system.

Related work

The robot system “RobaCKa”, developed at our lab, is an example for such a rather monolithic robot system. Its architecture is depicted in Figure 2 [Fig. 2]. RobaCKa has been developed for performing research on automatic methods in cranio- and maxillofacial surgery and for gaining experience with robotized CIS systems. The robot used in this system is a Staeubli RX90 (like the one in Figure 1 [Fig. 1], bottom right). Its end effector includes a mechanical overload protection, a force/torque sensor, reference frames of an infrared tracking system and a bone milling tool. The robot’s manufacturer specific control and all of the other devices are connected to one central computer, each using its specific interface. On this computer, three modules handle the specific devices (infrared tracking system, force/torque sensor and robot) and the graphical user interface (GUI). A central communication module (COM) performs the message exchange between the other modules and is responsible for the data exchange with the robot control.

This central computer keeps all knowledge about the connected devices, e.g. the robot’s geometry, the way to address the force/torque sensor (CAN-Bus), the tracking system or the robot control (both RS-232). This results in a very high effort for a system that is “only” capable of milling preplanned trajectories into a patient’s skull. Neither is it possible to extend the system nor to replace single devices without considerable effort in reprogramming parts of the software. This means as well, that the system can not be used for other tasks than the one it had originally been designed for.

A distributed architecture for surgical robot systems has been proposed in [8]. After an analysis of various surgical robot systems the authors defined a framework combining their common properties. This enables faster implementation of further similar systems. Based on CORBA (Common Object Request Broker Architecture) the single modules of such a system, e.g. operation planning tool, visualization station and robot control, may be run on different computers linked via LAN (local area network). Servers “translate” between the hardware devices and the network. They make the devices available to applications. Yet the system is set up around a robot and disregards robotless CIS systems. And again any surgical tool is seen as immanent to the robot.

An architecture for CIS systems, where robot and tool are cooperative, yet independent components of a system has not been published so far.


In our approach, the robot is just be an assistive system for the actual surgical tool. The idea is that a robot can be connected to a tool (end effector) so that the tool can command the robot to locate it in a certain pose.

Extending this idea, we suggest a network, where each device of a computer integrated surgery system (CIS) can call on each of the other devices. This leads to a highly distributed system with specialized devices that can be plugged together just as needed for a specific task.

In order to support CIS with multiple tools and that are open to support all kinds of devices and sensors like visualization monitors, tracking systems, graphical user interfaces, robots and so on, we propose:

A distributed system where all devices offer services to the other devices on a network
Tool and transportation device (robot) are understood as two separate devices.
The devices keep knowledge about themselves and act automatically or autonomously.


Our system architecture (see Figure 3 [Fig. 3]) bases on services rather than on objects or devices [9]. Thus for us, a robot is just one possible device to offer a transportation service, taking into account, that not only a robot but also another device or even a person could provide the service of bringing something into a certain position. In a larger scope, any component or device offers services to all of the others and it can make use of the services offered by them. Since most devices are not freely programmable, they are represented in the network by proxies or servers. A server will offer services to the other servers, depending on the connected devices. A server to which a tracking system is connected, for example, will work as a tracking system server offering a tracking service. We propose a peer-to-peer like network architecture [10] where the servers access each other with remote process calls (RPC When we use the term “server” in this context, we keep in mind that each computer in the network can be client and server at the same time. The server is a kind of a proxy, communicating and controlling the device on one hand side, and on the other offering services to the network and, as far as required, request services from other servers using RPC. But not only devices are represented by a server. All parts of a CIS can offer their services. A patient, represented by a “patient server”, may provide its position and a planning system the operation plan, for example.

In order to keep the servers replaceable, they have to stick to well defined interfaces. We defined some of them for the services that should be public, i.e. available to any server in a CIS system. The services are:

  • init: This service returns which services are offered by the server.
  • block: This service is called to gain exclusive access to a service by blocking it for other clients (e.g. only one client may control a robot).
  • release: The counterpart for the block service.
  • setReference: Using this service one device can tell another one the pose of a reference point. This way the called server can obtain the transformation to the calling client’s coordinate system. Starting, e.g. from the patient, one common coordinate system can be dispersed over all devices.
  • isRegistered: Finds out whether a device has already been registered to a common coordinate system.
  • getPose: This service will be called to acquire a devices Position.
  • moveToPose: Can be called to have a device move to a specific pose (position and orientation).
  • Stop: Makes a device stop its current action.
  • getForceTorque: Obtains the force and torque applied to a device.
  • getOperationPlan: Acquires an operation plan, e.g. from an operation planning system.
  • showMenu: Prompts a menu to the user.

A server controlling a tracking system, for example, would offer the services “getPose” and “isRegistered”. Any other server could connect to it as a client and ask it whether it has already been registered to the overall system and ask for the current position and orientation.

Therefore, of course, any device has to know that it is connected to a specific tracking system i.e. to the corresponding tracking server. In this approach it is the user who connects the two using a graphical user interface.

A surgical instrument server that wants to be tracked would search the network for servers offering the “getPose” service. Then it would display a menu asking the user which of the servers it should connect to.

This way a surgeon can choose even intraoperatively, whether he/she would like to move an instrument manually or whether a robot present in the network should move it. The current CIS setup can be configured within seconds. Alternatively, a configuration can of course be saved in and loaded from a file.

All servers dealing with poses (i.e. position and orientation of an object) must agree on a common coordinate system. This reference coordinate system is originally defined by the patient. Because there can only be one patient in a CIS system, this ensures that there is only one reference system. Whenever a server that knows the reference system, i. e. that has been registered to the CIS system, connects to a server that has not been registered so far, it passes the reference coordinate system to the other server. This works out as long as the geometric relationship between the two is known to at least one of them.

Other than that none of the servers can or should be configured by another one. Each server keeps all of the knowledge it needs to perform its task or it requests necessary information by calling the services of other servers. This allows easy replacement of any server or service at any time.

The surgeon acts as a referee, initiating, directing and stopping processes.

It is important to note, that in this approach a robot and its end effector are two independent devices, since the end effector is a surgical instrument that can – but needs not - be fixed to a robot.

Experimental setup

For first experiments we used a tool for the trephination of skull bone [11] (see Figure 4 [Fig. 4]) and set up a server for a Stäubli RX90 robot. The end effector consists basically of a base compound containing an active linear axis and a force/torque-sensor, and the drilling/milling hand piece just as used for manual surgery (see Figure 2 [Fig. 2]). The force/torque sensor allows the detection of a skull’s outer and inner border by measuring the process forces. In order to minimize the positioning errors resulting from errors in the robot’s joint positioning in conjunction with the distance between the robot’s flange and the tool tip, this distance was kept as small as possible. The hand piece’s motor cable is a source of unintentionally measured forces for the force torque sensor. To keep these small, the hand piece’s cable outlet was brought as close to the sensor as possible, so that torques induced by the cable would be far less significant than those induced by the tool tip. In order to keep the end effector small and its weight down, we use four ultrasonic motors which are self-locking. This is an advanced safety feature and supersedes additional brakes. The legs of the motors run on ceramic pads integrated into the base compound with minimum steps of 0.1 µm. The loop is closed by an incremental sensor with a resolution of 1 µm.

The end effector server bases on an embedded PC (PC/104+) with a 700MHz Pentium 3 processor, small and stable enough to be placed on a robot joint. Further miniaturization should make it possible to have it stored in the end effector’s base compound.

The server runs a Real Time Linux operating system ( and offers the services “init”, “getForceTorque” and “getPose”. A connected robot can use the “getForceTorque” service to realize a so called force controlled mode, where it moves according to the forces and torques applied to the tool by a human.

Since the robot control itself does not have an Ethernet interface and does in no way support RPC, a proxy has been inserted as the robot server (Pentium 4, 2 GHz). It communicates with the robot control via RS232. While most of the functionality has been implemented in the server software, only the angels for the robot joints are transmitted to and from the robot control with a maximum update rate of 20 positions per second. The robot server offers the services “init”, “block”, “release”, “setReference”, “isRegistered”, “getPose” and “moveToPose”.

Because it would be a nuisance for the op staff if they had to watch multiple monitors and use multiple keyboards, we set up one GUI (graphical user interface) server, offering services for user communication.


For testing the feasibility of our architecture, we implemented a force controlled mode, so a surgeon could easily grip the surgical tool attached to the robot and guide it to wherever he likes.

Upon system start, the tool looks out for and finds a transportation service. Meanwhile it calibrates its force/torque sensor for subsequent weight compensation. After that, it offers the “getForceTorque” service to any other device in the CIS network.

The robot server will now find this service and offer a force control moving mode to the user.

During force control, the robot server requests the current force applied to the end effector from the tool server. The latter then requests the current robot position from the robot server in order to be able to compensate for the tool weight and the torque, which of course depends on the tools orientation. Then the tool server sends the current forces and torques applied to it to the robot. In our 100MBit Ethernet LAN, using the TCP, one such cycle takes up to 3 msec. The robot position reported to the tool server may be up to approx. 50 msec old itself, though, because, as mentioned earlier, the robot server and the robot control communicate via a serial connection and with a maximum speed of 20 datasets per second.

The methods for measuring force/torque data and controlling the tool feed for trephining skull bone is completely implemented in the tool server. So the tool would work on any robot.


We propose a distributed architecture for computer integrated surgery systems. Its major benefit is that various devices (sensors, robots, surgical instruments) can freely be connected to form a computer integrated surgical tool for a specific task.

The physical decomposition and reassembly is anyway required since some parts (e.g. milling tool) must, others (e. g. robot) can not be sterilized.

To enable “plug and work” behavior, the single devices must be self configuring to a very high degree (see also [12]). They have the whole knowledge about themselves and the methods they are used for. The connection of the components via a network causes latencies and is not always reliable. Therefore each device has to guarantee safety for patient, medical staff and the surrounding systems as far as any possible. In combination, the overall system will thus be even safer.


Korb W, Marmulla R, Raczkowsky J, Muehling J, Hassfeld S. Robots in the operating theatre - chances and challenges. Int J Oral Maxillofac Surg. 2004;33(8):721-32.
Pott P, Köpfle A, Wagner A, Badreddin E, Männer R, Weiser P, Scharf H, Schwarz M. Erste Versuche mit dem handgehaltenen Operationsroboter ITD. In: Biomedizinische Technik - Beiträge zur 38. Jahrestagung der Dt. Gesellschaft für biomediznische Technik im VDE. 2004. p. 72-3.
Kneissler M, Hein A, Matzig M, Thomale U, Lueth T, Woiciechowsky C. Concept and clinical evaluation of navigated control in spine surgery. In: Advanced Intelligent Mechatronics, 2003. AIM 2003. Proceedings. 2003 IEEE/ASME International Conference on Advanced Intelligent Mechatronics. 2003. p. 1084-9.
Schweikard A, Shiomi H, Adler JR. Respiration tracking in radiosurgery. Med Phys. 2004;31(10):2738-41.
Rachinger J, Nissen U, Bumm K, Iro H, Fahlbusch R, Nimsky C. Experimentelle und klinische Erfahrungen mit dem Robotersystem ‚Evolution1'. In: CURAC. 2004.
Woern H, Peters H. LASER Based Osteotomy with Surgical Robots. Biomedizinische Technik. 2005;50(Suppl. Vol. 1, Part 1):25-6.
ANSI/RIA R15.06-1999; ISO 8373:1994.
Schorr O, Hata N, Bzostek A, Kumar R, Burghart C, Taylor RH, Kikinis R. Distributed Modular Computer-Integrated Surgical Robotic Systems: Architecture for Intelligent Object Distribution. In: Medical Image Computing and Computer-Assisted Intervention - MICCAI'00. 2000. p. 979-87.
Peters H, Raczkowsky J, Woern H. Approach to an Architecture for a Generic Computer Integrated Surgery System. In: 2005 IEEE/RSJ International Conference on Intelligent Robots and Systems. 2005. p. 3751-6.
Bengel G. Grundkurs Verteilte Systeme. 3. Auflage 2004. Wiesbaden: Friedr. Vieweg & Sohn Verlag/GWV Fachverlage GmbH; 2004.
Peters H, Raczkowsky J, Woern H. An Automatic Surgical End Effector for a Distributed Surgical Robot System. Biomedizinische Technik. 2005;50 (Suppl. Vol. 1, Part 2):1266-7.
Korb W, Bohn S, Burgert O, Dietz A, Jacobs S, Falk V, Meixensberger J, Strauss G, Trantakis C, Lemke HU. Surgical PACS for the digital operating room. Systems engineering and specification of user requirements. Stud Health Technol Inform. 2006;119:267-72.