TRITA-MMK 2012:05 ISSN 1400-1179

ISRN/KTHMMK/R-12/05-SE

Three 6-DOF Haptic Algorithms Compared for Use in a Milling Surgery

Simulator Prototype

Magnus G. Eriksson

Stockholm

2012

Technical Report

Department of Machine Design Royal Institute of Technology, KTH

S-100 44 STOCKHOLM

Technical Report TRITA-MMK 2012:05

ISSN 1400-1179 ISRN/KTHMMK/R-12/05-SE

Three 6-DOF Haptic Algorithms

Compared for Use in a Milling Surgery Simulator Prototype

Mechatronics Lab

Feb 2012

Magnus G. Eriksson

{magnuse@md.kth.se}

Abstract Three different six degrees of freedom haptic algorithms are presented in this paper.

Two of them are developed by the author, and the third is a modified Barbic’ algorithm. Algorithm #1 is a constraint-based proxy-method, Algorithm #2 is a penalty-based method, and Algorithm #3 uses a virtual coupling. They are implemented and compared in a haptic milling surgery simulator. We produce new angles of perspective when having three different solutions to the same problem. All of the algorithms fulfill the real-time requirements and give realistic force- and torque feedback. The choice of algorithm is a question about stability and the requirement of the virtual environment to realistically mimic real world scenarios. The work presented here is an extension to earlier research dealing with three degrees of freedom haptic feedback for milling applications.

Keywords Haptics, surgical simulation, bone milling, virtual reality, force modeling.

1

Three 6-DOF Haptic Algorithms Compared for Use in a Milling Surgery

Simulator Prototype Magnus G. Eriksson

Abstract—Three different six degrees of freedom haptic algorithms are presented in this paper. Two of them are developed by the author, and the third is a modified Barbic’ algorithm. Algorithm #1 is a constraint-based proxy-method, Algorithm #2 is a penalty-based method, and Algorithm #3 uses a virtual coupling. They are implemented and compared in a haptic milling surgery simulator. We produce new angles of perspective when having three different solutions to the same problem. All of the algorithms fulfill the real-time requirements and give realistic force- and torque feedback. The choice of algorithm is a question about stability and the requirement of the virtual environment to realistically mimic real world scenarios. The work presented here is an extension to earlier research dealing with three degrees of freedom haptic feedback for milling applications.

Index Terms—Algorithms, Haptic I/O, Interactive systems, Virtual reality.

1 INTRODUCTION

he research presented here describes a vital step in the design of a prototypical surgical training simulator. The results are intended to be applied in

simulators used to educate and train surgeons for milling operations. Three different six degrees-of-freedom (6-DOF) haptic algorithms are introduced, compared and analyzed. Our methods handle the challenging problem of real-time rendering of volume data changes due to material removal, while fulfilling the given requirements of the kind of haptic applications that we approach.

The material removal algorithm, the force feedback algorithm, and the graphic rendering are developed and described in earlier research based on 3-DOF haptics [1]. The contributions presented in this paper describe an extension to that work by further developing the haptic algorithms to enable 6-DOF haptic feedback instead of 3-DOF, which is crucial for realistic haptic feedback when interacting in a more complex virtual environment, particularly milling applications.

For the time being and in the development of the surgical simulator, the research focus is on finding stable and realistic 6-DOF haptic feedback for milling applications that can run at 1000 Hz in update frequency.

There are a number of research groups working in the area of 6-DOF haptic simulation and in this paper we categorize the three algorithms in relation to others work. The algorithms presented in this paper are characterized as impedance mode, voxel-based collision detection, constraint-based and penalty-based haptic feedback, and direct rendered and virtual coupling based. Our developed methods differ from those of the groups mentioned above, in that we are using a case-specific virtual tool that can be approximated, and the algorithms are optimized for efficient collision detection and milling applications.

Milling a hole in an object in the virtual environment or dragging the virtual tool along the surface of a virtual

object shall generate realistic contact force and torque in the correct directions.

Having three differently developed algorithms provides the benefit of being able to compare them and draw conclusions. The goal of this paper is to discuss the different parts of a 6-DOF haptic algorithm that are of importance for realistic haptic feedback, and to compare the three algorithms and present conclusions for the problem at hand.

The paper is organized as follows. Section 2 describes the problem formulation. Section 3 extensively discusses related work and categorizes it. Sections 4, 5 and 6 present the three algorithms. The concluding section describes implementation and comparison, and presents the conclusions.

2 PROBLEM DESCRIPTION

The milling tool is modeled as a cylinder and a sphere in the virtual environment and directly follows the translation and orientation of the tool tip of the haptic device. The virtual tool is either moving in free space or interacting with a manipulated object in the virtual environment. In our case, this object is built up from medical CT data. In earlier research, a 3-DOF haptic force feedback algorithm was developed for haptic simulation of milling, where modeling of the virtual objects is also presented [1]. Of course, the limitation of that previous research is the haptic feedback; only force can be sent back to the device—no torque. This is a crucial problem when working in a more complex virtual environment (e.g., surgical simulators or milling applications) where multiple point contacts will appear and must be realistically feedback to the haptic device. This occurs when milling a hole and moving the tool down into the hole—having collision detection and force feedback only at the tip of the tool will be very unrealistic and must be

T

2

improved to increase the level of realism towards the kind of haptic simulators treated here.

In this paper, we present three different multiple-point collision detection haptic algorithms. The algorithms perform collision detection of the complete tool when colliding with the object, and generate both haptic force and torque feedback to the user.

In the milling scenario the manipulated object must be updated in real time, this put demands on the haptic algorithm. How to update the surface for stable 6-DOF interaction and collision detection.

In the analysis of the three 6-DOF algorithms we are focusing on the stability issue and haptic update rate for both the milling phase scenario and the non-milling scenario. If the stability demands are fulfilled and also the haptic update rate one can find the user perception satisfied.

3 RELATED WORK In this section we relate the algorithms presented in this paper to known 6-DOF haptic methods. We investigate the collision detection, haptic feedback, and stability of haptic rendering.

3.1 Collision Detection The objects in a virtual environment can be described in two main ways: as polygonal models or as voxel models. The collision detection algorithm used will be different, depending on how the models are described. For 6-DOF haptic rendering, multiple-point object collisions are occurring and must be detected. If the objects are described as polygonal models, the collision detection is performed by using methods in computer graphics [5], [6], [7], [8], [9], [10], [11], [12], [13]. In general, a contact point, a penetration depth and contact normal direction is received from the algorithm [14], [15].

If the objects in the virtual scene are voxel models, collision detection is done by comparing density values of the voxels to determine which ones are colliding.

It is somewhat more common to use a voxel-based description of the virtual objects for 6-DOF haptic rendering. The reason for this could be the pioneering work done by [4], who introduced the Voxmap-Pointshell method that has been commonly used by different research groups since [16], [17], [18], [19], [20], [21], [22], [23].

