Simulator architecture

As the refresh rates of the visual rendering and the haptic rendering are quite different, it seems natural to divide the simulator in two parts. As shown in figure 1, one part manages the force feedback loop, and the other manages the object deformation loop. This latest can be divided into different steps:

• first get the position of the tool, which allows us to
• detect an eventual collision between the tool and the model, and in this case
• compute the deformation of the model;
• from this deformation, deduce the force applied on the tool;
• then, we only need to update the display and to send the force to the extrapolation module, before starting again the loop.

  

Figure: Simulator architecture

In our case, the object is a tetrahedric mesh representing a human liver. We give it a linear elasticity behavior modeled by the finite element method, which is either solved dynamically with the Tensor/Mass algorithm [6], or quasi-statically using pre-computation [5]. Our model includes 1394 vertices, 8347 edges, and 6342 tetrahedra. This size of mesh permits an interactive simulation on a bi-processor Pentium 333 or on a SGI Onyx2. In our setup, as in most simulators, the force feedback devices are handled by another computer, a Pentium 166 in our case, which drives the two Laparoscopic Impulse Engines¹. The communication between the simulation workstation and the force feedback workstation is done via a classical Ethernet connection, using UDP sockets.

Our research group [7] works on all the problems encountered in minimal invasive surgery simulation. We can cite the optimization of the collision detection between the tool and the organ [9], the development of a more realistic behavior of the model (non-linear elasticity, anisotropy), the tuning of the behavior model to bio-mechanical data and realistic visual rendering. This paper focuses on the force feedback problem.