Patent Description:
Robotic systems are commonly used to perform surgical procedures and typically include a robot comprising a robotic arm and a tool coupled to an end of the robotic arm for engaging a surgical site. Often, a tracking system, such as optical localization, is utilized to track positioning of the robot and the surgical site. Kinematic data from the robot may be aggregated with data from the tracking system to update positioning of the robot or for redundant position detection. Tracking systems often track the robot at much higher speeds than the robot can respond. This high speed tracking data is often unsuitable to be utilized directly by the robot, due to both noise and control system stability issues. In many cases, low-pass filtering is used to reduce the noise levels, which improves the signal-to-noise ratio of the commands given to the robot and results in smoother movement and improved performance of the robot arm. In addition, since the tracking system measurement of the tool is part of an outer positioning loop, it is important to not close this outer loop at a higher bandwidth than the robot is capable of responding. The aforementioned low-pass filter also serves this purpose as a control system compensator, effectively lowering the bandwidth of the outer loop to that needed to ensure stable performance. As a result, updating position of the robot based on data from the tracking system has delays due to the filtering of the data.

Although such systems may update the steady state positioning or detect static positioning errors using this technique, such systems are not equipped to determine whether errors or loss of system accuracy has occurred in the system in real time. Instead, such techniques detect errors only after data from the tracking system is filtered or compensated based on control needs of the robot. In other words, any detection of errors in such systems is delayed. Such delay in detecting errors may result in damage to the system or the surgical site, even if such delay is merely hundreds of milliseconds.

According to document <CIT>, telerobotic, telesurgical, and/or surgical robotic devices, systems, and methods employ surgical robotic linkages that may have more degrees of freedom than an associated surgical end effector in space. A processor can calculate a tool motion that includes pivoting of the tool about an aperture site. Linkages movable along a range of configurations for a given end effector position may be driven toward configurations which inhibit collisions. Refined robotic linkages and method for their use are also described.

As such, there is a need in the art for systems and methods for addressing at least the aforementioned problems.

One robotic surgical system is defined in enclosed claim <NUM>. The robotic surgical system comprises a surgical tool, a manipulator comprising a base supporting a plurality of links and being configured to support the surgical tool, and a navigation system comprising a tracker coupled to the surgical tool and a localizer being configured to monitor a state of the tracker. A controller is coupled to the manipulator and the navigation system and is configured to acquire, from the manipulator, raw, i.e., unfiltered kinematic measurement data relating to a state of the surgical tool relative to the base. The controller acquires known relationship data relating to the state of the tracker relative to the surgical tool. The controller acquires, from the navigation system, raw, i.e., unfiltered navigation data relating to the state of the tracker relative to the localizer. The raw, i.e., unfiltered kinematic measurement data, the known relationship data and the raw, i.e., unfiltered navigation data are combined to determine a raw, i.e., unfiltered relationship between the base and the localizer. The raw, i.e., unfiltered relationship is filtered according to a first filter length to produce a first filtered relationship between the base and the localizer for controlling the manipulator. The controller filters the raw, i.e., unfiltered relationship according to a second filter length being shorter than the first filter length to produce a second filtered relationship between the base and the localizer. The second filtered relationship is utilized, alone or by comparing the first filtered relationship to the second filtered relationship, to determine whether an error has occurred relating to at least one of the manipulator and the localizer.

One method of operating a robotic surgical system is defined in enclosed claim <NUM>. The robotic surgical system comprises a surgical tool, a manipulator comprising a base supporting a plurality of links and being configured to support the surgical tool, a navigation system comprising a tracker coupled to the surgical tool and a localizer being configured to monitor a state of the tracker. A controller is coupled to the manipulator and the navigation system. The method comprises the controller performing the steps of acquiring, from the manipulator, raw, i.e., unfiltered kinematic measurement data relating to a state of the surgical tool relative to the base, acquiring known relationship data relating to the state of the tracker relative to the surgical tool, and acquiring, from the navigation system, raw, i.e., unfiltered navigation data relating to the state of the tracker relative to the localizer. The raw, i.e., unfiltered kinematic measurement data, the known relationship data and the raw, i.e., unfiltered navigation data are combined to determine a raw, i.e., unfiltered relationship between the base and the localizer. The raw, i.e., unfiltered relationship is filtered according to a first filter length to produce a first filtered relationship between the base and the localizer for controlling the manipulator. The controller filters the raw, i.e., unfiltered relationship according to a second filter length being shorter than the first filter length to produce a second filtered relationship between the base and the localizer. The second filtered relationship is utilized, alone or by comparing the first filtered relationship to the second filtered relationship, to determine whether an error has occurred relating to at least one of the manipulator and the localizer.

Another method of operating a robotic surgical system is exemplarily described. The robotic system comprises a surgical tool, a manipulator comprising a base supporting a plurality of links and being configured to support the surgical tool, and a navigation system comprising a tracker coupled to the manipulator and a localizer being configured to monitor a state of the tracker. A controller is coupled to the manipulator and the navigation system. The method comprises the controller performing the step of determining a raw, i.e., unfiltered relationship between one or more components of the manipulator and one or more components of the navigation system using raw, i.e., unfiltered kinematic measurement data from the manipulator and, optionally, raw, i.e., unfiltered navigation data from the navigation system. The controller filters the raw, i.e., unfiltered relationship to produce a filtered relationship between one or more components of the manipulator and one or more components of the navigation system for controlling the manipulator. The controller utilizes the raw, i.e., unfiltered relationship to determine whether an error has occurred relating to at least one of the manipulator and the navigation system.

The system and methods advantageously exploit unfiltered raw or lightly filtered raw data relating to the relationship between the base and the localizer to detect system errors or loss in system accuracy. Since the raw, i.e., unfiltered relationship is instantaneous, such error or loss in accuracy can be determined in real time. Even when lightly filtered to produce the second filtered relationship, the lightly filtered raw data can be utilized by the controller to detect error or loss in accuracy near instantaneously and faster than if the first filtered relationship, which is used for controlling the manipulator, alone is utilized. By filtering the raw, i.e., unfiltered relationship according to the second filter length being shorter than the first filter length, the system and method detect the error faster than the amount of filtering needed to control the manipulator. In other words, the system and methods detect error or loss in system accuracy by circumventing the filtering needed for controlling the manipulator. The system and method may exhibit advantages other than those described herein.

Referring to the Figures, wherein like numerals indicate like or corresponding parts throughout the several views, a robotic surgical system <NUM> (hereinafter "system") and method for operating the system <NUM> and detecting errors or loss in accuracy of the system <NUM> are shown throughout.

As shown in <FIG>, the system <NUM> is a robotic surgical system for treating an anatomy of a patient <NUM>, such as bone or soft tissue. In <FIG>, the patient <NUM> is undergoing a surgical procedure. The anatomy in <FIG> includes a femur (F) and a tibia (T) of the patient <NUM>. The surgical procedure may involve tissue removal or treatment. Treatment may include cutting, coagulating, lesioning the tissue, treatment in place of tissue, or the like. In some embodiments, the surgical procedure involves partial or total knee or hip replacement surgery. In one embodiment, the system <NUM> is designed to cut away material to be replaced by surgical implants such as hip and knee implants, including unicompartmental, bicompartmental, multicompartmental, or total knee implants. Some of these types of implants are shown in <CIT>, entitled, "Prosthetic Implant and Method of Implantation". Those skilled in the art appreciate that the system <NUM> and method disclosed herein may be used to perform other procedures, surgical or non-surgical, or may be used in industrial applications or other applications where robotic systems are utilized.

The system <NUM> includes a manipulator <NUM>. The manipulator <NUM> has a base <NUM> and plurality of links <NUM>. A manipulator cart <NUM> supports the manipulator <NUM> such that the manipulator <NUM> is fixed to the manipulator cart <NUM>. The links <NUM> collectively form one or more arms of the manipulator <NUM>. The manipulator <NUM> may have a serial arm configuration (as shown in <FIG>) or a parallel arm configuration. In other embodiments, more than one manipulator <NUM> may be utilized in a multiple arm configuration. The manipulator <NUM> comprises a plurality of joints (J) and a plurality of joint encoders <NUM> located at the joints (J) for determining position data of the joints (J). For simplicity, only one joint encoder <NUM> is illustrated in <FIG>, although it is to be appreciated that the other joint encoders <NUM> may be similarly illustrated. The manipulator <NUM> according to one embodiment has six joints (J1-J6) implementing at least six-degrees of freedom (DOF) for the manipulator <NUM>. However, the manipulator <NUM> may have any number of degrees of freedom and may have any suitable number of joints (J) and redundant joints (J).

