Sofie (surgical robot)

The Surgeon’s Operating Force-feedback Interface Eindhoven (Sofie) surgical robot is a surgical robot developed at the Eindhoven University of Technology. It was developed as part of a Ph.D thesis by Dr. Ir. Linda van den Bedem and is the first surgical robot to incorporate force feedback.[1][2]

Background

The Sofie surgical robot was developed as part of the Ph.D work of ir. Linda van den Bedem on the improvement of existing surgical systems.

The surgical systems commercially available as of September 2010 (such as the da Vinci Surgical System) all focus on translating movements made by a surgeon at a surgical console into movements by robot arms. However, a great limitation of this generation of robots is a complete lack of any tactile feedback: the surgeon cannot feel what he is doing, so he must rely completely on visual feedback to check his incisions, sutures and so on. A secondary drawback to this generation of robot is the average size and bulkiness, limiting the movements of surgical staff around the table and necessitating time-consuming recalibrations whenever the patient must be moved.

The Sofie robot improves upon the design of the previous generation of surgical robots by adding force feedback to the surgeon's controls, restoring the use of tactile senses that surgeons learn to use in their training.[1][2][3]

Design

Like several of the previous generations of surgical robot, Sofie is a master-slave design. The two components (master and slave) are completely separated from each other, however, with all communication between the two taking place over data cables arranged in an overhead wiring boom.

The master

The master, or control console, is a workstation from which the surgeon controls the robotic arms and surgical tools. The workstation consists of a monitor on which an image of the work area is shown, plus a number of force-feedback joysticks. The console was designed to be a separate module from the slave, which allows it to be placed at some distance from the surgical table; this means that personnel working at the table will not be hampered in their movement by a large control console in the vicinity of the table. The master console was developed by ir. Ron Hendrix.[2]

The slave

The slave (the actual subject of dr.ir. Van den Bedem's thesis) is a robotic arm frame which can accommodate three independent manipulators (two for surgical tools, one for a camera). The frame for the manipulators is of the type used for pick-and-place robots, allowing the manipulators full freedom of motion in space. This means that the surgeon can also choose the optimal direction of approach for any organ, rather than having to move the patient to suit the machine.[1][2] Of course the manipulators also provide force feedback through the overhead cable boom.

In addition to having a large degree of freedom, the Sofie slave is also quite compact when compared to the generation of surgical robots in current use. Whereas the current generation requires a large robot arm installation next to the surgical table, the slave is small enough to be clamped onto the surgical bed itself. This means that the slave moves with the bed when the surgical table is moved or adjusted and doesn't have to be adjusted separately for the new position of the table in the operating room.[2]

Commercial advantages and exploitation

Another advantage to the design of Sofie is that its construction is cheaper than that of the previous generation of robot. Although there is no notion yet of what a Sofie-like robot would cost in a commercial offering, it is already clear that the design allows for a robot that costs substantially less than the €1,000,000 average of the da Vinci Surgical System.[2]

As of October 2010, dr.ir. Van den Bedem is investigating the possibilities for commercial exploitation of the basic design. The expectation however, is that any robot could only be available in the market by 2016 at the earliest.[2]

gollark: Specifically, 22 bytes for the private key and 21 for the public key on ccecc.py and 25 and 32 on the actual ingame one.
gollark: <@!206233133228490752> Sorry to bother you, but keypairs generated by `ccecc.py` and the ECC library in use in potatOS appear to have different-length private and public keys, which is a problem.EDIT: okay, apparently it's because I've been accidentally using a *different* ECC thing from SMT or something, and it has these parameters instead:```---- Elliptic Curve Arithmetic---- About the Curve Itself-- Field Size: 192 bits-- Field Modulus (p): 65533 * 2^176 + 3-- Equation: x^2 + y^2 = 1 + 108 * x^2 * y^2-- Parameters: Edwards Curve with c = 1, and d = 108-- Curve Order (n): 4 * 1569203598118192102418711808268118358122924911136798015831-- Cofactor (h): 4-- Generator Order (q): 1569203598118192102418711808268118358122924911136798015831---- About the Curve's Security-- Current best attack security: 94.822 bits (Pollard's Rho)-- Rho Security: log2(0.884 * sqrt(q)) = 94.822-- Transfer Security? Yes: p ~= q; k > 20-- Field Discriminant Security? Yes: t = 67602300638727286331433024168; s = 2^2; |D| = 5134296629560551493299993292204775496868940529592107064435 > 2^100-- Rigidity? A little, the parameters are somewhat small.-- XZ/YZ Ladder Security? No: Single coordinate ladders are insecure, so they can't be used.-- Small Subgroup Security? Yes: Secret keys are calculated modulo 4q.-- Invalid Curve Security? Yes: Any point to be multiplied is checked beforehand.-- Invalid Curve Twist Security? No: The curve is not protected against single coordinate ladder attacks, so don't use them.-- Completeness? Yes: The curve is an Edwards Curve with non-square d and square a, so the curve is complete.-- Indistinguishability? No: The curve does not support indistinguishability maps.```so I might just have to ship *two* versions to keep compatibility with old signatures.
gollark: > 2. precompilation to lua bytecode and compressionThis was considered, but the furthest I went was having some programs compressed on disk.
gollark: > 1. multiple layers of sandboxing (a "system" layer that implements a few things, a "features" layer that implements most of potatOS's inter-sandboxing API and some features, a "process manager" layer which has inter-process separation and ways for processes to communicate, and a "BIOS" layer that implements features like PotatoBIOS)Seems impractical, although it probably *could* fix a lot of problems
gollark: There's a list.
  • van den Bedem, Linda Jacoba Martina (22 September 2010), Realization of a demonstrator slave for robotic minimally invasive surgery, Eindhoven: Technische Universiteit Eindhoven, ISBN 978-90-386-2300-9, retrieved 26 April 2010

References
  1. "Beter opereren met nieuwe Nederlandse operatierobot Sofie" (in Dutch). TU/e. 27 September 2010. Archived from the original on 24 July 2011. Retrieved 10 October 2010.
  2. Mischa, Brendel (10 October 2010). "Operatierobot met gevoel" [Feeling surgical robot]. Technisch Weekblad (in Dutch). The Hague, Netherlands: Beta Publishers. p. 4. ISSN 0923-1919. Retrieved 10 October 2010.
  3. "Better Surgery With New Surgical Robot With Force Feedback". Science Daily. 29 September 2010. Retrieved 10 October 2010.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.