Achieving Useful Force Feedback

To achieve realistic feedback, all steps should be executed with approximately 1 kHz frequency [8]. However, in our applications involving complex CAD models, the collision detection rate was highly variable, averaging around 10 Hz - which is 40 times slower than needed (see Table 1). Thus, to achieve realistic interaction rates, we need to determine some reasonable feedback to apply during the idle collision detection updates. Our solution was to use a heuristic to decide if a collision occurred during these idle periods. Since we collect approximate paths anyway (Section 6), a heuristic is an acceptable solution (i.e., undetected collisions are acceptable).

Consider the scenario shown in Figure 4(a). Suppose the last collision detection call returned a collision free result when the robot was in the configuration $c_{lf}$, and let $md$ denote the minimum distance vector from $c_{lf}$ to an obstacle (also returned by the collision detection call). While the system waits for the result of the next collision detection call, the user continues to move the robot. During this time, the PHANTOM tracks the current configuration of the robot $c$. If the projection of $cd$ (the vector from $c_{lf}$ to $c$) on $md$ is greater than $md$, then our heuristic determines that a collision occurred and applies a force opposite to $md$. Now suppose the last collision detection request returned a collision when the robot was in configuration $c_{lc}$ (Figure 4(b)), and let $xd$ denote the vector from our last known free configuration to $c_{lc}$. In this case, we heuristically determine the robot is still in collision if the projection of $cd$ on $xd$ is greater than $xd$, and apply a reaction force opposite to $xd$.

Table 1 summarizes the importance of the heuristic function. It can be seen that almost all collision detection calls are handled by the heuristic function. We also note that the client's (i.e., the haptic system) average wait time for a collision detection request is approximately twice as long as the average collision detection computation time on the server. This delay is caused by the interprocess communication. Our experiments showed that if we had computed the collision detection locally, the wait time would be around 500-700ms.