To develop a surgical robot that can operate in harsh environments, our group has focused on miniaturization and mobility. This design work draws on research we did several years ago. In that research, we collaborated with Mika Sinanan, a professor of surgery at the University of Washington, to attach position and force sensors to minimally invasive tools. We gathered sensor data as Sinanan and other surgeons operated on animals by cutting into the body, severing and suturing arteries, lifting out organs, and sewing up incisions. The measurements revealed the actual workspace the tools require and the magnitudes of force and torque for performing a variety of procedures.

With this information we were able to optimize the robot’s dimensions and motion, minimizing the space it occupies without compromising its manipulation capabilities. To do that, we wrote software that generated 5476 different designs by varying the size and shape of the segments and joints that make up the robot’s arms. Using the program, we selected the smallest design that meets all the requirements of minimally invasive surgery and also of soft-tissue procedures typically performed as part of general, vascular, cardiac, and urological surgery.

Why is size so important? Yulun Wang, one of the pioneers of surgical robotics, once said that the most precious space in the whole world is the operating room space directly above a patient. No matter how big the operating room is, the space above the patient is always roughly the same: about 1 by 0.5 by 0.25 meters for an adult patient. In a robotic surgery setup, that space needs to accommodate at least two and ideally four robotic arms, as well as one or more video cameras for the surgeon to see the results of each robotic maneuver.

Our current prototype has two articulated arms. Each arm consists of four aluminum segments connected by rotary joints. It holds a stainless steel shaft 30 centimeters long and 5 millimeters in diameter to which different surgical tools—scalpels, graspers, clip appliers, scissors—can be attached. An articulation at the extremity of the shaft works as a wrist, giving additional mobility to the tools.

We built the arms with steel cables running through them and converging toward a fixed base, where six brushless dc motors used to pull them are housed. With this configuration, you don’t have to embed the motors into the arms themselves, enabling them to be smaller and lighter. The arms can each move in six distinct ways (six degrees of freedom), and they can be attached to a surgical table or to the walls or ceiling of the operating room.

The robot’s control system uses a standard PC running a real-time operating system based on Linux. One thousand times every second, the control system receives a variety of input signals: readings from the robot’s position sensors, motion commands from the surgeon’s console, and status and safety signals from circuits inside the robot. After processing the data, the control system generates electrical currents to guide the motors.

As for the surgeon’s console, we’ve been using off-the-shelf devices until we have the resources to design a more robust system. The console includes two Phantom Omni haptic devices, which are motion-tracking joysticklike controls, from SensAble Technologies, that connect to a PC. The PC, in turn, communicates with the robot through a standard Ethernet link.

That means the robot and the surgeon can be in the same room, connected by an Ethernet cable, or on different continents, connected through the Internet. Indeed, in a recent transatlantic experiment, surgeons at Imperial College in London successfully controlled our robot in Seattle using a regular Internet connection. They used a PC and haptic devices available there, and the software for the video links—iChat and Skype—was not only off-the-shelf, it was free. Although the quality was not the same as what we get with our MPEG hardware, we were impressed with the detail and smoothness of motion.

Our PC-based control console also includes features important to robotic surgery. For instance, like earlier systems, it can scale down motion. That means that the surgeon’s hands can move relatively large distances while the robot’s arms move shorter distances. This is particularly useful when the surgeon is operating on small body structures while looking at a magnified video image. We hope that with our simple control interface, more surgeons will be able to learn and experiment with our robot.

The distinguishing aspect of our work, as mentioned earlier, was to make surgical robots smaller and easier to deploy in places other than conventional operating rooms—the reason, of course, that we wound up in California this past summer. That experiment was part of a U.S. Army project called High Altitude Platforms Mobile Robotic Telesurgery. Its overall goal was to demonstrate the concept of remote robotic surgery in the field, using a rugged surgical robot and an airborne communications link.

The communications platform was provided by AeroVironment, best known for its unmanned aerial vehicles (UAVs). The Army decided to go with a UAV because earlier remote surgery experiments had turned up problems with satellites, which aren’t always available and whose communication delays—often a second or more—make surgery hard. UAVs are an attractive alternative: they can be compact and low cost, and they can fly as low as 100 meters or as high as 30 000 meters from the ground. AeroVironment alone has about 4000 small UAVs flying in Iraq and Afghanistan.

Our experiment took place at an isolated site north of AeroVironment’s headquarters in Simi Valley. With the robot and the surgeon’s console set up in different tents 100 meters apart, AeroVironment engineers sent one of their UAVs, called the Puma, to fly autonomously in circles about 100 to 200 meters above us. Internet-style data packets streamed through the UAV and between the two tents. To transmit video using the 2 megabit-per-second channel available, a high-performance MPEG encoder-decoder device by HiaVision Systems compressed the video signal.

Taking turns at the surgeon’s console were Timothy Broderick, who is a professor of surgery and biomedical engineering at the University of Cincinnati, and Lynn Huffman, also from the department of surgery at the University of Cincinnati. Their eyes on a video monitor and their hands at the haptic controls, the surgeons moved the tools along specific paths in space and positioned their tips at predetermined spots on the latex objects. They were able to simulate various maneuvers that surgeons normally perform, including suturing, which is one of the most complex surgical tasks in minimally invasive procedures, when surgeons must sew up tissue and vessels well under the patient’s skin. During the experiment, we measured manipulation delays of 20 millisconds and video delays of 200 ms, both noticeable by the surgeons but not enough to interfere with their control of the robot.

In the next phase of the project, expected to take place sometime next year, the UAV will fly much higher and the surgeon’s console will be located not 100 meters from the robot but 2000 km away, at our Seattle lab. The experiments will help us better understand how remote surgery works when relying on UAV-enabled links, Internet connections, and combinations of them. In fact, some people wonder about the vulnerabilities of airborne communications. What would happen if the UAV is shot down, interrupting the surgeon-robot connection? To avoid such problems, the best solution seems to be redundancy. It’s likely that when surgical robots are deployed, they will use multiple communications links, enabled by a fleet of UAVs, which could fly at stratospheric altitudes, making it difficult for rockets to reach them.

In any case, surgical robots need to have a host of monitoring circuits to guarantee that they are fail-safe. One of the hardware safety systems we developed controls the transitions among four states of our robot: E-Stop, in which power is removed from the motors and brakes are applied; Initialize, in which the robot checks its operation and range of motion prior to surgery; Pedal‑Up, in which the surgeon uses a foot pedal to determine that the robot is ready to respond to commands but still has the brakes applied; and Pedal-Down, in which actual surgery is performed.

The robot’s control system guarantees that the robot is always in one of these four states. In addition, if the control system detects any type of software or hardware failure, it puts the robot in the E-Stop state within 20 ms.