The base <NUM> of the manipulator <NUM> is generally a portion of the manipulator <NUM> that is stationary during usage thereby providing a fixed reference coordinate system (i.e., a virtual zero pose) for other components of the manipulator <NUM> or the system <NUM> in general. Generally, the origin of the manipulator coordinate system MNPL is defined at the fixed reference of the base <NUM>. The base <NUM> may be defined with respect to any suitable portion of the manipulator <NUM>, such as one or more of the links <NUM>. Alternatively, or additionally, the base <NUM> may be defined with respect to the manipulator cart <NUM>, such as where the manipulator <NUM> is physically attached to the cart <NUM>. In a preferred embodiment, the base <NUM> is defined at an intersection of the axes of joints J1 and J2 (see <FIG>). Thus, although joints J1 and J2 are moving components in reality, the intersection of the axes of joints J1 and J2 is nevertheless a virtual fixed reference point which does not move in the manipulator coordinate system MNPL.

A surgical tool <NUM> (hereinafter "tool") couples to the manipulator <NUM> and is movable relative to the base <NUM> to interact with the anatomy in certain modes. The tool <NUM> is or forms part of an end effector <NUM>. The tool <NUM> may be grasped by the operator in certain modes. One exemplary arrangement of the manipulator <NUM> and the tool <NUM> is described in <CIT>, entitled, "Surgical Manipulator Capable of Controlling a Surgical Instrument in Multiple Modes". The manipulator <NUM> and the tool <NUM> may be arranged in alternative configurations. The tool <NUM> can be like that shown in <CIT>, entitled, "End Effector of a Surgical Robotic Manipulator". The tool <NUM> includes an energy applicator <NUM> designed to contact the tissue of the patient <NUM> at the surgical site. The energy applicator <NUM> may be a drill, a saw blade, a bur, an ultrasonic vibrating tip, or the like. The manipulator <NUM> and/or manipulator cart <NUM> house a manipulator computer <NUM>, or other type of control unit. The tool <NUM> comprises a TCP, which in one embodiment, is a predetermined reference point defined at the energy applicator <NUM>. The TCP has known position in its own coordinate system. In one embodiment, the TCP is assumed to be located at the center of a spherical feature of the tool <NUM> such that only one point is tracked. The TCP may relate to a bur having a specified diameter.

Referring to <FIG>, the system <NUM> includes a controller <NUM>. The controller <NUM> includes software and/or hardware for controlling the manipulator <NUM>. The controller <NUM> directs the motion of the manipulator <NUM> and controls a state (position and/or orientation) of the tool <NUM> with respect to a coordinate system. In one embodiment, the coordinate system is a manipulator coordinate system MNPL, as shown in <FIG>. The manipulator coordinate system MNPL has an origin located at any suitable pose with respect to the manipulator <NUM>. Axes of the manipulator coordinate system MNPL may be arbitrarily chosen as well. Generally, the origin of the manipulator coordinate system MNPL is defined at the fixed reference point of the base <NUM>. One example of the manipulator coordinate system MNPL is described in <CIT>, entitled, "Surgical Manipulator Capable of Controlling a Surgical Instrument in Multiple Modes".

As shown in <FIG>, the system <NUM> further includes a navigation system <NUM>. One example of the navigation system <NUM> is described in <CIT>, entitled, "Navigation System Including Optical and Non-Optical Sensors". The navigation system <NUM> is configured to track movement of various objects. Such objects include, for example, the tool <NUM> and the anatomy, e.g., femur F and tibia T. The navigation system <NUM> tracks these objects to gather state information of each object with respect to a (navigation) localizer coordinate system LCLZ. Coordinates in the localizer coordinate system LCLZ may be transformed to the manipulator coordinate system MNPL, and/or vice-versa, using transformation techniques described herein.

The navigation system <NUM> includes a cart assembly <NUM> that houses a navigation computer <NUM>, and/or other types of control units. A navigation interface is in operative communication with the navigation computer <NUM>. The navigation interface includes one or more displays <NUM>. The navigation system <NUM> is capable of displaying a graphical representation of the relative states of the tracked objects to the operator using the one or more displays <NUM>. First and second input devices <NUM>, <NUM> may be used to input information into the navigation computer <NUM> or otherwise to select/control certain aspects of the navigation computer <NUM>. As shown in <FIG>, such input devices <NUM>, <NUM> include interactive touchscreen displays. However, the input devices <NUM>, <NUM> may include any one or more of a keyboard, a mouse, a microphone (voice-activation), gesture control devices, and the like. The controller <NUM> may be implemented on any suitable device or devices in the system <NUM>, including, but not limited to, the manipulator computer <NUM>, the navigation computer <NUM>, and any combination thereof.

The navigation system <NUM> also includes a navigation localizer <NUM> (hereinafter "localizer") that communicates with the navigation computer <NUM>. In one embodiment, the localizer <NUM> is an optical localizer and includes a camera unit <NUM>. The camera unit <NUM> has an outer casing <NUM> that houses one or more optical sensors <NUM>.

The navigation system <NUM> includes one or more trackers. In one embodiment, the trackers include a pointer tracker PT, a tool tracker <NUM>, a first patient tracker <NUM>, and a second patient tracker <NUM>. In the illustrated embodiment of <FIG>, the tool tracker <NUM> is firmly attached to the tool <NUM>, the first patient tracker <NUM> is firmly affixed to the femur F of the patient <NUM>, and the second patient tracker <NUM> is firmly affixed to the tibia T of the patient <NUM>. In this embodiment, the patient trackers <NUM>, <NUM> are firmly affixed to sections of bone. The pointer tracker PT is firmly affixed to a pointer P used for registering the anatomy to the localizer coordinate system LCLZ. Those skilled in the art appreciate that the trackers <NUM>, <NUM>, <NUM>, PT may be fixed to their respective components in any suitable manner. Additionally, the navigation system <NUM> may include trackers for other components of the system, including, but not limited to, the base <NUM>, the cart <NUM>, and any one or more links <NUM> of the manipulator <NUM>.

Any one or more of the trackers may include active markers <NUM>. The active markers <NUM> may include light emitting diodes (LEDs). Alternatively, the trackers <NUM>, <NUM>, <NUM> may have passive markers, such as reflectors, which reflect light emitted from the camera unit <NUM>. Other suitable markers not specifically described herein may be utilized.

The localizer <NUM> tracks the trackers <NUM>, <NUM>, <NUM> to determine a state of each of the trackers <NUM>, <NUM>, <NUM>, which correspond respectively to the state of the tool <NUM>, the femur (F) and the tibia (T). The localizer <NUM> provides the state of the trackers <NUM>, <NUM>, <NUM> to the navigation computer <NUM>. In one embodiment, the navigation computer <NUM> determines and communicates the state the trackers <NUM>, <NUM>, <NUM> to the manipulator computer <NUM>. As used herein, the state of an object includes, but is not limited to, data that defines the position and/or orientation of the tracked object or equivalents/derivatives of the position and/or orientation. For example, the state may be a pose of the object, and may include linear data, and/or angular velocity data, and the like.

Although one embodiment of the navigation system <NUM> is shown in the Figures, the navigation system <NUM> may have any other suitable configuration for tracking the tool <NUM> and the patient <NUM>. In one embodiment, the navigation system <NUM> and/or localizer <NUM> are ultrasound-based. For example, the navigation system <NUM> may comprise an ultrasound imaging device coupled to the navigation computer <NUM>. The ultrasound imaging device images any of the aforementioned objects, e.g., the tool <NUM> and the patient <NUM> and generates state signals to the controller <NUM> based on the ultrasound images. The ultrasound images may be <NUM>-D, <NUM>-D, or a combination of both. The navigation computer <NUM> may process the images in near real-time to determine states of the objects. The ultrasound imaging device may have any suitable configuration and may be different than the camera unit <NUM> as shown in <FIG>.