In our haptic simulator we directly use voxel-based CT data from medical imaging, and hence also use corresponding collision detection with discrete points.

3.2 Haptic Feedback There are two main methods that are used for determine the haptic feedback: penalty-based, and constraint-based methods.

In the penalty-based method, the penetration depth between the two colliding virtual objects is used to calculate reaction forces (and torques), which act to repulse the collision and is proportional to the penetration depth and the stiffness of the materials. Using a penalty-based method when two stiff rigid bodies

collide requires high stiffness constant in the force model; this can be a stability issue for the simulated haptic system. The penalty-based method is the most common haptic feedback technique. The reason for this could be the simplicity of the commonly used spring-damper force model, where the penetration depth can be directly used for force computations.

The constraint-based method is characterized by having virtual objects as analytical constraints and applying an approach to find forces (and torques) that do not violate these constraints. The method makes the manipulated virtual object stay at the surface of the colliding tool object (even though the haptic device is moving into the colliding object); in other words, there is no penetration depth in the model. The classical god-object 3-DOF point haptic interaction algorithm is a typical constraint-based technique [25]. But this method is not straightforward for 6-DOF rigid body haptic interaction [12]. However, [11] has developed a constraint-based method that seems to work for 6-DOF haptic rendering, even though the haptic update rate is limited and unsufficient. [Ref Chan] combine the work done by [11] and [20], but is an unsufficient solution for the milling case. The tool never interpenetrates the object, and hence the material removal is impossible to perform in a good way, which is central for us in our application.

The first two 6-DOF haptic algorithms presented in this paper are self-developed, while the third algorithm is a modification of the Barbic’ algorithm. Algorithm #1 with a line approximation of the tool corresponds to the constraint-based category, since it always keeps the tool object on the surface of the collided object. Algorithm #2 with discrete surface points, which forms the tool, corresponds to a direct penalty based method, where the penetration depth for each colliding point is used to calculate the reaction force. Algorithm #3 is a penalty based method, but uses a virtual coupling that always keeps the tool at a simulated position on the surface of the manipulated object.

3.3 Stability of the Haptic Rendering Stability issues in haptic rendering are related to the situation when two rigid objects are colliding in a virtual world. To be able to transfer a feeling of high stiffness it is important to have a stable haptic simulation.

One absolute requirement for maintaining stability of a haptic simulation when two rigid objects are colliding is high haptic update rates of the force calculations (at least 1000 Hz for the collision of rigid bodies) [27], [28].

The 6-DOF haptic rendering can be split into one of two main categories: direct rendering or virtual coupling. The categories differ in the way the virtual probe of the haptic device is connected to the real position of the haptic device. In the direct rendering, the virtual probe directly follows the haptic device (map-map) and the collision forces are sent directly to the device. This approach provides high transparency of the haptic simulation, but less stability when two stiff materials collide in the virtual environment [3].

To solve the stability problem for direct rendering, a

3

virtual coupling concept was introduced by [29]. This method is used for many 6-DOF haptic algorithms to ensure stability of the haptic simulation. The virtual coupling is a spring-damper force model between the device state and the tool object state in a haptic simulation [24]. The virtual spring-damper system generates forces (and torques) that are sent to the haptic display and felt by the operator.

The main disadvantage with virtual coupling is that the force sent back to operator can be felt as dampened and smoothened, thus reducing transparency. In [18] it is stated that the spring-damper system of the virtual coupling often leads to heuristic optimization of the parameters for a given haptic display.

Both Algorithm #1, and Algorithm #2 presented in this paper use direct rendering. Algorithm #3 uses a virtual coupling.

The three algorithms presented and compared in this paper differ from others in that the algorithms are costimized for milling in real time processing. Most of the other 6-DOF algorithms are not directly suitable for milling. E.g. [20] put out the point shell points in a very time consuming pre-process manner, which is impossible during the real time milling procedure.

However, there are some research groups that have developed 6-DOF algorithms for milling. [A] has made an interesting implementation of the thrust force and torque. But the algorithm is insufficient due to it never takes the real penetration depth, just the number of collision points, which makes it strongly dependent on the resolution of the sampling points on the drill surface. The analyze is also deficient due to the limitation with just 3-DOF device so they are adding the torques to the forces in some vague motivated way. [B] is also using the thrust force, which is of concern but the force summation is not not good for haptic milling – it enables fall through due to that the vector sum of the thrust force can be zero. The force that occurs due to collision between the drill shaft and the bone is never described, and makes the torques of pitch and yaw unclear. [C] seems to be a well working algorithm, but they must show more resulting graphs on force and torque feedback do be able to draw relevant conclusions. Using this algorithm will be problems when milling due to no penetration depth; hence correct material removal is not easily performed. [D] is an impressive algorithm that includes friction and real time update of the distance field, but the minimum update rate for the contact algorithm can be as low as 166 Hz. [E] has also done a modified Barbic algorithm, with well presented face validity tests. It differs from our work in the collision detection; they are taking point by point – while we are using a hierarchical tree. They are directly taking the center points of the surface voxels, while we are using a method where we can separate the resolution of the original data set and the point shell resolution – by doing the latter coarser.

We are approximating the tool to be able to perform milling (modifying the surface) and still fulfill the real time and stability requirements. The approximation of the

tool does not affect the milling procedure, it is just a simplification that is possible to do for this specific task and procedure in the developed simulator.

4 ALGORITHM #1. PROXY-BASED FORCE/TORQUE ALGORITHM: LINE APPROXIMATED TOOL

A proxy-based force and torque algorithm is presented in this section. A proxy is a representation of the tool, which always remains on the surface of the manipulated object when collision occurs. The basic idea of Algorithm #1 is inherited from an earlier developed haptic force algorithm [1]. The advantage of using a proxy-based method is to avoid haptic fall-through problems. This is a problem that occurs when the calculation of the force feedback fails and a zero-force is sent to the haptic device. The user is pushing the tool into the object without having any reaction force to stop it. A proxy method also enables the use of spring models as force algorithms and allows the user to easily drag and push the tool along the surface of the object.

4.1 Discretizing and Approximating the Tool with Vertices along the Centerline

The first step of this algorithm is to discretize the tool with vertices that are used for both collision detection and calculation of the haptic force and torque feedback. The milling tool is modeled as a sphere and cylinder, representing the tip and the shaft of the tool. To reduce the computational load, the number of vertices is minimized by using the same method as in earlier research [1]. The cylinder is approximated with vertices along the centerline, and the sphere is approximated with one vertex at the center point of the sphere (see Fig. 3). The number of vertices along the centerline can easily be changed in our application. However, tests and verification indicate that a total of 51 vertices generate the best performance for fulfilling real-time demands while finding collisions with an arbitrary surface (see section 8.1).

Fig. 3. Discretization of the milling tool (cylinder and sphere).

4.2 Collision Detection The collision detection between the tool and the object is performed by checking the density value for each vertex placed along the centerline of the tool. The density value is compared with the pre-defined iso-value representing the surface of the object.

• If all the density values of the vertices are less than the iso-value, then no collision has occurred. No force or torque feedback is calculated. The position and orientation of the tool is saved to the next time step in the haptic loop.

4

• If any one of the density values is higher than the iso-value, then there is collision between the tool and the object. The torque feedback is calculated as described in Section 4.4 before the signal is sent to the haptic device. There is a force feedback if the vertex for the center point of the sphere has collision. The force is calculated based on the algorithm presented in [1].

4.3 Find Intersection Point If collision between any vertex and the object is detected, an intersection point at the collision position between the centerline of the tool and the surface of the object must be determined (see Fig. 4). The translation difference, d , of the tool tip vertex and orientation difference, α , of the centerline from time step t-1 to t is calculated. There are two main situations when trying to find the intersection point; it was either a collision detected at time step t-1, or it was not.

Fig. 4. The approximated centerline is translated, d , and rotated, α, from t-1 to t. There is no collision at t-1, but collision at t. The intersection point is marked with the cross.

4.3.1 The case of no collision at time step t-1 If there were no collision at t-1 but at t, the intersection point can be determined by using a fraction-based method presented in this section. The first step of this method is to determine which of the vertices are “active vertices”. In the translation/rotation method the basic idea is to go step-by-step, according to a pre-defined step size, from the position at time t-1 to the position at t. This goes on until a collision is found for any of the vertices along the centerline. The vertices that are in collision at step n are called “active vertices”.

After finding the active vertices, the most active vertex is found by comparing the density value fraction of each active vertex. For each active vertex (see Fig. 5), the following equation is used to calculate the density value fraction of that specific point. Index n-1 indicates the step before any collision and index n indicates the step at which collision is detected in the translation/rotation method:

nn

n

valuevaluevalueisovalue

Fraction−

−=

−

−

1

1 _ (1)

The vertex with the minimum fraction value is said to be the most active vertex and, hence, the one that produces the assumed correct intersection point:

minmin )1( FractionFraction ⋅+−⋅= − n1n VertexmostActiveVertexmostActiveonPointIntersecti (2)

Fig. 5. Active vertices and the most active vertex are presented in step n-1 and n at time step t. The intersection point is marked with a cross.

The translation/rotation method of finding the active vertices is presented in conjunction with an example presented in Fig. 6. The basic idea of this method for finding the active vertices is to move the approximated tool centerline step-by-step from t-1 to t until finding a collision of any vertex. It is most efficient to go from t-1 to t rather than from t to t-1 because, in the first case, the search algorithm can stop directly when finding the first collision—which is not obvious for the latter case. If moving from t to t-1 the search algorithm has to continue the whole way until t-1, otherwise a surface part can be missed.

The first step of the procedure presented in Fig. 6 is to verify if the vertex of the tool tip center point is in collision at t. If there is collision of this vertex (as in the figure) the proxy on the surface for that vertex is determined using a previously developed algorithm [1]. The approximated centerline is translated out from the object as an offset to this proxy position. The translation amount and direction will be the base information for the calculated haptic force feedback (see Section 4.4). The new position of the centerline is marked as toffset in the figure.

The search algorithm to find the active points proceeds as follows. The translation part of the algorithm is performed first. The approximated centerline is moved step-by-step dΔ . At every step, the density value of each vertex is calculated. If no collision is found when translated all the way to d (all the steps have been completed), the rotation sequence of the algorithm takes part (as in the example in Fig. 6). Now the approximated centerline is rotated step-by-step αΔ until collision of any vertex/vertices is found. The vertices with collision at step n are called “active vertices”. The positions and values for these vertices from step n-1 and step n are used to calculate the intersection point.

The translation difference, d , and orientation difference, α , of the centerline from time step t-1 to toffset are easily determined. The number of translation steps and number of rotation steps are predefined constants. Hence, the translation step size, dΔ , and rotation step size, αΔ , are calculated as:

5

STEPSNTRANSLATIOOFNUMBER ___ddΔ = (3)

STEPSROTATIONOFNUMBER ___ααΔ = (4)

Fig. 6. Example illustrating the translation/rotation method to find active points. First offset is performed if the center point of the sphere has a collision. After that translation along d , and if no collision was found, step size rotation is completed until a collision is found between any vertex/vertices and the object.

4.3.2 If collision at time step t-1 To find the intersection point at time step t if there already was a collision at t-1, some parts of a previously developed probe-proxy algorithm will be used [1]. That algorithm generates the movement of a proxy on the surface, based on relative position to the “probe of that point”.

Since there was a collision at t-1, the intersection point at t-1 ( 1tPI − ) is known, as is the position of the center point of the sphere ( tPC ). b as indicated in the example presented in Fig. 8 is the vector between these two points. The approximated centerline with vertices is projected along this vector. Step-by-step, the density value of each vertex is calculated and the one with the maximum density value is saved.

The vertex with maximum density value ( maxv ) is the vertex that is located deepest in the object. This vertex is used as “the probe” in the abovementioned algorithm. The intersection point at t-1 corresponds to the proxy position in that algorithm. The algorithm provides the new position of the proxy, which is the same as the intersection point at time step t ( tPI ).

Fig. 8. The intersection point at t-1 ( 1tPI − ) is known, as is the position of the center point of the sphere ( tPC ). A previously developed probe-proxy algorithm moves the proxy from 1tPI − to

tPI (illustrated as squares in the figure) with maxv as a probe. 1tPI − and tPI are marked as crosses.

4.4 The Force and Torque Haptic Feedback Two different forces are calculated if there is a collision between the tool and the object in the virtual environment.

1) If the center point of the sphere ( pointprobe in Fig. 9) has a collision, force is calculated based on a previously developed spring-model algorithm [1]. The vector, e , between the pointprobe and pointproxy (determined by the algorithm) corresponds to the spring length and direction. Hence, the haptic force feedback at the

pointproxy is calculated as: eFproxyPoint ⋅= springk (6)

To model stiff contacts, a high value of the spring constant, kspring, is chosen.

2) The reaction force at the shaft intersection point (see Fig. 8) that produces the torque around the pointproxy is calculated. Once the intersection point is found, a proxy for the centerline of the cylinder ( cylinderproxy ) is placed in the direction from the pointproxy to the intersection point (

tIP ). r in Fig. 9 is defined as the vector between these two points:

pointt proxyIPr −= (7) The centerline of the probe ( cylinderprobe ), which is the

same as the real position of the haptic device tool shaft, is known and the position of the intersection point on

cylinderprobe is calculated as:

pointcylinderderprobeCylin proxyrobepronPointIntersecti +⋅= ˆ (8) The reaction force at the shaft intersection point is

based on a spring model, where the spring length and direction ( g ) is calculated as:

derprobeCylint onPointIntersectiIPg −= (9) The reaction force at the intersection point is:

gFreaction ⋅= springk (10) The torque at the end effector of the haptic device is

calculated as:

reactionFrT ×= (11) The torque, T , and the force, proxyPointF , are sent to the device for realistic 6-DOF haptic feedback.

6

Fig. 9. Two forces are calculated if there is a collision between the tool and the object. proxyPointF produces the haptic force feedback and reactionFrT ×= produces the haptic torque feedback.

4.5 Placing the Proxy Offset for Correct Visualization

In the algorithm described in the sections above, the tool cylinder has been approximated with the centerline of the cylinder. The cylinder represents the shaft of the tool and directly follows the translation and orientation of the end effector of the haptic device. If the visualization of the cylinder is done with this cylinderproxy as centerline of the visualized cylinder, that cylinder would be a radius distance into the object. Hence there must be an offset of the cylinderproxy to give a correct centerline for the visualized cylinder. To establish this offset, a method used in earlier research can be directly applied for the tool tip [1].

The offset of the proxy cylinder, fsetcylinderOfproxy , is calculated as follows and presented in Fig. 10. First, the offset of the intersection point, tOffsetIP , is calculated by using the gradient of this point, u , and the radius of the cylinder. The gradient is defined as the directional gradient at a certain point in the field of density values of the medical object.

radius⋅+= uIPIP ttOffset ˆ (12) The vector for the centerline of the visualized cylinder

is calculated as: tpointOffsetOffsetfsetcylinderOf proxyIPproxy −= (13)

Fig. 10. 2D figure of vectors used to calculate the centerline for the visualized cylinder ( fsetcylinderOfproxy ).

5 ALGORITHM #2. NON PROXY-BASED FORCE/TORQUE ALGORITHM: SURFACE POINTS APPROXIMATED TOOL

In this section, the second developed force and torque algorithm is presented. This one is not proxy-based like the algorithm described above. The basic idea of this algorithm is to put vertices on the enveloped surface of the tool and use these vertices for collision detection and calculation of the force and torque feedback. As in the previous case, the representation of the tool directly follows the movements (translation and rotation) of the end effector of the haptic device. The advantage of this algorithm compared with the previous one is that the feedback is not based on one point; under this algorithm, the haptic feedback will be more stable. Using the method of Algorithm #1 and moving the proxy a radius in the gradient direction sometimes makes the visualization look as though it is vibrating; this is because the direction is based on just the gradient at one point (which is not the case in the second algorithm). The size of the radius to move out also influences the disturbance in visualization.

One problem with Algorithm #2, in terms of visualization, is that when the user pushes the tool against the static surface of the object it will look like the tool is moved into the object, rather than remaining on the surface as in the proxy case. This is because the surface of the object is modeled as static and unresisting.

5.1 Discretizing and Approximating the Tool with Surface Points

As in the previous algorithm, the first step of this algorithm is to discretize the tool with vertices that are used for both collision detection and calculation of the haptic force and torque feedback. The milling tool consists of a sphere and cylinder, representing the tip and the shaft of the tool. The cylinder is approximated with vertices of 2D surface slices and the sphere is approximated with vertices around the envelope surface (see Fig. 11). The number of vertices on the envelope surface can easily be changed in our application. However, test and verification indicates that a number of 24 vertices on the sphere and 20 slices with 8 vertices each

7

for the cylinder give the best performance for fulfilling real-time demands while finding collision with an arbitrary surface (see Section 7.1).

Fig. 11. Discretization of the milling tool (cylinder + sphere).

5.2 Collision detection Collision detection between the tool and the object is performed by checking the density values of the surface vertices and the center point value for each slice and for the center point of the sphere. This is done at the same time, as each vertex is set to the specific position at time step t. The density value is compared with the pre-defined iso-value representing the surface of the object.

• If all the density values of the vertices are less than the iso-value, then no collision has occurred. No force or torque feedback is calculated. The position and orientation of the virtual tool is saved to the next time step in the haptic loop.

• If the density value for the center point of the sphere or the density value for the center point of a certain slice is higher than the iso-value, the haptic force feedback or the reaction force for that slice will be the same as from time step t-1 (see motivation in the next section).

• If the density values of the vertices on the envelope surface are higher than the iso-value, then there is collision between the tool and the object. The torque feedback is calculated as described in Section 5.3 below, before the signal is sent to the haptic device. There is force feedback if any one of the vertices on the envelope surface of the sphere has a collision. The force is calculated based on the same method as the reaction force for each slice when calculating the torque.

5.3 The Force and Torque Haptic Feedback If collision is detected for the sphere, haptic force feedback is calculated. The force is calculated by summarizing forces from all vertices of the sphere that are in collision.

For each vertex with collision, a force is calculated based on a spring-model (see Fig. 12):

verticesofnumberk ispring __

1⋅⋅= aFvertex_i (14)

The force from each vertex is weighted so that the total reaction force will be independent of the vertex resolution of the tool. kspring is the spring constant and ia is the vector from vertex i (being in collision) to the intersection point with the surface in the direction of the center point

of the sphere. The fraction from (1) is used to calculate ia :

( )vertexi-cejcenter_slia ⋅

−

−−=

vertexislicejcenter

isoslicejcenteri vv

vv

_

_1, (15)

where v is density value. The total force on the sphere is determined by

summarizing the forces from each vertex (Fig. 12 is in 2D, but for the sphere the vertices are spread in 3D):

∑=

=

=ni

oivertex_iretotal_sphe FF

, (16)

where n is the number of vertices with a collision.

Fig. 12. 2D description of calculation of force feedback for the sphere or reaction force for each slice that has a collision.

As mentioned in Section 5.2 above, if it is detected at time t that the center point of the sphere is in collision, the haptic force feedback at time step t is set to the same as for step t-1.

1re_ttotal_sphere_ttotal_sphe FF −= (17) Otherwise, if more than half of the sphere is in

collision and the force algorithm is applied, the calculated force may start to decrease and even change direction. This occurs because of the vector summation and indicates a non-realistic situation. This motivation is also used below to set the reaction force for each slice having the center point inside the object to the same reaction force as in time step t-1.

If collision is detected for the cylinder part of the tool, a haptic torque feedback is calculated around the end effector of the device. The torque is calculated by summarizing torques from each slice of the tool that is in collision. The torque from each slice is determined by first calculating a reaction force for that slice and then multiplying (cross product) the force with the distance to the tool tip (center point of the sphere). The reaction force for each slice in collision is calculated by using exactly the same method as derived above for the total force on the sphere (see Fig. 13).

∑=

=

=ni

oivertex_islice_jreaction_ FF (18)

If it is detected that the center point of slice j is in collision, the reaction force for slice j at time step t is set to the same as for step t-1.