In another embodiment, the navigation system <NUM> and/or localizer <NUM> are radio frequency (RF)-based. For example, the navigation system <NUM> may comprise an RF transceiver in communication with the navigation computer <NUM>. Any of the tool <NUM> and the patient <NUM> may comprise RF emitters or transponders attached thereto. The RF emitters or transponders may be passive or actively energized. The RF transceiver transmits an RF tracking signal and generates state signals to the controller <NUM> based on RF signals received from the RF emitters. The navigation computer <NUM> and/or the controller <NUM> may analyze the received RF signals to associate relative states thereto. The RF signals may be of any suitable frequency. The RF transceiver may be positioned at any suitable location to effectively track the objects using RF signals. Furthermore, the RF emitters or transponders may have any suitable structural configuration that may be much different than the trackers <NUM>, <NUM>, <NUM> as shown in <FIG>.

In yet another embodiment, the navigation system <NUM> and/or localizer <NUM> are electromagnetically based. For example, the navigation system <NUM> may comprise an EM transceiver coupled to the navigation computer <NUM>. The tool <NUM> and the patient <NUM> may comprise EM components attached thereto, such as any suitable magnetic tracker, electromagnetic tracker, inductive tracker, or the like. The trackers may be passive or actively energized. The EM transceiver generates an EM field and generates state signals to the controller <NUM> based upon EM signals received from the trackers. The navigation computer <NUM> and/or the controller <NUM> may analyze the received EM signals to associate relative states thereto. Again, such navigation system <NUM> embodiments may have structural configurations that are different than the navigation system <NUM> configuration as shown throughout the Figures.

Those skilled in the art appreciate that the navigation system <NUM> and/or localizer <NUM> may have any other suitable components or structure not specifically recited herein. Furthermore, any of the techniques, methods, and/or components described above with respect to the camera-based navigation system <NUM> shown throughout the Figures may be implemented or provided for any of the other embodiments of the navigation system <NUM> described herein. For example, the navigation system <NUM> may utilize solely inertial tracking or any combination of tracking techniques.

As shown in <FIG>, the controller <NUM> further includes software modules. The software modules may be part of a computer program or programs that operate on the manipulator computer <NUM>, navigation computer <NUM>, or a combination thereof, to process data to assist with control of the system <NUM>. The software modules include instructions stored in memory on the manipulator computer <NUM>, navigation computer <NUM>, or a combination thereof, to be executed by one or more processors of the computers <NUM>, <NUM>. Additionally, software modules for prompting and/or communicating with the operator may form part of the program or programs and may include instructions stored in memory on the manipulator computer <NUM>, navigation computer <NUM>, or a combination thereof. The operator interacts with the first and second input devices <NUM>, <NUM> and the one or more displays <NUM> to communicate with the software modules. The user interface software may run on a separate device from the manipulator computer <NUM> and navigation computer <NUM>.

The controller <NUM> includes a manipulator controller <NUM> for processing data to direct motion of the manipulator <NUM>. In one embodiment, as shown in <FIG>, the manipulator controller <NUM> is implemented on the manipulator computer <NUM>. The manipulator controller <NUM> may receive and process data from a single source or multiple sources. The controller <NUM> further includes a navigation controller <NUM> for communicating the state data relating to the femur F, tibia T, and tool <NUM> to the manipulator controller <NUM>. The manipulator controller <NUM> receives and processes the state data provided by the navigation controller <NUM> to direct movement of the manipulator <NUM>. In one embodiment, as shown in <FIG>, the navigation controller <NUM> is implemented on the navigation computer <NUM>. The manipulator controller <NUM> or navigation controller <NUM> may also communicate states of the patient <NUM> and tool <NUM> to the operator by displaying an image of the femur F and/or tibia T and the tool <NUM> on the one or more displays <NUM>. The manipulator computer <NUM> or navigation computer <NUM> may also command display of instructions or request information using the display <NUM> to interact with the operator and for directing the manipulator <NUM>.

As shown in <FIG>, the controller <NUM> includes a boundary generator <NUM>. The boundary generator <NUM> is a software module that may be implemented on the manipulator controller <NUM>, as shown in <FIG>. Alternatively, the boundary generator <NUM> may be implemented on other components, such as the navigation controller <NUM>. The boundary generator <NUM> generates virtual boundaries <NUM> for constraining the tool <NUM>, as shown in <FIG>. Such virtual boundaries <NUM> may also be referred to as virtual meshes, virtual constraints, or the like. The virtual boundaries <NUM> may be defined with respect to a <NUM>-D bone model registered to the one or more patient trackers <NUM>, <NUM> such that the virtual boundaries <NUM> are fixed relative to the bone model. The state of the tool <NUM> is tracked relative to the virtual boundaries <NUM>. In one embodiment, the state of the TCP of the tool <NUM> is measured relative to the virtual boundaries <NUM> for purposes of determining when and where haptic feedback force is applied to the manipulator <NUM>, or more specifically, the tool <NUM>.

A tool path generator <NUM> is another software module run by the controller <NUM>, and more specifically, the manipulator controller <NUM>. The tool path generator <NUM> generates a path for the tool <NUM> to traverse, such as for removing sections of the anatomy to receive an implant. One exemplary system and method for generating the tool path is explained in <CIT>, entitled, "Surgical Manipulator Capable of Controlling a Surgical Instrument in Multiple Modes". In some embodiments, the virtual boundaries <NUM> and/or tool paths may be generated offline rather than on the manipulator computer <NUM> or navigation computer <NUM>. Thereafter, the virtual boundaries <NUM> and/or tool paths may be utilized at runtime by the manipulator controller <NUM>. Yet another software module in <FIG> is an error detection module <NUM>, the details of which are described below.

As described above, the manipulator <NUM> and the navigation system <NUM> operate with respect to different coordinate systems, i.e., the manipulator coordinate system MNPL and the localizer coordinate system LCLZ, respectively. As such, in some embodiments, the controller <NUM> fuses data from the manipulator <NUM> and the navigation system <NUM> for controlling the manipulator <NUM> using the navigation system <NUM>. To do so, the controller <NUM> utilizes data fusion techniques as described herein.

In general, the controller <NUM> acquires raw data of various transforms between components of the system <NUM>. The controller <NUM> combines and filters this raw data, and creates a filtered relationship between the base <NUM> of the manipulator <NUM> and the localizer <NUM>, and ultimately produces a filtered relationship between the base <NUM> and one or more of the patient trackers <NUM>, <NUM> based on the filtered data to control the manipulator <NUM>.

As used herein, the term "raw" is used to describe data representing an actual or true state of one or more components of the system <NUM> (e.g., base <NUM>, tool <NUM>, localizer <NUM>, trackers <NUM>, <NUM>, <NUM>) relative to at least another component(s) of the system <NUM>, whereby the raw data is obtained instantaneously (in practically real time) from its respective source such that the raw data is unfiltered. The raw data is an unaltered or minimally processed measurement.

As used herein, the term "filtered" is used to describe raw data that is filtered according to a filter length and that represents a filtered state of one or more components of the system <NUM> relative to at least another component(s) of the system <NUM>. The filtered data is delayed with respect to the instantaneously obtained raw data due to application of the filter length in the filter. As will be described below, the raw data is ultimately filtered to control the manipulator <NUM>. Additional details related to filtering are described below.

Each tracked component has its own coordinate system separate from the manipulator coordinate system MNPL and localizer coordinate system LCLZ. The state of each component is defined by its own coordinate system with respect to MNPL and/or LCLZ. Each of these coordinate systems has an origin that may be identified as a point relative to the origin of the manipulator coordinate system MNPL and/or the localizer coordinate system LCLZ. A vector defines the position of the origin of each of these coordinate systems relative to another one of the other coordinate systems. The location of a coordinate system is thus understood to be the location of the origin of the coordinate system. Each of these coordinate systems also has an orientation that, more often than not, is different from the coordinate systems of the other components. The orientation of a coordinate system may be considered as the relationship of the X, Y and Z-axes of the coordinate system relative to the corresponding axes of another coordinate system, such as MNPL and/or LCLZ.

The state of one component of the system <NUM> relative to the state of another component is represented as a transform (T). In one embodiment, each transform (T) is specified as a transformation matrix, such as a <NUM> x <NUM> homogenous transformation matrix. The transformation matrix, for example, includes three unit vectors representing orientation, specifying the axes (X, Y, Z) from the first coordinate system expressed in coordinates of the second coordinate system (forming a rotation matrix), and one vector (position vector) representing position using the origin from the first coordinate system expressed in coordinates of the second coordinate system.

The transform (T), when calculated, gives the state (position and/or orientation) of the component from the first coordinate system given with respect to a second coordinate system. The controller <NUM> calculates/obtains and combines a plurality of transforms (T1-T5) from the various components of the system <NUM> to control the manipulator <NUM>, as described below.

As shown in <FIG>, the transforms include a first transform (T1) between the base <NUM> and the tool <NUM>, a second transform (T2) between the tool <NUM> and the tool tracker <NUM>, a third transform (T3) between the localizer <NUM> and the tool tracker <NUM>, and a fourth transform (T4) between the localizer <NUM> and one or more of the patient trackers <NUM>, <NUM>. One exemplary system and method for obtaining the transforms of the various components of the system is explained in <CIT>, entitled, "Surgical Manipulator Capable of Controlling a Surgical Instrument in Multiple Modes".

The output (e.g., values) of the transforms (T1)-(T4) are regarded as raw data when obtained instantaneously (in near real time) and when unfiltered. Such raw data may be understood as being derived from an instantaneous transform, i.e., an instantaneous determination of the state of one component of the system <NUM> relative to the state of another component. On the other hand, the output values of such transforms are regarded as filtered data when the values are filtered, such as for reasons described below.

To implement the aforementioned data fusion technique, the controller <NUM> acquires raw kinematic measurement data relating to a state of the tool <NUM>. The state of the tool <NUM> may be determined relative to the manipulator coordinate system MNPL. In some instances, the raw kinematic measurement data may relate to the state of the tool <NUM> relative to the base <NUM>. The state of the tool <NUM> is measured relative to the base <NUM> because the state of the base <NUM> is assumed to be stationary and the tool <NUM> moves relative to the base <NUM>. The raw kinematic measurement data may be obtained from the manipulator controller <NUM>. Specifically, as shown in <FIG>, the controller <NUM> is configured to acquire the raw kinematic measurement data by acquiring one or more values of a first instantaneous transform (T1) between a state of the base <NUM> and the state of the tool <NUM>. Here, the raw kinematic measurement data may be obtained from kinematic data of the manipulator <NUM>. In particular, the controller <NUM> may acquire one or more values of the first instantaneous transform (T1) by applying a forward kinematic calculation to values acquired from the joint encoders <NUM>. Thus, the state of the tool <NUM> can be determined relative to the manipulator coordinate system MNPL without intervention from the navigation system <NUM>. In other words, the first instantaneous transform (T1) may be obtained irrespective of any measurements from the navigation system <NUM>.

In <FIG>, the first transform (T1) is indicated by an arrow having an origin at the base <NUM> and extending to and having an arrowhead pointing to the tool <NUM>. In one exemplary convention used throughout <FIG>, the arrowhead points to the component having its state derived or specified relative to the component at the origin. Those skilled in the art appreciate that the first transform (T1) may be inverted such that the raw kinematic measurement data represents the state of the base <NUM> relative to the state of the tool <NUM>. Additionally, the first transform (T1) may be determined using any suitable reference frames (coordinate systems) on the base <NUM> and the tool <NUM>.

The controller <NUM> may further acquire known relationship data relating to the state of the tool tracker <NUM> relative to the tool <NUM>. In general, the known relationship data may be derived from any known relationship between the tool tracker <NUM> and the tool <NUM>. In other words, the tool tracker <NUM> and the tool <NUM> have a relationship that is known or calculatable using any suitable method. The tool tracker <NUM> and the tool <NUM> may be fixed or moving relative to each other. For example, the tool tracker <NUM> may be attached directly to the tool <NUM>, as shown in <FIG>. Alternatively, the tool tracker <NUM> may be attached to one of the links <NUM>, which move relative to the tool <NUM>. In general, the tool tracker <NUM> and the tool <NUM> are tracked by different techniques, i.e., by navigation data and kinematic measurement data, respectively. The known relationship data assists to bridge the kinematic measurement data and the navigation data by aligning the tool tracker <NUM> and the tool <NUM> to a common coordinate system.

The known relationship data may be fixed (constant or static) or variable. In embodiments where the known relationship data is fixed, the known relationship data may be derived from calibration information relating to the tool tracker <NUM> and/or the tool <NUM>. For example, the calibration information may be obtained at a manufacturing/assembly stage, e.g., using coordinate measuring machine (CMM) measurements, etc. The known relationship data may be obtained using any suitable method, such as reading the known relationship data from a computer-readable medium, an RFID tag, a barcode scanner, or the like. The known relationship data may be imported into system <NUM> at any suitable moment such that the known relationship data is readily accessible by the controller <NUM>. In embodiments where the known relationship data is variable, the known relationship data may be measured or computed using any ancillary measurement system or components, such as additional sensors, trackers, encoders, or the like. The known relationship data may also be acquired after mounting the tool tracker <NUM> to the tool <NUM> in preparation for a procedure by using any suitable technique or calibration method.

Whether static or variable, the known relationship data may or may not be regarded as raw data, as described herein, depending on the desired technique for obtaining the same. In one embodiment, the controller <NUM> may acquire the known relationship data by acquiring one or more values of a second instantaneous transform (T2) between the state of the tool <NUM> and the state of the tool tracker <NUM>. The second transform (T2) may be determined with respect to any suitable coordinate system or frame on the tool tracker <NUM> and the tool <NUM>.

In other embodiments, the controller <NUM> may determine the second transform (T2) using any one or more of the kinematic measurement data from the manipulator <NUM> and navigation data from the navigation system <NUM> such that known relationship data is not utilized. For example, the second transform (T2) may be calculated using one or more of raw kinematic measurement data relating to the state of the tool <NUM> relative to the base <NUM> from the manipulator <NUM> and raw navigation data relating to the state of the tracker <NUM> relative to the localizer <NUM> from the navigation system <NUM>. For example, the tool <NUM> may be rotated about its wrist to create a circular or spherical fit of the tool <NUM> relative to the tool tracker <NUM>.