1slice_j_treaction_slice_j_treaction_ FF −= (19) For every slice in collision, the reaction force is used to

calculate a torque, slice_jT , around the tip of the tool (center

8

of the sphere).

( )slice_jreaction_jslice_j FrT ×⋅=slicesofnumber __

1 (20)

The torque from each slice is weighted so that the total torque will be independent of the slice resolution of the tool. jr is the vector from the tip of the tool to the center point of slice j. The total torque is calculated by summarizing all the torques from each slice.

∑=

=

=mj

0jslice_jtotal TT

, (21)

where m is the number of slices in collision. The torque, totalT , and the force, retotal_spheF , are sent to the device for

realistic 6-DOF haptic feedback.

Fig. 13. Two viewplanes illustrating the reaction force for every slice in collision and the corresponding torque. The total torque is determined by taking the sum of all these torques for every slice in collision.

6 ALGORITHM #3. MODIFIED BARBIC’ ALGORITHM: USED AS REFERENCE

As a reference the haptic algorithm developed by Barbic is implemented for use. A demo clearly shows the quality of this algorithm for complex 6-DOF interaction [ref]. The original Barbic’ algorithm is modified to be suitable for milling applications, which in real time put demands in the update of point shell points. The main difference compared to the original Barbic algorithm is the creation of the MPO and the collision detection procedure.

6.1 Construction of the objects We are using the notations as Barbic of the two objects in the virtual scene. One of the objects must be a signed distance field, and the other a point shell. The mill (SPO) is created as a pre-computed signed distance field so the penetration depth easily can be found. The SPO, which is an undeformed object, must be the signed distance field – otherwise the signed distance filed must be re-calculated in real time when milling. The shape of the SPO has been created similar to the ones for the other two algorithms in this paper due to verification analysis.

The other object, the milled tooth, is created as a point shell (MPO). It is the same data as for the other two algorithms, and all the center points for each surface voxel generate a point shell that easily can be updated when milling. The resolution of the point shell directly follows the resolution of the data set, which is fine due to

nice graphical representation of the milling procedure. If the resolution of the data set is too fine for the haptic algorithm (too many points that collide and slow down the process), a method for variable resolution of the point shell is developed and implemented.

6.2 Collision detection A self developed fast collsion detection method has been implemented, which is suitable for milling applications. The point shell (MPO) points are stored as a geometrical based hierarchical octree, and around the SPO a bounding box is created. This enables fast box-box collision detection between the MPO octree-boxes and the SPO bounding-box.

This first step of the collision detection generates a range of possible collision points at the lowest hierarchy of the octree. We go through this list of possible collision points, and check the signed distance field value of each point if there is collision or not (minus sign of the signed distance field value gives inside the MPO).

6.3 The Force and Torque Haptic Feedback For the calculation of the force- and torque feedback we are using the same penalty based method as Barbic. In every haptic loop - first the penalty based forces and torques, and its derivates, are calculated for each colliding point. After that the virtual coupling force and torque are calculated and its derivates. The net force and torque (equation 22 and 23) acting on the SPO are set to zero, solving the 6x6 linear system gives delta postion and rotation of the SPO. Moving the SPO these new deltas gives the new postion and rotation of the SPO. Between the new SPO position and the device position a virtual coupling acts and generates the force- and torque feedback felt by the user.

www

xxx

cvccvccvcnet ∆

∂∂

+∂∂

+∆

∂∂

+∂∂

++=FFFFFFF

(22)

www

xxx

cvccvccvcnet ∆

∂∂

+∂∂

+∆

∂∂

+∂∂

++=TTTTTTT

(23)

7 IMPLEMENTATION AND SYSTEM OVERVIEW For our application, the H3DAPI [30] scene graph is used for code implementation and communication with the self-developed ARES 6-DOF haptic device [REF]. The C++ programming language is used for low-level programming in the H3DAPI, while the X3D scripting language is used to build up the scene graph.

The data for the object to be manipulated in the virtual environment is taken from high-resolution DICOM CT datasets. A modified version of the Marching Cubes algorithm is used for 3D rendering of the milling process, and is performed at higher rate than 30 Hz. The haptic rendering loop is updated at 1000 Hz. The simulations have been tested on a Pentium 4, 3.3 GHz dual processor PC with a Quadrow FX1400 graphics card.

9

The ARES 6-DOF haptic device was used for 6-DOF haptic feedback. The workspace of the ARES is sufficient to realistically mimic a real surgery situation. The parallell kinematic structure of the device enables high stiffness and the possibility to send high forces as feedback to the user. Device stiffness properties are clearly very important for a realistic feeling when interacting with stiff materials such as bone.

Apart from manipulating the virtual representation of the object by milling/material removal, the simulator also allows the use of cut-planes, zoom and rotation to explore interesting regions of the data. Sound effects are also implemented to make the simulated milling process seem more realistic.

The developed haptic milling surgery simulator can potentially be used for different applications, such as free-form sculpting or dental training simulations.

8 TEST, COMPARISON AND ANALYSIS OF THE THREE 6-DOF ALGORITHMS

This section is divided into two parts. The first sub-section consists of a test application and the second sub-section presents a comparison and analysis of the three algorithms. The three algorithms are those presented above; Algorithm #1 is the proxy-based line approximated tool, Algorithm #2 is the non proxy-based surface points approximated tool, and Algorithm #3 is the modified Barbic’ algorithm.

8.1 Test Application To determine the number of vertices along the center line in Algorithm #1, the number of slices and vertices in Algorithm #2, and the number of point shell points in Algorithm #3, a test application has been created. The virtual scene consists of the milling tool and a 3D representation of a tooth taken from a CT image with a resolution of 256 x 256 x 176 (see Fig. 14).

Tests indicate that the real-time requirement of a haptic rate at 1000 Hz must be fulfilled by 95% (950 Hz), or else the stability issues of the haptic device make the vibrations unbearable when two stiff materials collide. As such, the analysis is performed by comparing the number of vertices versus the haptic rate.

Fig. 14, which illustrates the test of Algorithm #1, shows that the intersection point (the red sphere) is found at the correct position.