The controller <NUM> is further configured to acquire, from the navigation system <NUM>, raw navigation data relating to the state of the tool tracker <NUM> relative to the localizer <NUM>. The controller <NUM> may do so by acquiring one or more values of a third instantaneous transform (T3) between the tool tracker <NUM> and the localizer <NUM>. The third transform (T3) can be calculated using navigation data alone, irrespective of kinematic measurement data from the manipulator <NUM>. Here, the state of the localizer <NUM> is assumed stationary and the tool tracker <NUM> is assumed to move during operation. Thus, the tool tracker <NUM> is tracked relative to the localizer <NUM>. The third transform (T3) is shown in <FIG> using an arrow originating at the localizer <NUM> and pointing towards the tool tracker <NUM>. The direction of transform (T3) is opposite to transforms (T1) and (T2). Accordingly, transform (T3) should be inverted prior to combining (T3) with transforms (T1) and (T2). Consistent with the convention shown in <FIG>, transform (T3) is hereinafter referenced as (T3') to indicate the inverted nature of this transform relative to the others in <FIG>.

The fourth transform (T4) between the localizer <NUM> and one or more of the patient trackers <NUM>, <NUM> may be determined by the controller <NUM> by similar techniques and assumptions as described above with respect to transform (T3). Specifically, the localizer <NUM> is configured to monitor the state of one or more of the patient trackers <NUM>, <NUM> and the controller <NUM> is configured to acquire, from the navigation system <NUM>, raw navigation data relating to the state of the one or more of the patient trackers <NUM>, <NUM> relative to the localizer <NUM>. The controller <NUM> acquires the raw navigation data by acquiring one or more values of the fourth instantaneous transform (T4) between the one or more of the patient trackers <NUM>, <NUM> and the localizer <NUM>.

As shown in <FIG>, a fifth transform (T5) may be calculated between one or more of the patient trackers <NUM>, <NUM> and the virtual boundary <NUM> associated with the anatomy of the patient <NUM> using registration techniques involving the navigation system <NUM> and the pointer (P). Specifically, the pointer (P) is tracked by the navigation system <NUM> via the pointer tracker (PT) and is touched to various points on a surface of the anatomy. The navigation system <NUM>, knowing the state of the pointer (P), registers the state of the anatomy with respect to one or more of the patient trackers <NUM>, <NUM>. Alternatively, (T5) may be broken up into additional (intermediate) transforms that are combined to result in (T5). For example, the additional transforms may correspond to implant placement (surgical planning) relative to a pre-op image, acquired using techniques such as CT, MRI, etc., and location of the one or more patient trackers <NUM>, <NUM> relative to that same pre-op image (registration). One exemplary system and method for registering the anatomy is explained in <CIT>, entitled, "Surgical Manipulator Capable of Controlling a Surgical Instrument in Multiple Modes".

<FIG> is a block diagram illustrating, in part, aspects of the data fusion techniques implemented by the controller <NUM> and as described herein. As shown, transforms (T1)-(T4) are provided from their respective sources, as described above. The third transform (T3) is inputted into an inverse block <NUM> representing inverse matrix calculation as described above. Thus, the output of the inverse block <NUM> is the inverted third transform
(T3'). Transform (T5) is omitted from <FIG> because transform (T5) is not directly utilized by the data fusion block, whose final output gives the pose of the one or more patient trackers <NUM>, <NUM> with respect to the base <NUM>. Instead, transform (T5) is utilized by downstream constraint generator blocks. Aspects of the data fusion calculations will be further described below.

The controller <NUM> is configured to combine the raw kinematic measurement data, the known relationship data and the raw navigation data to determine a raw relationship between the base <NUM> and the localizer <NUM>. Specifically, the controller <NUM> combines values of each of the first, second, and third transforms (T1), (T2), (T3') to determine the raw relationship. As shown in <FIG>, the controller <NUM> does so by applying a matrix multiplier at block <NUM>. The matrix multiplier <NUM> receives the transforms (T1), (T2), and (T3') as inputs and performs matrix multiplication operations (including multiplication of matrices and concatenation of transforms) to combine transforms (T1), (T2), and (T3'). The output of the matrix multiplier <NUM> is the combination of transforms (T1), (T2), and (T3').

When transforms (T1), (T2), and (T3') are combined, the result is the raw relationship defining the state of the localizer <NUM> relative to the state of the base <NUM>. Viewed with respect to <FIG>, this raw relationship may be understood as the (instantaneous) spatial combination of the arrows of (T1), (T2), and (T3') originating at the base <NUM>, extending to the tool <NUM>, through the tool tracker <NUM>, and terminating at the localizer <NUM>.

Since the transforms (T1), (T2), and (T3') are generally raw data when inputted into the matrix multiplier <NUM>, the output of the matrix multiplier <NUM> is consequently also raw data. In other words, the raw relationship may be understood as representing an actual and instantaneous state of the localizer <NUM> relative to the base <NUM>. <FIG> includes a node <NUM> provided at the output of the matrix multiplier <NUM> representing for simplicity a point in the block diagram where the raw relationship is available. The raw relationship, which is based on pose data, is primarily or entirely a spatial relationship. However, the sequences of raw relationships may also signify one or more relationships that are derived from spatial parameters, such as relationships with respect to velocity and/or acceleration of the respective components used in calculating the raw relationship. As will be described, this raw relationship is used for more than one purpose.

As shown in <FIG>, the raw relationship can be represented as a signal (bold line) in the time-domain. The signal in <FIG> is a 6DOF pose such that the plot of <FIG> can be considered a plot of a single component (x, y, z, r, p, y) or as the magnitude of position or angle. The plot of <FIG> may be repeated for any one or more of these single components. As can be seen in <FIG>, under normal operating conditions for the system <NUM>, the raw relationship may exhibit variations resulting from minor changes in the relationship between the base <NUM> and the localizer <NUM>. This variation can be due to physical movements and/or vibrations as well as due to measurement noise.

The raw relationship is particularly important, as will be described below, because both the base <NUM> and the localizer <NUM> are components of the system <NUM> that are assumed to be stationary and any appreciable variation in this transform may reveal system errors not previously detectable.

With the raw relationship now determined, the controller <NUM> is configured to filter the raw relationship. As shown in <FIG>, the controller <NUM> is configured to input the raw relationship into a first filter shown at block <NUM>. The first filter <NUM> is a digital temporal filter that filters the raw relationship in the time-domain. Filtering may be understood as performing a type of averaging over a time history of data. Filtering does not affect the update or measurement rate but rather the frequency of content of the output signal (e.g., how quickly or smoothly the output changes), yet still providing a new output for each sample. The first filter <NUM> results in latency in responding to either the base <NUM> and/or the localizer <NUM> moving. As will be described below, the first filter <NUM> may consequently result in spatial filtering by ultimately causing the manipulator <NUM> to lag (as compared with the raw relationship) in the spatial domain.

The first filtered relationship is available at node <NUM> in <FIG> at the output of the first filter <NUM>. As will be described below, this first filtered relationship is involved in the calculation of constraints and downstream control commands, ultimately used to control the manipulator <NUM>.

Filtering is performed on the raw relationship for two primary purposes, i.e., reducing noise and increasing system stability. If it were possible, using the raw data alone to control the system <NUM> would be preferred since doing so would give the fastest and most accurate response. However, filtering is needed because of practical limitations on the system <NUM>. Such practical limitations include noise reduction and stability improvements by removal of positive feedback. The localizer <NUM> is capable of operating at a much higher bandwidth as compared to the manipulator <NUM>. That is, the localizer <NUM> tracks poses of the trackers <NUM>, <NUM>, <NUM> faster than the manipulator <NUM> can respond. Controlling off the raw relationship alone causes instability of system <NUM> because the manipulator <NUM> must react to commanded movements including those arising from random signal variation (i.e., noise), which are provided at the rate of the localizer <NUM>. For example, the manipulator <NUM> would have to respond to every variation in the raw relationship shown in <FIG>. Commanded movement occurring at a rate higher than the manipulator <NUM> can respond, results in heat, audible noise, mechanical wear, and potentially resonance which can cause system instability. Because the localization data feedback represents an outer positioning loop, it is important to not close this outer loop at a higher bandwidth than the manipulator <NUM> can respond, to avoid instability.

Filtering reduces the bandwidth of the outer positioning loop thereby accommodating the bandwidth limitations of the inner positioning loop of the manipulator <NUM>. Through such filtering, noise is reduced and stability is improved by removal or reduction in positive feedback. The manipulator <NUM> is prevented from reacting to every minor change in the raw relationship. Otherwise, if the manipulator <NUM> had to react to noisy data, the manipulator <NUM> may be susceptible to spatial overshoot of tool <NUM> along the tool path (such as when turning corners). Such spatial overshoot may cause the tool <NUM> to overcut the anatomy contrary to best design practices of favoring undercutting rather than overcutting. Instead, filtering of the raw relationship causes the manipulator <NUM> to behave more smoothly and run more efficiently. Further, noise may be introduced into the system <NUM> through measurement error in the sensors (e.g., encoders, localization feedback data, etc.). Filtering limits overall noise to a threshold tolerable by the system <NUM>.

The first filter <NUM> filters the raw relationship according to a first filter length to produce a first filtered relationship between the base <NUM> and the localizer <NUM>. In general, the greater the filter length for the filter, the greater the filter latency (delay) and averaging. In other words, a greater filter length provides more time to take into account (or average) determinations of the raw relationship over time. Thus, the greater the filter length, the more smooth the filtered relationship is over time. In other words, filtering affects the smoothness of the output, rather than the input.

In one embodiment, the first filter <NUM> may be understood as averaging inputted data, or averaging a time history of data. The first filter <NUM> may be one or more of various types of filters. For example, the first filter <NUM> may be an infinite impulse response (IIR) filter, a finite impulse response filter (FIR), a "boxcar" filter, a moving average filter, or the like. The filter length takes into account the time history of the filter. Examples of a filter length include a "time constant" for IIR filters, number of taps or coefficients (i.e., memory depth) for a FIR (finite impulse response) filter, or any parameter of a filter relating to the amount of depth of data that is processed or averaged. In addition, the filter order and length maybe chosen to meet requirements of the application. Generally, the filtering described herein applies to low pass-type filtering, however, other filter-types, such as band pass, high pass, or notch filtering may be utilized.

The filter length may be expressed as a unit of time. For example, the filter length may be represented in milliseconds (ms) or seconds (s). In one embodiment, the first filter length is greater than or equal to <NUM> and less than or equal to <NUM>. For example, the first filter length may be <NUM>. In this example, for any given time step, the filtered relationship is based on the raw relationship determinations averaged over the previous <NUM> relative to the given time step.

In <FIG>, the effect of filtering is demonstrated whereby the raw relationship is compared with its corresponding first filtered relationship. The first filtered relationship is illustrated as a signal provided directly over the signal of the raw relationship. The variations in the raw relationship signal are substantially reduced in the filtered relationship signal. In other words, the filtered relationship is a smoother version of the raw relationship. The smoothness of the filtered relationship depends on the value of the filter length. It is to be understood that <FIG> is provided for simplicity in explanation and that the signals of the raw relationship and the first filtered relationship may be substantially different than as shown and may exist over different durations of time from one another. Once again, the signal of the filtered relationship in <FIG> is a 6DOF pose such that the plot of <FIG> can be considered a plot of a single component (x, y, z, r, p, y) or as the magnitude of position or angle. The plot of <FIG> may be repeated for any one or more of these single components.

Referring back to <FIG>, the controller <NUM> also filters the raw navigation data relating to the state of the one or more patient trackers <NUM>, <NUM> relative to the localizer <NUM> to produce filtered navigation data. Specifically, the fourth transform (T4) is inputted into a third filter <NUM>, which is a temporal filter, such as a moving average filter, similar to the first filter <NUM>. The output of the third filter <NUM> is the filtered navigation data. The third filter <NUM> is utilized for many of the same reasons described above with respect to the first filter <NUM>, i.e., signal noise reduction and increasing system stability. In this case, however, the third filter <NUM> is tuned based on the bandwidth of the patient anatomy rather than the manipulator <NUM>. The third filter <NUM> helps dampen the response of the manipulator <NUM> in responding to self-induced anatomy (e.g., leg) motion due to tool forces. Without sufficient filtering, positive feedback and resulting instability can result from responding too aggressively to the self-induced leg motion.

The third filter <NUM> may also be represented as a filter length and may be any such filter length as those described herein for the first filter <NUM>. In one embodiment, the filter length of the third filter <NUM> is greater than <NUM> and less than or equal to <NUM>. In one example, the filter length of the third filter <NUM> is <NUM>. The third filter <NUM> results in latency in responding to movement of the anatomy.

The filter length of the third filter <NUM> is generally less than the filter length for the first filter <NUM> for practical considerations. Mainly, the first filter <NUM> filters the raw relationship between two components of the system (i.e., the base <NUM> and the localizer <NUM>) that are assumed to be stationary. Measurements of the tool tracker <NUM> play a role in an outer position loop used to adjust/correct commands to the manipulator <NUM>. The length of the first filter <NUM> increases the time interval over which manipulator <NUM> positioning errors are corrected, a minimum amount of which is required to maintain stability.

To the contrary, the third filter <NUM> filters the raw navigation data including the state of the one or more patient trackers <NUM>, <NUM>, which are assumed to move during operation of the system <NUM>. Movement of the patient trackers <NUM>, <NUM> may result from movement of a table on which the patient <NUM> rests, movement of the patient <NUM> generally, and/or local movement of the anatomy subject to the procedure. Movement may also occur from anatomy holder dynamics, cut forces affecting movement of the anatomy, and/or physical force applied to the anatomy by an external source, i.e., another person, or a collision with an object. It is desirable to limit the length of the third filter <NUM>, e.g., to allow the manipulator <NUM> to track/respond to motion within practical limits needed for stability.

The first filter <NUM> can afford applying a relatively longer filter length (slower response) to the raw relationship because this relationship is based on components assumed to be stationary. On the other hand, the third filter <NUM> requires a shorter filter length to allow fast response to movement of the one or more patient trackers <NUM>, <NUM>.

As shown in <FIG>, the controller <NUM> combines the first filtered relationship (from the first filter <NUM>) and the filtered navigation data (from the third filter <NUM>) to produce a third filtered relationship. The controller <NUM> does so by utilizing a second matrix multiplier at block <NUM>, which operates similar to the matrix multiplier at block <NUM>. The third filtered relationship is a filtered relationship between the base <NUM> and one or more of the patient trackers <NUM>, <NUM>. The output of the second matrix multiplier <NUM> is the combination of (first) filtered transforms (T1)*(T2)*(T3'), and (third) filtered transform (T4). The combination of the filtered transforms (T1)*(T2)*(T3') provides a signal at the output of the first filter <NUM>, which can be seen at node <NUM> in <FIG>, for reference. Viewed with respect to <FIG>, the third filtered relationship may be understood as the (filtered) spatial combination of the arrows of (T1), (T2), (T3'), and (T4) originating at the base <NUM>, extending to the tool <NUM>, through the tool tracker <NUM>, to the localizer <NUM> and terminating at one or more of the patient trackers <NUM>, <NUM>.

The controller <NUM> is configured to utilize the third filtered relationship to generate the tool path and/or to position the virtual boundaries <NUM> relative to the patient anatomy and to convert the same into coordinates relative to the base <NUM> for controlling the manipulator <NUM>. In <FIG>, the output of the second matrix multiplier at block <NUM> is passed to the manipulator controller <NUM> such that the path generator <NUM> generates the tool path based on the third filtered relationship and such that the boundary generator <NUM> generates the virtual boundaries <NUM> based on the third filtered relationship.

Techniques have been described above for fusing the kinematic measurement data and navigation data and filtering the same to obtain the (intermediate) first filtered relationship, and ultimately, the (final) third filtered relationship for controlling the manipulator <NUM>. Notably, the raw relationship between the base <NUM> and the localizer <NUM> remains available (at node <NUM> in <FIG>) prior to being filtered by the first filter <NUM>. This raw relationship is exploited for techniques described herein to detect errors and/or loss of accuracy in the system <NUM>. Details regarding the theory and implementation of this error detection technique are provided below.

During typical operation of the system <NUM>, there is an assumption that both the base <NUM> and the localizer <NUM> are stationary. Therefore, provided that neither the base <NUM> nor the localizer <NUM> moves during machining, digital filtering (as described above) can be performed on the raw relationship without directly affecting the dynamic response of the manipulator <NUM> to tracking of movement of the patient trackers <NUM>, <NUM>. However, there are downsides to this filtering. For example, if the base <NUM> and/or the localizer <NUM> do move during machining, then the first filtered relationship (base <NUM> to localizer <NUM>), and ultimately, the third filtered relationship (base <NUM> to patient trackers <NUM>, <NUM>) become inaccurate and/or invalid. Furthermore, as described above, the first filter <NUM> generally has a longer filter length to accommodate stability requirements of the outer position loop. Extracting the raw relationship before filtering by the first filter <NUM> allows error determinations to be made instantaneously or near instantaneously that would otherwise be delayed by filtering.

Even though the assumption is that neither the manipulator <NUM> nor the localizer <NUM> is actively moving during machining, it is desirable to allow the raw relationship to adjust (via filtering) during runtime rather than simply performing a "one time" registration to compute a fixed transform. The outer positioning loop is enabled by allowing this raw relationship to adjust gradually during runtime. In other words, if the raw relationship were to be held constant, the outer positioning loop would not be active. Errors in the positioning of the manipulator <NUM>, e.g., based on encoder data or calibration errors, are corrected by the system <NUM> by making fine adjustments to the raw relationship over time. In a sense, this can be thought of as the manipulator <NUM> positioning the localizer <NUM> (virtually) as needed relative to its base <NUM> so that the tool tracker <NUM> and the one or more patient trackers <NUM>, <NUM> are in correct positions relative to each other. Said differently, if the first transform (T1) is not aligned with the third transform (T3), the manipulator <NUM> virtually adjusts the localizer <NUM> to be in the correct state to align the transforms (T1), (T3). The result is that the subsequent commands to the manipulator <NUM>, converted from anatomy coordinates to base coordinates using this updated transform, cause the tool positioning to converge to a more accurate result, compared to if the localization data from the tool tracker <NUM> was not used.

From an accuracy standpoint, if all components in the system <NUM> were perfectly accurate, then the raw relationship would be a constant with no variation or noise. However, this is not the case, as shown by the raw relationship signal in <FIG>. Variation in the raw relationship exists and may be correlated to errors or loss of accuracy in the system <NUM>. As a positioning device, the manipulator <NUM> is designed to have very high repeatability and incremental accuracy (in a small/local working volume). However, the manipulator <NUM> may not be as accurate when measured over its entire workspace. On the other hand, the localizer <NUM> is designed to exhibit high and consistent accuracy over its entire workspace. As the manipulator <NUM> moves from one part of the workspace to another, there will be some (expected) positioning error as a result. This error is measured by the navigation system <NUM> through the localizer <NUM> and the tool tracker <NUM>. As a result, the raw relationship of the transform between the base <NUM> and the localizer <NUM> updates. This update is expected to be small (approximately <NUM> or less), within the range of the global positioning accuracy of the manipulator <NUM>. These updates are reflected by the oscillations in the raw relationship signal in <FIG>.

A variation of the raw relationship over time gives an indication of the overall positioning error in the system <NUM> from a perspective of the localizer <NUM>. The raw relationship is expected to see small and gradual changes over time based on calibration or other positioning errors in the system <NUM>, as shown in <FIG>. However, any abrupt or significant magnitude changes in the raw relationship indicate a notable issue in the system <NUM>. One example of such abrupt change in the raw relationship is shown in its signal in <FIG> wherein the magnitude of the signal exhibits a spike, which can be seen instantaneously in the raw relationship and delayed in the first filtered relationship. To detect a loss in accuracy of the system <NUM>, the error detection technique is provided to compare the values of the raw relationship (or a lightly filtered version of the raw relationship) with the values of the first filtered relationship, which is more heavily filtered.

To implement this error detection technique, the controller <NUM>, as shown in <FIG>, is configured, according to one embodiment, to filter the raw relationship by applying the raw relationship to a second filter <NUM>. The second filter <NUM> has a (second) filter length being shorter than the first filter length of the first filter <NUM>. That is, the raw relationship is lightly filtered relative to the filtering of the first filtered relationship. The output of the second filter <NUM> is a second filtered relationship between the base <NUM> and the localizer <NUM>. The second filtered relationship is generated specifically for the error detection technique. In one example, the filter length of the second filter <NUM> is greater than <NUM> and less than or equal to <NUM>, as compared to, for example, the filter length of <NUM> for the first filter <NUM>.

In this embodiment, the raw relationship is filtered by the second filter <NUM> to remove high frequency noise or high frequency jitter from the raw relationship signal, and to help isolate from false trips on the error detection. The amount of filtering (filter length) applied to the raw relationship for error detection purposes should be chosen, such that, it is long enough to remove the aforementioned high frequency noise/jitter in the signal, but short enough such that error detection reacts quickly enough to prevent significant errors in machining due to loss of accuracy in the system <NUM>. When filtered, it is generally understood that the filter length is greater than zero. In one preferred embodiment, the error detection technique filters the raw relationship by a filter length allowing detection of errors in a time interval similar to the filter length of the closed loop positioning of the system <NUM>. In this embodiment, the controller <NUM> compares the first filtered relationship to the second filtered relationship to determine whether an error has occurred relating to at least one of the manipulator <NUM> and the localizer <NUM>.

In another embodiment, the controller <NUM>, as shown in <FIG>, is configured to compare the raw relationship (instead of the second filtered relationship) to the first filtered relationship to determine whether the error has occurred. In this example, the raw relationship is not filtered. Hypothetically, it may also be understood that the raw relationship, in this embodiment, is filtered by the second filter <NUM> having a filter length of zero. If filtered by filter length of zero, the raw relationship "passes through" the second filter <NUM>. Whether unfiltered, or filtered by filter length of zero, the raw relationship is the same in both of these instances. In this embodiment, the controller <NUM> compares the raw relationship to the first filtered relationship to determine whether the error has occurred relating to at least one of the manipulator <NUM> and the localizer <NUM>.

The controller <NUM> is configured to make this comparison by accessing each of the first filtered relationship and the raw relationship/second filtered relationship. The first filtered relationship, as shown in <FIG>, remains available at node <NUM> before being inputted into the second matrix multiplier <NUM> for controlling the manipulator <NUM>. The first filtered relationship is duplicated or accessed at this point <NUM> for error detection purposes, leaving the first filtered relationship in tact for control purposes downstream. The raw relationship or second filtered relationship are accessible from the branch in <FIG> stemming from node <NUM> and comprising the second filter <NUM>, if utilized.

Each of the first filtered relationship and the raw relationship/second filtered relationship are then passed to the error detection module <NUM>. The error detection module may be implemented by the manipulator controller <NUM>, as shown in <FIG>. The error detection module <NUM> may comprise any suitable computer-executable instructions, algorithms, and/or logic for comparing the raw relationship or second filtered relationship to the first filtered relationship. In one embodiment, the error detection module <NUM> compares the raw relationship or second filtered relationship to the first filtered relationship by determining a difference between the same.

In general, the first filtered relationship alone may not be suitable for error handling. Mainly, the filter length of the first filter <NUM> may be too long for real time error detection. In other words, the system <NUM> would not be able to react to detection of the error quickly enough if the first filtered relationship alone is utilized. As part of this error handling method, the first filtered relationship is utilized instead as a 'steady state' or mean value of the raw relationship/second filtered relationship. By subtracting the first filtered relationship from the raw relationship/second filtered relationship, the signal is de-trended (i.e., its mean value updated over time by the first filter <NUM> is removed) such that the variation may be more easily evaluated. The resulting difference represents variation or changes in the raw relationship over time. In turn, the amount of variation between the first filtered relationship and the raw relationship/second filtered relationship gives an indicator of degradation in runtime system accuracy.

In one embodiment, comparing the first filtered relationship to the raw relationship/second filtered relationship occurs by converting each relationship to its respective positional (xyz) and angular components and by subtracting the respective components of each relationship. After subtraction, the magnitude of the positional and angular components may be computed, respectively, and each compared to a corresponding positional/angular predetermined threshold, as shown in <FIG>. Thus, the result of this comparison is shown in <FIG>.

The signal in <FIG> is a function of the separation between the first filtered relationship and the raw relationship/second filtered relationship. In <FIG>, the relationships are shown according to any one or more of component of the spatial error (x, y, z, r, p, y), the position magnitude, or the angle magnitude, with respect to time. That is, the greater the separation between these transforms in <FIG>, the greater the magnitude of variation in <FIG>. This variation is compared to the predetermined threshold, as shown in <FIG>. If the variation exceeds the threshold, a loss in accuracy of the system <NUM> is determined. In <FIG>, the threshold is indicated by a sample upper threshold (+) that also represents the floor of an error detection range. In <FIG>, an abrupt change in the raw relationship/second filtered relationship occurs with respect to the first filtered relationship. In turn, this abrupt change causes, at the same time step, a corresponding large separation between the transforms in <FIG>. When the variation signal in <FIG> exceeds the threshold and enters the error detection range, the error in the system <NUM> is detected.

Preferably, the threshold should be greater than zero such that minor/negligible variations between the transforms do not trigger errors. Instead, the sensitivity of the threshold should be set such that only noticeable and/or meaningful errors of the system <NUM> exceed the threshold. The threshold for the positional and/or angular errors may be chosen based on a predetermined error budget of the system <NUM>. For example, if the system <NUM> is designed to have a total error of less than <NUM>, the positional threshold may be set at <NUM> such that there is some safety margin to avoid false trips, but enough sensitivity to detect subtle degradations in performance. The threshold may be a position threshold, an angle (orientation) threshold, or any combination thereof. The threshold may be an upper threshold or a lower threshold and may have other configurations other than that shown in <FIG>.

In an alternative embodiment of the present invention, the error can be detected by evaluating either of the raw relationship or second filtered relationship, alone, for variations, without comparing the same to the first filtered relationship. Mainly, comparing (or subtracting) the first filtered relationship and the raw relationship/second filtered relationship is done for convenience so that the result can be compared to the predetermined threshold. Using either of the raw relationship/second filtered relationship alone would require detecting changes in a present value relative to past values. On the other hand, comparing the first filtered relationship and the raw relationship/second filtered relationship (as described above) allows simple comparison to the predetermined threshold rather than the analysis needed to detect the aforementioned changes of the present value relative to past values. When utilizing the raw relationship alone, detection of such changes can be done using a high pass filter and looking for a signal above the predetermined threshold on the output. When utilizing the second filtered relationship alone, which is a low-pass filter, detection of such changes can also be done using a high pass filter to detect abrupt change. This technique is equivalent to passing of the raw relationship into a band pass filter and performing comparison of the output to the predetermined threshold. To reiterate, using the signal from the first filtered relationship, which is used for control purposes, alone is not suitable to detect the aforementioned error. Those skilled in the art appreciate that there are other mathematically equivalent techniques to detect the error other than those described specifically herein.

In any of the aforementioned embodiments, the detected error generally indicates the error in the system <NUM> or a loss in accuracy of the system <NUM>. Because the error detection technique compares relationships between the base <NUM> and the localizer <NUM>, the error generally relates to at least one of the manipulator <NUM> and the localizer <NUM>.

Specific examples of the error as it relates to the manipulator <NUM> include, but are not limited to, the following: undesired movement of the base <NUM> (such as during machining); improper operation of the manipulator <NUM>; failure of any one or more components of the manipulator <NUM> such as damage to one or more of the links <NUM> and/or increase in gear box compliance at any one or more of the joints (J1-J6); improper kinematic calibration of the manipulator <NUM>; failure or errors in the encoders (e.g., slippage, noise, nonlinearity, misalignment); and any other electrical or mechanical degradation of the same.

Specific examples of the error as it relates to the localizer <NUM> include, but are not limited to, the following: undesired movement of the localizer <NUM> (such as during machining); improper operation of the localizer <NUM>; failure of any one or more components of the localizer <NUM>; improper calibration of the localizer <NUM>; and any other electrical or mechanical degradation of the same. Additionally, the error may indicate improper calibration of the tool <NUM>. The error may relate to any one or more of the aforementioned problems. The error may relate to other problems associated with any other component or subcomponent not specifically recited herein and being in the path of transforms (T1), (T2), and (T3').

Because the techniques described herein use the combination of data from the manipulator <NUM> and the localizer <NUM>, the techniques are able to detect failures not able to be detected in either component standalone. In this manner, the error detection techniques provide a check of the full system. This helps avoid a single source of failure, a critical design aspect for a safety- critical system, such as surgical robotics. The techniques also enable detection of a stack up problem, in which the aggregate error (based upon multiple subtle errors adding up) exceeds an acceptable limit.

The controller <NUM> is configured to modify operation of the system <NUM> and/or manipulator <NUM> in response to determining that the error has occurred. This may be done so to prevent damage to the patient <NUM> and/or the system <NUM> as a result of operation of the manipulator <NUM> during the error. The controller <NUM> may do so using any suitable technique, such as commanding the manipulator <NUM> to hold position, power off, lock a current state of the manipulator <NUM>, and the like. Additionally, or alternatively, the controller <NUM> may power off the tool <NUM> or energy applicator <NUM> by, for example, stopping burr rotation, saw actuation, and/or application of ultrasonic energy thereto, and the like. Those skilled in the art appreciate that controller <NUM> may modify operation of the system <NUM> and/or manipulator <NUM> according to other techniques not described herein in response to determining that the error has occurred.

In response to detection of the error, the controller <NUM> may command prompt of an alert or notification <NUM> on any one or more of the displays <NUM> of the system <NUM>, as shown on the display in <FIG>, for example. The alert or notification <NUM> relates to occurrence of the error to inform operator(s) of the system <NUM> that the error, detected according to the aforementioned techniques, has occurred. The alert or notification <NUM> may be audible, visual, haptic or any combination of the same. In other embodiments, the alert or notification <NUM> may be implemented using any other component of the system <NUM>, such as the manipulator <NUM>, the manipulator cart <NUM>, the navigation system <NUM>, or the like.

The aforementioned error detection method provides a bona fide means for detecting whether a loss in accuracy or an error has occurred in the system <NUM>. In general, the error detection technique may do so without precisely identifying what the error is or where in the system <NUM> the error occurred. From a real time control standpoint, the precise cause of the error is not critical if the controller <NUM> ultimately halts the system or manipulator <NUM> and informs the operator(s). In other words, adverse consequences of the error are mitigated by immediately halting the system or manipulator <NUM>. However, there may be practical reasons for determining the precise cause of the error. For example, such reasons may be related to improving service and diagnostics capabilities, improving GUI feedback to the user to assess the failure, and the like.

In such instances, the aforementioned error detection technique may be combined with auxiliary sensors to provide further specificity as to the cause of the error. Examples of such auxiliary sensors include, but are not limited to, sensors (such as secondary joint encoders, accelerometers, inertial sensors, velocity sensors, position sensors, etc.) in the localizer <NUM> and/or the manipulator <NUM>, sensors in any one or more of the carts <NUM>, <NUM> to detect brake release, auxiliary position sensing (e.g., lower bandwidth type), or the like. For example, one or more auxiliary sensors in the localizer <NUM> and/or the manipulator <NUM> may be configured to detect abrupt changes for the respective component. The controller <NUM> may determine whether the error occurred from the localizer <NUM> and/or the manipulator <NUM> by analyzing these measurements in conjunction with other measurements. Similar techniques may be applied to any other components of the system <NUM>.

These auxiliary measurements may be used to directly detect common (expected) failure modes, and/or rule out causes of failure, allowing process of elimination to point to alternate causes. Additionally, if auxiliary sensors from more than one component detect an abrupt change, the controller <NUM> may compare/combine these measurements, and for example, apply weighting factors to the measurements to identify which component produced the error and by how much each component contributed to the error, as a whole. In other cases, the error may be tripped due to user action, e.g., moving the localizer <NUM> while machining. In such cases, the auxiliary sensors can be used to detect this error and give better guidance to the user to avoid future errors.

Such auxiliary sensors may provide measurements that can be detected and analyzed by the controller <NUM> and evaluated with respect to the detected error to determine the cause of the error. The level of specificity as to determining the cause of the error may depend on the particularity, quantity, location of the auxiliary sensors. In some embodiments, the auxiliary sensors may be used to rule out common errors or user actions (rather than component failures) in the system <NUM>, such as undesired movement of the base <NUM> of the manipulator <NUM> and/or localizer <NUM>, and the like.

Several embodiments have been described in the foregoing description. However, the embodiments discussed herein are not intended to be exhaustive or limit the invention to any particular form. The terminology, which has been used, is intended to be in the nature of words of description rather than of limitation. Many modifications and variations are possible in light of the above teachings and the invention may be practiced otherwise than as specifically described.

Claim 1:
A robotic surgical system (<NUM>) comprising:
a surgical tool (<NUM>);
a manipulator (<NUM>) comprising a base (<NUM>) supporting a plurality of links (<NUM>) and being configured to support the surgical tool (<NUM>);
a navigation system (<NUM>) comprising a tracker (<NUM>) coupled to the surgical tool (<NUM>) and a localizer (<NUM>) being configured to monitor a state of the tracker (<NUM>); and
a controller (<NUM>) coupled to the manipulator (<NUM>) and the navigation system (<NUM>) and being configured to:
acquire, from the manipulator (<NUM>), unfiltered kinematic measurement data relating to a state of the surgical tool (<NUM>) relative to the base (<NUM>);
acquire known relationship data relating to the state of the tracker (<NUM>) relative to the surgical tool (<NUM>);
acquire, from the navigation system (<NUM>), unfiltered navigation data relating to the state of the tracker (<NUM>) relative to the localizer (<NUM>);
combine the unfiltered kinematic measurement data, the known relationship data and the unfiltered navigation data to determine an unfiltered relationship between the base (<NUM>) and the localizer (<NUM>);
filter the unfiltered relationship according to a first filter length to produce a first filtered relationship between the base (<NUM>) and the localizer (<NUM>) for controlling the manipulator (<NUM>);
filter the unfiltered relationship according to a second filter length being shorter than the first filter length to produce a second filtered relationship between the base (<NUM>) and the localizer (<NUM>); and
utilize the second filtered relationship, alone or by comparing the first filtered relationship to the second filtered relationship, to determine whether an error has occurred relating to at least one of the manipulator (<NUM>) and the localizer (<NUM>).