Fig. 14. The virtual scene used for test application. The red sphere indicates the position of the intersection point (Algorithm #1).

The results and analysis of the logged data is presented

below. The material of the tooth for all algorithms is assumed

to have high stiffness (high spring constant) and low friction.

The average values of the haptic rate for Algorithm #1 are:

• 50 vertices: 984 Hz • 100 vertices: 964 Hz • 250 vertices: 884 Hz • 500 vertices: 795 Hz • 1,000 vertices: 544 Hz

Based on this analysis, the number of vertices for Algorithm #1 is chosen as 50, in order to best fulfill the real-time requirements and still have good collision detection accuracy.

For Algorithm #2, the number of slices and vertices is chosen based on tests that first determine the minimum number of vertices on the sphere and on each circle of a slice. The following minimum resolution must be used for correct collision detection and haptic force feedback:

• Number of vertices on the sphere: 24 • Number of vertices on the circle of each slice: 8

Using these numbers, tests were performed for different numbers of slices.

The average values of the haptic rate for Algorithm #2 are:

• 10 slices: 974 Hz • 20 slices: 951 Hz • 30 slices: 922 Hz • 50 slices: 837 Hz • 100 slices: 622 Hz

Based on this analysis, the number of slices for Algorithm #2 is chosen as 20, in order to best fulfill the real-time requirements and still have good collision detection accuracy.

The total number of point shell points for Algorithm #3 is choosen due to a scaling factor in relation to the size of the data set. The resolution of the data set 256x256x176 generates a total number of 72326 point shell points (scaling factor = 1). The data below indicates that this gives too low haptic rate due to too many points to check for collision. Changing the scaling factor in our reduced-resolution method gives a lower number of continously distributed point shell points, and hence a higher haptic rate as presented below.

• Scaling factor = 1, 72326 points: 127 Hz • Scaling factor = 2, 18549 points: 507 Hz • Scaling factor = 3, 8399 points: 987 Hz

From the analysis in this section the following conclusions can be drawn. For Algorithm #1 (the line approximation) the total number of vertices is chosen as 51. For Algorithm #2 (the surface approximation) the total number of vertices is 24 + 8 * 20 = 184. In Algorithm #3 a scaling factor of 3 is chosen, which gives a total number of point shell points as 8399. In the test application with the current settings for algorithm #3 an average number of approximately 15 points shell points are really colliding in each haptic loop.

10

8.2 Comparison and Analysis Studying other relevant research groups [e.g. A-E] how they have performed their tests of haptic algorithms in 6-DOF and milling we have found out what seems to be the most important data and test procedure for accurate analysis. We log data and also use visual feedback to analyse that we do not have any delays and correct material removal, that the haptic update rate is fulfilled, and that we can do comparison of the stability of each algorithm. The virtual scene consists of the same milling tool and a 3D modeled tooth as in the test application above (see Fig. 14). The material of the tooth is assumed to have high stiffness (high spring constant) and low friction. The number of vertices or point shell points for each algorithm is chosen based on the tests done in Section 8.1. The test application also visually indicates that the intersection points are found at correct positions and that the material removal takes place in a correct way.

The comparison procedure for the three algorithms is split up into two parts and performed as follows. In the first part the user moves the virtual tool until the tip collides with the tooth, and then starts to remove material by milling a hole and moving the shaft so that it collides with the edge of the milled hole. In the second part of the procedure, the user is not removing material with the mill – just standing still in the already milled hole and let the cylindrical shaped tool collide with the wall while the user tries to keep the tool as still as possible.

The results and analysis of relevant logged data is presented below. For each figure; first the milling case is presented, and then the non-milling case. The haptic rate, the force- and torque feedback, and the direction of the shaft orientation are presented. In each figure the results from the three algorithms are all combined (Algorithm #1 (red), Algorithm #2 (green), and Algorithm #3 (black)).

Fig. 16 shows the haptic rate results for the three algorithms when milling (top) and not milling (low). The average haptic rates during the tests are: Algorithm #1 976 Hz, Algorithm #2 955 Hz, and Algorithm #3 973 Hz during milling. And Algorithm #1 988 Hz, Algorithm #2 963 Hz, and Algorithm #3 989 Hz when not milling, which are all good indications that all the algorithms fulfill the real-time requirements both during the milling- and the non-milling procedures.

Fig. 16. The logged data of the haptic rate when milling (top), and non-milling (low), for Algorithm #1 (red), Algorithm #2 (green), and Algorithm #3 (black).

Fig. 17 depicts the force feedback during the two case procedures for the three algorithms. Interesting here is the shape of the curves. The shapes illustrate how strong fluctuations and instabilities that are sent to the device and felt by the user. In this sense, Algorithm #1 and Algorithms #3 seem to be the more stable than Algorithm #2 independent of case scenario. Algorithm #2 produces more fluctations and disturbances for both milling and non-milling. For Algorithm #1 and Algorithm #3 almost no instabilities are felt by the user due to the force feedback. While Algorithm #2 generates some instabilities and vibrations that are felt when holding the device and performing the comparison session. The force graphs clearly indicate this problem for Algorithm #2. Vibrations occur and the magnitude is based on how hard the user is holding and gripping the device by hand. In the code for all three algorithms an extra vibration force is generated for milling simulation when pushing the device button, but during the tests this extra feature is turned off – so the vibrations does not depend on it.

11

Fig. 17. The logged data of the force magnitude when milling (top), and non-milling (low) for Algorithm #1 (red), Algorithm #2 (green), and Algorithm #3 (black).

Fig. 18 shows the torque feedback during the two case procedures for the three algorithms. Also here is the shape of the curves interesting information. The figure indicates that the torque feedback is a complex parameter with quite large variations. The results give us the clear information that is also felt and viewed during the test procedure; Algorithm #1 has a very unstable torque feedback. The algorithm is so unstable that it “kicks away” the shaft at a moment (generates an unusual behavior of the torque), which is illustrated with a peak in the torque signal when milling. For Algorithm #2 the fluctuations of the torque seem to follow the same pattern as for the force feedback, but Algorithm #2 is more stable than Algorithm #1. The torque feedback for Algorithm #3 is a bit more unstable than the force feedback, especially for the milling case. For the non-milling case both Algorithm #2 and Algorithm #3 give stable torque feedback, which is also felt by the user. The results depicted in the graphs truly follow the impression the user experience during the test scenarios. Vibrations occur and for Algorithm #2 the magnitude is based on how hard the user is holding and gripping the device by hand. Both the milling case and the non-milling case

illustrate these conclusions.

Fig. 18. The logged data of the torque magnitude when milling (top), and non-milling (low) for Algorithm #1 (red), Algorithm #2 (green), and Algorithm #3 (black).

In Fig. 19 the two 3D graphs show the coordinates for the direction of the shaft orientation of the virtual tool, which can be seen as how much disturbance that is felt by the user for both the milling case (top) and the non-milling case (low). The comparison procedure is exercised so that from one time step to another the direction of the shaft orientation should change as less as possible, especially for the non-milling case. Each point in the graph illustrates the directional vector at a certain time step; the colour range helps to see the movement during 20 seconds. A strong compactness of the points is recommended, due to stability. Long distances between the points illustrate fluctuations, disturbance, and an unpleased behavour. The result showed in Fig. 19 makes the results from Fig. 17 and Fig. 18 even clearer. For the milling case one can see that Algorithm #1 generates a very unstable behavior of the shaft. The direction of the shaft starts at dark blue points and then suddenly jumps away as being more light blue. This “jump” occurs at the same time as the “kick away peak” of the torque, which also was felt by the user. Algorithm #3 is more stable than

12

Algorithm #1 for the milling case, but worse than Algorithm #2. For the non-milling case the result from Algorithm #3 is very good, which also can be predicted from the graph of the torque and what the user experienced. Algorithm #2 has a very stable virtual shaft for both of the test scenarios, and keeps the direction of the shaft orientation in a very compact manner. This can be due to the fact that Algorithm #2 using a direct rendering technique, which means that the virtual shaft directly follows the shaft of the real device that is held by the operator. So, if the user is gripping the shaft hard, and damping the instabilities due to force and torque by his hand, the virtual shaft will not vibrate as much as a virtual coupled virtual shaft.

Fig. 19. The logged data of the direction of the shaft orientation, when milling (top), and non-milling (low), during 20 seconds (20000 sample points), for Algorithm #1, Algorithm #2, and Algorithm #3.

Table 1 presents scoring results from the tests taking into account the haptic rate, the force feedback, the torque feedback, and the direction of the virtual shaft. From the over all results it seems like Algorithm #3 is the most appropriate algorithm to choose for a haptic milling simulator. This is also supported by the impression the user received during the test episode, if not using the human hand as a stabilizer – if so, also Algorithm #2 is suitable due to the user impression.

Algorithm #1 Algorithm #2 Algorithm #3 Haptic rate 1 1 1 Force 1 3 1 Torque 3 1 1 Shaft direction 3 1 2 Total 8 6 5 Tab. 1. Scoring results from the tests taking into account the haptic rate, the force feedback, the torque feedback, and the direction of the virtual shaft for Algorithm #1, Algorithm #2, and Algorithm #3.

9 CONCLUSION AND FUTURE WORK In this paper, three different 6-DOF haptic algorithms

have been presented and compared for the application of a haptic milling surgery simulator. Earlier work has showed a solution for efficient 3-DOF haptic rendering for this specific application. The importance of also introducing 6-DOF haptic feedback is evident for realistic impression when interacting with the virtual scenes of such milling procedures. The main issue with the 6-DOF haptic algorithm is developing methods that can be solved for a haptic update rate of 1000 Hz, an important requirement for applications with interacting stiff objects. In our specific case, the virtual mill is modeled as a cylinder and a sphere; as such it can be discretized and optimized for efficient collision detection and correct calculations of the force and torque feedback when milling. Having three different representations of the same tool and the same environment allow us to compare the results of three different haptic algorithms and draw relevant conclusions.

Algorithm #1 is a constraint-based algorithm that approximates the tool as a line. In Algorithm #2 the tool is approximated with surface points, and using a direct rendering penalty-based method for haptic feedback. Algorithm #3 is a modification of the well known Barbic-algorithm. The resolution of the pointshell is adjustable, and the collision detection is performed in an efficient two-steps procedure.

All of the three algorithms have been implemented in our prototypical haptic milling simulator. The virtual scene consists of the virtual milling tool that interacts with a 3D representation of a tooth taken from a CT image. The tooth is built up with discrete voxel density values used for both graphic and haptic rendering.

The number of vertices or point shell points for the three algorithms has been carefully selected by performing the test application presented in Section 8.1. The demand has been to fulfill the real-time requirements and still have accurate collision detection.

In this work we present an analysis by performing the same test procedure for the three algorithms. The comparison test is split up into two cases, a milling scenario and a non-milling scenario. First, Algorithm #1 is analyzed by moving the virtual tool in a pre-defined trajectory motion in interaction with the 3D tooth. Relevant data are logged for analysis. The procedure is repeated for Algorithm #2, and Algorithm #3 for both the milling and non-milling scenarios. The logged data for

13

the three algorithms are analyzed and from this the following conclusions can be drawn.

All of Algorithm #1, Algorithm #2, and Algorithm #3 fulfill the real-time requirement of a haptic algorithm when two stiff materials are colliding in a virtual environment for both the milling case and the non-milling case. The visual feedback indicates that the graphical representation of the milling process takes place in a correct manner.

The three algorithms mainly differ in how much disturbance and instability is felt by the user; this can also be seen in the graphs of the forces, the torques, and the directions of the shaft orientation. Algorithm #1 has stable force feedback, but very much disturbance related to the torque feedback. Possibly this occurs because just one point is used for calculation of the reaction force and, hence, the torque. From one time step to another, the direction of this force can change a lot when the calculations are just based on one point. Algorithm #2 does not have the same amount of disturbance, most likely because of using several points for calculating the reaction force. The direction and the size of the reaction force can be seen as an average from all these points and thus does not change much from one time step to another. The disturbance that occurs from Algorithm #3 may be caused due to the change in colliding points from one time step to another. At one time step a points shell point has collsion, and at the next time step maybe it does not, and so on. This gives a large variation in the collision force, and hence the collsion torque. Another possible reason for the instabilities could be the large number of parameters to adjust for correct behavior of Algorithm #3. In our modified Barbic algorithm, we are using the center points of the surface voxels as the point shell points due to updating possibities when milling while Barbic is using another maybe more accurate pre-computed method to find these points. This can also be a reason for the stability issues.

One benefit of using Algorithm #1 and Algorithm #3 is that they are methods that always keep the virtual tool on the surface of the manipulated object; as such, haptic fall-through is avoided. In Algorithm #2 the user pushes the tool into the object and also sees this in the graphical rendering, which could be annoying. But as shown in Fig. 19, using Algorithm #2 will not cause so much directional change of the virtual shaft due to direct rendered algorithm and having the human hand as a damping filter.

Future work may include case specific face validity tests, and also comparison tests with milling in real bone material.

ACKNOWLEDGMENT This work was supported in part by a grant from the PIEp-IDRE foundation.

REFERENCES [1] M.G. Eriksson, “Haptic and Visual Simulation of a Material

Cutting Process,” Licentiate Thesis, Dept. of Neuronic

Engineering, KTH, Stockholm, 2006. [2] R.J. Adams and B. Hannaford, “A Two-Port Framework for the

Design of Unconditionally Stable Haptic Interfaces,” Proc. Of the 1998 IEEE/RSJ International Conference on Intelligent Robots and Systems, pp. 1254-1259, 1998.

[3] J.E. Colgate and J.M. Brown, “Factors Affecting the Z-Width of a Haptic Display,” Proc. Of the IEEE 1994 International Conference onRobotics & Automation, pp. 3205-3210, 1994.

[4] W.A. McNeely, K.D. Peterbaugh and J.J. Troy, “Six Degree-of-Freedom Haptic Rendering Using Voxel Sampling,” Proc. ACM Siggraph, pp. 401-408, 1999.

[5] D. Baraff, “Fast Contact Force Computation for Nonpenetrating Rigid Bodies,” Proc. ACM Siggraph, pp. 23-34, 1994.

[6] C. Duriez, F. Dubois, A. Kheddar and C. Andriot, "Realistic Haptic Rendering of Interacting Deformable Objects in Virtual Environments," IEEE Trans. Visualization and Computer Graphics, vol. 12, no. 1, pp. 36-47, Jan/Feb 2006.

[7] A. Gregory, A. Mascarenhas, S. Ehmann, M. Lin and D. Manocha, “Six Degree-of-Freedom Haptic Display of Polygonal Models,” Proc. Of the Conference on Visualization, pp. 139-146, 2000.

[8] Y. Yokokohji, R.L. Hollis and T. Kanade, “What You can See Is What You can Feel,” Proc. Of the IEEE Virtual Reality Annual Symposium 1996, pp. 46-54, 1996.

[9] D.E. Johnson and P. Willemsen, “Six Degree-of-Freedom Haptic Rendering of Complex Polygonal Models,” Proc. Of the IEEE 11th Symposium on Haptic Interfaces for Virtual Environment and Teleoperator Systems (HAPTICS’03), pp. 229-235, 2003.

[10] M. Kolesnikov and M. Zefran, “Energy-Based 6-DOF Penetration Depth Computation for Penalty-Based Haptic Rendering Algorithms,” Proc. Of the 2007 IEEE/RSJ Internationell Conference on Intelligent Robots and Systems, pp. 2120-2125, 2007.

[11] M. Ortega, S. Redon and S. Coquillart, “A Six Degree-of-Freedom God-Object Method for Haptic Display of Rigid Bodies,” Proc. Of the IEEE Virtual Reality Conference (VR’06), pp. 197-204, 2006.

[12] D. Constantinescu, S. Salcudean and E. Croft, "Haptic Rendering of Rigid Contacts Using Impulsive and Penalty Forces," IEEE Trans. on Robotics, vol. 21, no. 3, pp. 309-323, June 2005.

[13] S. Hasegawa and M. Sato, “Real-time Rigid Body Simulation for Haptic Interactions Based on Contact Volume of Polygonal Objects,” Proc. Of EUROGRAPHICS 2004, pp. 529-538, 2004.

[14] Y. Kim, M. Otaduy, M. Lin and D. Manocha, “Six Degree-of-Freedom Haptic Display Using Locilized Contact Computations,” Presence-Teleoperators and Virtual Environments, vol. 12, no. 3, pp. 277-295, June. 2003.

[15] D.E. Johnson, P. Willemsen and E. Cohen, "6-DOF Haptic Rendering Using Spatialized Normal Cone Search," IEEE Trans. Visualization and Computer Graphics, vol. 11, no. 6, pp. 661-670, Nov/Dec 2005.

[16] M. Wan and W.A. McNeely, “Quasi-Static Approximation for 6 Degrees-of-Freedom Haptic Rendering,” Proc. Of the 14th IEEEVisualization Conference (VIS’03), pp. 257-262, 2003.

[17] E. Ruffaldi, D. Morris, F. Barbagli, K. Salisbury and M. Bergamasco, “Voxel-Based Haptic Rendering Using Implicit Sphere Trees,” Proc. Of the 2008 Symposium on Haptic Interfaces for Virtual Environment and Teleoperator Systems, pp. 319-325, 2008.

[18] M. Renz, C. Preusche, M. Pötke, H.P. Kriegel and G. Hirzinger, “Stable Haptic Interaction with Virtual Environments Using an

14

Adapted Voxmap-PointShell Algorithm,” Proc. Of the Eurohaptics Conference 2001, pp. 149-154, 2001.

[19] A. Prior, “On-the-fly Voxelization for 6 Degrees-of-freedom Haptic Virtual Sculpting,” Proc. Of the2006 ACM International Conference on Virtual Reality continuum and its applications, pp. 263-270, 2006.

[20] J. Barbic and D.L. James, "Six-DoF Haptic Rendering of Contact between Geometrically Complex Reduced Deformable Models," IEEE Trans. on Haptics, vol. 1, no. 1, pp. 39-52, Januari-June 2008.

[21] D. Garroway and F. Bogsanyi, “6DOF Haptic Rendering using Geometric Algebra,” Proc. Of IEEE International Workshop 2002 HAVE, pp. 103-107, 2002.

[22] X.J. He and Y.H. Chen, “Bone drilling simulation based on six degree-of-freedom haptic rendering,” Proc. Of Eurohaptics 2006, pp. 147-152, 2006.

[23] M.D. Tsai, M.S. Hsieh and C.H. Tsai, “Bone drilling haptic interaction for orthopedic surgical simulator,” J. Computers in Biology and Medicine, vol. 37, no. 12, pp. 1709-1718, Dec. 2007.

[24] M.A. Otaduy and M.C. Lin, "A Modular Haptic Rendering Algorithm for Stable and Transparent 6-DOF Manipulation," IEEE Trans. on Robotics, vol. 22, no. 4, pp. 751-762, Aug. 2006.

[25] C.B. Zilles and J.K. Salisbury, “A Constraint-based God-object Method for Haptic Display,” Proc. Of the 1995 IEEE/RSJ International Conference on Intelligent Robots and Systems, pp. 146-151, 1995.

[26] B.V. Mirtich, “Impulse-based dynamic simulation of rigid body systems,” PhD dissertation, Dept. of Elect. Eng. Comp. Sci., Univ. California, Berkeley, 1996.

[27] J.E. Colgate and G.G. Schenkel, “Passivity of a class of sampled-data systems: Application to haptic interfaces,” Proc. Of the American Control Conference 1994, pp. 3236-3240, 1994.

[28] F.P. Brooks, Jr., M. Ouh-Young, J.J. Batter and P.J. Kilpatrick, “Project GROPE – Haptic displays for scientific visualization,” Proc. Of Computer Graphics (SIGGRAPH) Aug. 1990, pp. 177-185, 1990.

[29] J.E. Colgate, M.C. Stanley and J.M. Brown, “Issues in the Haptic Display of Tool Use,” Proc. Of the 1995 IEEE/RSJ International Conference on Intelligent Robots and Systems, pp. 140-145, 1995.

[30] H3DAPI, http://www.h3dapi.com, 2010. [31] OpenHaptics Toolkit, http://www.sensable.com/products-

opehaptics-toolkit.htm, 2010. [32] PHANToM Premium 1.5/6DOF,

http://www.sensable.com/haptic-phantom-premium-6dof.htm, 2010.

Magnus G. Eriksson is a PhD candidate at the Department of Machine Design at the Royal Institute of Technology KTH in Stockholm, Sweden. His research interests at the Division of Mechatronics are haptics, multiple-point collision detection, robotics, and 3D graphic rendering. Jan Wikander has been a professor of Mechatronics at KTH, Stockholm, Sweden since 1996. His current research interests are integrated mechatronics design in general, design, and control strategies for mechatronic, robotic and haptic devices. The main fields of application are automotive, automation and medical devices. Twelve PhDs have graduated under his supervision,he holds three patents, and has co-founded two spin-off companies.