Scalable filtering infrastructure for variable control rates in distributed systems such as surgical robotic systems

Abstract

For scalable filtering infrastructure, a library of filters is provided that are each capable of being used at different control rates by defining the filters in continuous-time mode, regardless of the end use for the digital filtering. To implement, the filter is selected and discretized for the desired control rate. The discretized filter is then deployed as a discrete-time implementation for convolution. In a distributed system with multiple control rates, the library can be used to more quickly and conveniently generate desired filters.

Description

Technical Field

[0001] The implementation scheme relates to scalable filtering for design and / or use in surgical robotic systems or other systems. Background Technology

[0002] Surgical robotic systems give operating surgeons the ability to mechanically perform one or more actions in a surgical procedure. In a surgical robotic system, the robot manipulates surgical tools to assist in the procedure. A user console receives user input to control the robot and can be positioned remotely from the robot. A control tower is communicatively connected between the user console and the robot. These distributed components have different signal or data filtering requirements. Complicating filtering is that different components can provide data for filtering at different sampling rates. Due to different operating modes, a given component can operate at different rates. The active components of the system vary depending on various system and / or subsystem modes, such as clinical mode (i.e., surgical operation), training or simulation mode, or stand-alone mode (e.g., active system failure states due to communication loss). In these modes, system functionality is often repeated to meet operational requirements or redundantly implemented for fault detection or fault handling. Depending on hardware specifications or computational limitations, various low-level control algorithms implemented as firmware or software may need to operate at various different control rates. Therefore, designing filters suitable for various signals at different control rates is difficult and time-consuming. Summary of the Invention

[0003] By way of introduction, the preferred embodiments described below include methods, systems, instructions, and computer-readable media for scalable filtering infrastructure. Regardless of the end use case for digital filtering, a library of filters is provided that can be used at different control rates by defining filters in a continuous-time pattern. To achieve this, filters are selected and discretized for the desired control rate. The discretized filters are then deployed as discrete-time implementations for convolution. In distributed systems with multiple control rates, this library can be used to generate desired filters more quickly and conveniently.

[0004] In a first aspect, a method for filtering information in a surgical robotic system is provided. A library of filters defined as continuous-domain transfer functions is generated. A first filter in the filter is discretized based on the sampling rate of the information in the surgical robotic system. The information is filtered at the sampling rate. The filtering includes convolving the information with a linear system implementation of the first filter in the filter. The surgical robotic system operates using the filtered information, such as operating in any of various modes.

[0005] In a second aspect, a surgical robot system for filtering at different control rates is provided. The surgical robot has a first component capable of operating at a first control rate. A user console is configured to receive user input for controlling the surgical robot. The user console is connected to the surgical robot wirelessly or via a wire. The user console has a second component capable of operating at a second control rate different from the first control rate. A memory stores a library of filters defined in a continuous domain. A processor is configured to discretize a first filter from the library using the first control rate and a second filter from the library using the second control rate. The processor is configured to generate discrete-time implementations of the first and second filters.

[0006] In a third aspect, a method for a scalable filtering infrastructure is provided. A filter requirement for filtering at a first control rate is input. A filter is generated from a filter library based on this requirement. The filter in the library is independent of the first control rate. The selected filter is converted to the first control rate. A filter kernel is generated for the converted filter. The signal is filtered using the filter kernel at the first control rate.

[0007] This invention is defined by the following claims, and the content of this section should not be construed as limiting those claims. Other aspects and advantages of the invention are discussed below in conjunction with preferred embodiments, and may subsequently be claimed independently or in combination. Attached Figure Description

[0008] Embodiments of the invention are illustrated by way of example and not by way of limitation in the accompanying drawings, wherein similar reference numerals indicate similar elements. It should be noted that references to "an" or "one" embodiment of the invention in this disclosure do not necessarily refer to the same embodiment, and that they refer to at least one. Furthermore, for the sake of brevity and to reduce the total number of drawings, a given drawing may be used to illustrate features of more than one embodiment of the invention, and not all elements in the drawing may be necessary for a given embodiment.

[0009] Figure 1 This is a drawn view of an exemplary surgical robotic system in a surgical setting;

[0010] Figure 2 This is a flowchart of an implementation scheme for a method to implement a scalable filter infrastructure;

[0011] Figure 3 A scalable filter infrastructure is shown; and

[0012] Figure 4 This is a block diagram of one implementation of a robotic system using a scalable filter infrastructure. Detailed Implementation

[0013] Scalable software infrastructure supports variable control rates for reconfigurable hardware and / or software. To address different operating modes and distributed systems, a continuous-time filter library provides a discretization method that allows software to operate at a variety of control rates while maintaining transient and steady-state system response and / or performance.

[0014] In one implementation, the filtering process is divided into three stages. In the first stage, a library is generated using filter definitions and corresponding performance requirements. Users or developers define the desired system characteristics for filtering in software or hardware. These characteristics include, but are not limited to, transfer function type, cutoff frequency, attenuation, bandwidth, order, etc. Filters for these requirements are converted into S-domain transfer functions. Alternatively, the S-domain transfer function is specified directly. The result is a library of filters defined in continuous time. In the second stage, one or more filters are discretized. Discrete Z-domain transfer functions are generated from the selected filters in the library, based on the specified control rate of the software process and the intended application. In the third stage, standard controllable or observable implementations or custom implementations are generated based on the context. For filter deployment or implementation, the discretized filters are used to generate a discrete-time implementation that can perform signal filtering as needed. In some real-time contexts, additional requirements may be placed on filters meeting minimum dynamic memory allocation at runtime. The order of the selected filter can be used to control memory allocation.

[0015] The formation of continuous-time filters with libraries discretized to specific control rates supports multiple control rates across different system (hardware and / or software) configurations. The continuous-time library separates the mathematical definition of the discrete filter from its real-time context usage. Validation of filter parameters (including stability at a specified control rate) can be achieved by using the library to test different filters for a given context. The library infrastructure with discretized control rates required for specific implementations reduces the number of control parameters and the tuning workload for robot or control engineers. Because the filter definition is separated from the context, the requirements for the defined filters can be accurately documented.

[0016] Figure 1 An exemplary surgical robot system is illustrated. The surgical robot system is a distributed system and includes multiple operating modes, both of which result in the use of different filters within a single system (e.g., for different components and / or for different operating modes). Figure 1Provided as an exemplary environment for using filter infrastructure. In other embodiments, other distributed systems and / or other systems with multiple operating modes may be provided, whether or not they are robotic systems or medical systems. In an alternative embodiment, a single processor operating in one mode uses filtering at more than one control rate, thus the filter infrastructure is used for different filters implemented by the processor or by the processor.

[0017] Figure 2 The method of using filter infrastructure is shown, and Figure 3 An exemplary representation of a filter infrastructure is shown. Figure 4 An exemplary general-purpose distributed system for using filter infrastructure is shown, although in a robotics context.

[0018] Figure 1 This is a drawing view of an exemplary surgical robotic system 1 in a surgical setting. The surgical robotic system 1 includes a user console 2, a control tower 3, and one or more surgical robotic arms 4 at a surgical platform 5 (e.g., a table, bed, etc.). The surgical robotic system 1 can be combined with any number of devices, tools, or accessories for performing surgery on a patient 6. For example, the surgical robotic system 1 may include one or more surgical tools 7 for performing surgical procedures. The surgical tool 7 may have an end effector at its distal end (which is also the distal end of the surgical robotic arm 4 to which the surgical tool 7 is attached) for performing surgical operations such as suturing, cutting, grasping, extending, or energy emission.

[0019] Each surgical tool 7 can be manually manipulated, robotically manipulated, or both during surgery. For example, a surgical tool 7 can be a tool for accessing, viewing, or manipulating the internal anatomy of a patient 6. A surgical tool 7 can be directly and manually controlled by the hand of a bedside operator 8; or it can be robotically controlled by sending electronic commands to actuate the movement of a surgical robotic arm 4 attached to the surgical tool 7. The surgical robotic arm 4 is shown as a tabletop system, but in other configurations, it can be mounted on a trolley, ceiling, or sidewall, or in another suitable structural support.

[0020] Generally, a remote operator 9 (such as a surgeon) can use a user console 2 to remotely manipulate the surgical robot arm 4 and attached surgical instruments 7, for example, through remote operation. The user console 2 may be located in the same operating room as the rest of the surgical robot system 1, such as... Figure 1As shown. However, in other environments, the user console 2 may be located in an adjacent or nearby room, or it may be located in a remote location, such as in a different building, city, or country. The user console 2 may include a seat 10, foot controls 13, one or more handheld user interface devices (UIDs) 14, and at least one user display 15 configured to display a view, for example, of a surgical site within a patient 6. In the exemplary user console 2, a remote operator 9 sits in the seat 10 and views the user display 15 while manipulating the foot controls 13 and the handheld UID 14 to remotely control the surgical robotic arm 4 and surgical instruments 7 (which are mounted on the distal end of the surgical arm 4).

[0021] In some variants, the bedside operator 9 can also operate the surgical robot system 1 in a "bedside" mode, where the bedside operator 8 (the user) is now positioned to one side of the patient 6 and simultaneously manipulates i) robot-driven tools (with end effectors) attached to the surgical robot arm 4, such as holding a handheld UID 14 with one hand, and ii) manual laparoscopic tools. For example, the bedside operator's left hand can manipulate the handheld UID to control the surgical robot components, while the bedside operator's right hand can manipulate the manual laparoscopic tools. Thus, in these variants, the bedside operator 8 can perform both robot-assisted minimally invasive surgery and manual laparoscopic surgery on the patient 6.

[0022] During the exemplary procedure (surgical operation), patient 6 is prepared for surgery and anesthesia is administered by aseptically covering the patient with a sterile drape. Initial access to the surgical site can be manually performed (to facilitate access to the surgical site) while the arms of the surgical robot system 1 are in a retracted or withdrawn configuration. Once access is complete, initial positioning or preparation of the surgical robot system 1, including its surgical robot arm 4, can be performed. The surgery then continues, with the remote operator 9 at the user console 2 using foot controls 13 and UID 14 to manipulate various end effectors and, possibly, imaging systems to perform the surgery. Artificial assistance can also be provided at the operating table or surgical table by a bedside person (e.g., bedside operator 8) wearing sterile surgical gowns, who can perform tasks on one or more arms of the surgical robot arm 4, such as tissue retraction, manual repositioning, and tool changes. Non-sterilized personnel may also be present to assist the remote operator 9 at the user console 2. When the procedure or surgery is completed, the surgical robot system 1 and the user console 2 can be configured or set to facilitate postoperative procedures (such as cleaning or disinfection) and the input or printing of health records via the user console 2.

[0023] In one embodiment, a remote operator 9 grasps and moves UID 14 to provide input commands, thereby moving the robotic arm actuator 17 in the surgical robot system 1. UID 14 may be communicatively coupled to the rest of the surgical robot system 1, for example, via a console computer system 16. UID 14 may generate spatial state signals corresponding to the movement of UID 14, such as the position and orientation of the UID's handheld housing, and these spatial state signals may be input signals for controlling the movement of the robotic arm actuator 17. The surgical robot system 1 may use control signals derived from the spatial state signals to control the coordinated movement of the actuator 17. In one embodiment, a console processor of the console computer system 16 receives the spatial state signals and generates corresponding control signals. Based on these control signals controlling how the actuator 17 is energized to move a segment of the surgical robot arm 4, the movement of a corresponding surgical tool attached to the arm may simulate the movement of UID 14. Similarly, the interaction between the remote operator 9 and UID 14 may generate, for example, a clamping control signal that causes the jaws of the gripper of the surgical tool 7 to close and clamp the tissue of the patient 6.

[0024] The surgical robot system 1 may include a plurality of UIDs 14, wherein a corresponding control signal is generated for each UID 14, which controls the actuators and surgical instruments (end-effectors) of the corresponding surgical robot arm 4. For example, a remote operator 9 may move a first UID 14 to control the movement of an actuator 17 located in the left robotic arm, wherein the actuator responds by moving links, gears, etc. in the surgical robot arm 4. Similarly, the movement of a second UID 14 by the remote operator 9 controls the movement of another actuator 17, which in turn moves other links, gears, etc. of the surgical robot system 1. The surgical robot system 1 may include a right surgical robot arm 4 fixed to a bed or table on the right side of the patient, and a left surgical robot arm 4 located on the left side of the patient. The actuators 17 may include one or more motors, which are controlled such that they drive the joints of the surgical robot arm 4 to rotate, for example, relative to the patient, changing the orientation of the endoscope or gripper of the surgical instrument 7 attached to the arm. The movement of a plurality of actuators 17 in the same surgical robot arm 4 may be controlled by spatial state signals generated from a particular UID 14. UID 14 can also control the movement of the corresponding surgical tool gripper. For example, each UID 14 can generate a corresponding clamping signal to control the movement of an actuator (e.g., a linear actuator) that opens or closes the jaws of the gripper at the distal end of the surgical tool 7 to clamp tissue within the patient 6. One or more UIDs in UID 14 can also control the movement of a suture device, such as activating the application of staples to the tissue of the patient 9.

[0025] In some respects, communication between the surgical platform 5 and the user console 2 can be achieved via a control tower 3, which translates user commands received from the user console 2 (and more specifically from the console computer system 16) into robot control commands transmitted to the surgical robotic arm 4 on the surgical platform 5. The control tower 3 can also transmit status and feedback from the surgical platform 5 back to the user console 2. The communication connection between the surgical platform 5, the user console 2, and the control tower 3 can be via wired and / or wireless links, using any suitable data communication protocol from a variety of data communication protocols. Any wired connection can optionally be integrated into the floor and / or walls or ceiling of the operating room. The surgical robotic system 1 can provide video output to one or more displays, including displays within the operating room and remote displays accessible via the Internet or other networks. Video output or feeds can also be encrypted to ensure privacy, and all or part of the video output can be stored on a server or electronic healthcare record system.

[0026] Any of the various components of a surgical robotic system can generate, manipulate, or receive a signal to be filtered. The processor or other digital hardware is programmable to implement the desired filtering. In a distributed system like this exemplary robotic surgical system, there may be dozens or hundreds of different filters to be implemented. The same signal can also be filtered differently, even at different control rates, depending on whether the system can operate in different modes. The sampling rates used by different components (e.g., processors or other hardware) and / or for different modes may require defining even more filters. Designing filter cores individually for all these filters is time-consuming and difficult.

[0027] Figure 2 This is a flowchart of an implementation of a method for creating and using a scalable filtering infrastructure. The filtering process is divided into three phases: filter definition in the library, discretization, and implementation. One or more filters are generated for use by one or more components and / or operating modes. In an exemplary use case, Figure 2 A method for filtering information in a surgical robotic system is shown.

[0028] This method is implemented by a processor such as a computer, workstation, or server. The implemented filter can be executed by one or more other processors, such as a processor implementing software filtering or programmable hardware implementing filtering. For example, actions 200 through 212 are executed by a computer. Different computers can use and / or be used for different actions of this method at different times, such as one computer for actions 200 and 202, while different computers are used for actions 204 through 212. In this example, action 214 is executed by a component of a distributed system or other system.

[0029] The action can be performed in the indicated order (e.g., top to bottom or numerical) or a different order. For example, in action 206, a filter is selected based on other criteria (e.g., the user selects a filter of the desired type), and then in action 204, the requirements for the selected filter are entered.

[0030] Additional, different, or fewer actions can be provided. For example, actions 200 and / or 202 are not executed if the library already exists or the user chooses to directly specify the discrete transfer function. In yet another example, actions 200 and 202 are executed without any additional actions to create a library of continuous-time filters.

[0031] In Action 200, one or more processors generate a filter. This filter is generated individually or in conjunction with other filters from a filter library. The user or developer defines the desired system characteristics. These characteristics include, but are not limited to, transfer function type, cutoff frequency, attenuation, bandwidth, and order. Filters with different characteristics are defined. These definitions can be formed through search or randomization, or they can be characteristics required for a specific system. The input defines a set of characteristics for multiple different filters.

[0032] In one implementation, the transfer function type is used to define a generic filter for each type. Bandwidth, cutoff frequency, attenuation, and / or other characteristics are not defined because the generic filter can be configured to provide different bandwidths, cutoff frequencies, attenuations, and / or other characteristics. Filters for the library can be defined using any subset or all of the characteristics.

[0033] In action 202, the filter is defined as a time-continuous filter. The library is generated as a library of filters defined as continuous-domain transfer functions. The defined filter is converted to an s-domain transfer function, for example, using Laplace-domain processing. Alternatively, the definition can directly specify the s-domain transfer function. The filter definition based on the requirements is converted to a continuous-domain transfer function. Alternatively, action 204 is performed prior to action 202, which is the conversion of the defined filter to a time-continuous filter.

[0034] Time-continuous filters, such as those provided by s-domain transfer functions, are independent of the sampling rate. By defining the filter as time-continuous (e.g., analog), the sampling rate is not used in that definition.

[0035] In one implementation, the definitions are based on the filter type. Libraries are generated to include filters of different types. For example, a library H(s) in the s-domain is represented as:

[0036]

[0037] Where f is the filter, the parameter in parentheses is the filter variable, the subscript is the type of the transfer function, and "ct" is a user-defined parameter.

[0038] In the generation of the transfer function, the filter definition specifies filter parameters, such as the cutoff frequency, the slope of the amplitude response plot, etc. These definitions are converted into a continuous-domain (s-domain) transfer function. Some exemplary filters that serve as s-domain transfer functions include Butterworth filters, Chebyshev Type II filters, notch filters, second-order filters, and custom filters. A Butterworth filter is defined by a cutoff frequency (ω). n The parameterization is performed on the order (n), where the discretization method is a bilinear transform. The s-domain transfer function is given as:

[0039]

[0040] The s-domain transfer function of the Chebyshev Type II filter is given by the following equation:

[0041]

[0042]

[0043]

[0044] The s-domain transfer function of the notch filter is given by the following equation:

[0045]

[0046] The s-domain transfer function of a second-order filter is given by the following equation:

[0047]

[0048] An exemplary s-domain transfer function for a custom filter is given by the following equation:

[0049]

[0050] Other types of filters can be used. Multiple filters of the same type can be defined, such as those in which one or more variables are set or defined in the s-domain transfer function.

[0051] The resulting set H(s) of time-continuous filters provides a library of defined filters. Figure 3 An example is shown. Filter definition 300 includes library 301 containing filters 302-306. Any number of filters can be defined.

[0052] Once the library is created, you can define and add other filters. When new requirements are found from new modes, components, and / or signals, new filters can be added to library 301.

[0053] Once library 301 is created, use it to create filters for a given component and / or signal. Reference Figure 2 In action 204, input the filter requirements for the filter to be created. Input filter requirements include, for example, bandwidth, cutoff frequency, transfer function type, attenuation, order, and / or other characteristics of the filter or the signal to be filtered (e.g., data stream).

[0054] The order of a filter can be limited. For example, the memory space available for a given component to implement a filter may be limited. Similarly, the order of the filter can be limited to avoid exceeding the available memory.

[0055] The component and / or signal to be filtered has a given control rate. The sampling rate or speed of the filter can vary for different components, modes, and / or signals. Since the filter is implemented for software filtering or filtering via programmable hardware, the signal to be filtered is a digital signal with a given sampling rate. Filter requirements include control or sampling rate.

[0056] Designers, engineers, or other users input filter requirements. This input can be made by selecting a filter in action 206 or by providing values ​​for one or more variables.

[0057] In action 206, the processor selects or generates filters 302-306 from library 301 based on filtering requirements such as those required by the user. These requirements may result in the identification of a filter 302-306 from the library. For example, a filter type is identified, and this type is specialized based on the user's requirements. Alternatively, multiple filters 302-306 may be identified.

[0058] For example, the processor outputs the identified filters 302-306 that match the requirements in a list. The user can then select a specific filter from filters 302-306. Alternatively, the processor identifies a filter from filters 302-306 that meet the requirements based on any criteria (such as minimum memory usage). This implementation provides flexibility through, for example, memory reduction, where the input version requires ~2n memory and the specification version requires ~n memory. In other embodiments, the user selects filters 302-306 without processor selection.

[0059] The selected filter (e.g., filter 306) is in the continuous-time domain. In action 208, the processor converts the filter based on a control rate. In action 210, the selected filter is discretized to operate at the control rate. Since the filter will operate on samples or data at a given rate in a digital environment, the filter is discretized to operate at that rate. The selected filter is converted from the continuous-time domain to the discrete-time domain to operate at the control rate. For filter discretization, the continuous-time transfer function generated from the filter definition is mapped to a discrete-time transfer function. The sampling or control rate for the information to be filtered is used to discretize the filter. In one embodiment, the z-domain transfer function is formed as a discrete-time transfer function. The z-domain transfer function is formed at the sampling rate.

[0060] Based on the specified control rate and expected application of the software process, the discretized z-domain transfer function H(z) is generated, as expressed by the following equation:

[0061]

[0062] Bilinear, matched, and n-holding are types of substitutions for continuous-time variables s and discrete-time variables z. Any substitution can be used, such as bilinear, bilinear with pre-warped curves, or matched substitutions of continuous-time variables with filters.

[0063] In one exemplary implementation of filter discretization, ΔT is a hardware and / or software mode-specific parameter representing the nominal control rate or update period of the signal to be processed. For bilinear substitution, In continuous-time transfer functions, for bilinear functions with frequency pre-warping, In the continuous-time transfer function, where ΔT p This is the pre-warping compensation time step. For matched replacement, this is achieved through mapping. After mapping the poles and zeros of the continuous-time transfer function, a discrete-time transfer function is generated. Generally speaking, discretization maps the filter definition to a discrete-rate specific form, expressed as:

[0064]

[0065] Other alternatives can be used.

[0066] Figure 3 This represents discretization into a z-domain transfer function 314. The time step 312 of a given filter to be applied in a given context (e.g., for a selected filter running on specific hardware and / or for filtering a specific signal) is used to discretize into the digital domain, thereby creating the z-domain transfer function 314.

[0067] Depending on the context, a controllable, observable, or custom implementation is generated in action 212. The processor generates the filter kernel for the transformed filter. The discretized filter is implemented. To instantiate the discretized filter, the filter kernel is created.

[0068] In one implementation, a linear system implementation is performed in the discrete-time domain. For filter deployment or implementation, the discrete-time implementation is transformed to perform signal filtering as needed. The discrete-rate form can be implemented using linear system implementation techniques, resulting in a filter kernel that can be convolved with the input signal.

[0069] Exemplary linear system implementation techniques include controllable techniques, represented as follows:

[0070]

[0071] C = [β] n -α n β0 β n-1 -α n-1 β0...β1-α1β0] D=β0.

[0072] Another exemplary technique produces an observable form, represented as follows:

[0073] C = [0 0 ... 1] D = β0. Another technique is time series or input-output format, represented as:

[0074]

[0075] Other technologies may be used.

[0076] In some real-time contexts, filters may be required to meet additional requirements regarding minimum dynamic memory allocation at runtime. This requirement is based on the filter's order. By including the order as a constraint in the filter selection, the implementation can utilize a limited amount of memory.

[0077] In action 214, the system's processor or component filters the information at a sampling rate. The implemented filter is stored in memory accessible to the system's components (such as a surgical robotic system). Alternatively, the component's processor creates and applies the implementation. The processor or other hardware of a component in a distributed system or other system implements the filtering using the implemented filter or another linear implementation, such as a controllable, observable, time-series convolution with input-output form.

[0078] The implemented filter (e.g., filter kernel) is convolved with the signal or data. A linear system implementation is used to filter the signal. Filtering is performed at a control rate of this component. Figure 3 An example of implementation 320 is shown. The implemented filter is provided for dynamic operation 322. The signal is input, and the output is a filtered signal. State 324 represents the state of dynamic filtering. The generated z-domain transfer function represents the kernel that needs to be applied (e.g., multiplied) to the signal (e.g., data) sampled periodically at a control rate for this component via convolution. For this purpose, implementation object 320 is created using dynamics 322 derived from z-domain transfer function 314. The signal is the input to the implementation at runtime, and the internal state 324 of the implementation is updated by its input dynamics. Simultaneously, state 324 is processed by output dynamics to generate the output signal or the filtered signal.

[0079] In one implementation, filtering uses shift operations. Linear system implementations replace matrix multiplication with a block identity matrix with shift operations. Some implementations have alternative dynamics, where at least a portion of the dynamic matrix is ​​an identity matrix. These implementations allow shift operations to reduce computational complexity.

[0080] The filtered information is used by the operating system. In the surgical robot system example, the filtered information is used for control, feedback, sensing, or other processing. The filtered information can be used in one or more operating modes. The filter can operate at a control rate. Different discretizations and implementations are used when the control rate changes with the mode.

[0081] refer to Figure 2 The feedback from action 214 to action 204 represents the use of a library to generate and use filters for another component, signal, and / or mode. The library is used again. A second filter from the library is selected based on the requirements of input 204 (206). The selected filter is discretized (210) using the control rate for the filter's context. After implementation (212), this second filter is used to filter the signal (214) used in the system's operation. For distributed systems with different components having different control rates and / or systems with different modes using different control rates, a library of time-continuous filters is used to create filters for various implementations of digital filtering. Filters are created for different modes and / or components operating at different control rates. Alternatively, feedback is used for iterative filter design.

[0082] Figure 4 A block diagram of one embodiment for filtering at different control rates in a robotic system (e.g., a surgical robotic system) is shown. Filters generated by discretizing time-continuous filters from a library are applied to different components 404, 406 of the system. Figure 2 Methods Figure 3The infrastructure or other methods and infrastructure were used to create filters for components 404 and 406.

[0083] The system includes a robot 400, a user console 402, a processor 410, and a memory 412. Additional, different, or fewer devices may also be used. For example, additional components and / or distributed parts may be provided. In another example, multiple processors and / or memories may be used to host libraries and / or to discretize them.

[0084] Robot 400 is a robotic arm, robotic manipulator, or other movable or controllable machine. In one embodiment, robot 400 is one or more robotic arms 4 for use in a surgical or medical setting, such as those described above. Figure 1 As described.

[0085] Robot 400 includes one or more components 404 for filtering signals. These signals may be sensed or measured information, output control signals, signals being processed, input control signals, communication signals, or any other signals used by robot 400 for operation, simulation, or fault handling.

[0086] Component 404 is a processor, such as a digital signal processor. Component 404 may be a programmable processor, a field-programmable gate array, or a general-purpose processor. Alternatively, component 404 may be an application-specific integrated circuit, a digital filter, or a firmware-operable device. Component 404 implements a filter to filter signals.

[0087] The signal and / or operation of component 404 are at the control rate. The filter is capable of filtering at the control rate. Different component and / or operating modes can result in different control rates.

[0088] User console 402 is configured by hardware and / or software to receive user input for controlling robot 400. User console 402 is a user input device, such as a joystick, a computer with a keyboard and mouse, or a virtual reality device. In one embodiment, user console 402 is used for, for example... Figure 1 The control console 2 of the robotic surgical system is shown. The user console 402 is wirelessly or via wire connected to the robot 400 to control and receive feedback from the robot 400.

[0089] User console 402 includes one or more components 406 for filtering signals. These signals may be sensed or measured information, output control signals, signals being processed, input control signals, communication signals, or any other signals used by user console 402 for operation, simulation, or fault handling.

[0090] Component 406 is a processor, such as a digital signal processor. Component 406 may be a programmable processor, a field-programmable gate array, or a general-purpose processor. Alternatively, component 406 is a digital filter or a firmware-operable device. Component 406 implements a filter to filter signals.

[0091] The signal and / or operation of component 406 is at a control rate. The filter is capable of filtering at the control rate. Different component and / or operating modes can result in different control rates. For example, component 406 has a different control rate than component 404.

[0092] The robot 400 and / or user console 402, including corresponding components 404 and 406, form a distributed system. Multiple individual components, rather than a single component, are provided to withstand different control rates (e.g., using different clocks). The robot 400 and / or user console 402 are capable of operating in different modes. For the surgical robot system example, the different modes could be a clinical mode for manipulating a patient, a simulation mode for simulating patient manipulation, and an independent mode for handling communication failures between the surgical robot 400 and the user console 402. The active components of the system vary depending on the various system and / or subsystem modes. In these modes, system functionality is often repeated to meet operational requirements or redundantly implemented for fault detection or handling. Depending on hardware specifications or computational limitations, various low-level control algorithms implemented as firmware or software may need to operate at various different control rates.

[0093] Memory 412 stores a library of filters defined in the continuous domain, such as... Figure 3 Library 301. In one implementation, the filter is defined in the continuous domain as an s-domain transfer function having a defined or definable transfer function, cutoff frequency, attenuation, bandwidth, and / or order. Any or all characteristics of the filter can be defined or can be definable.

[0094] Memory 412 may be graphics processing memory, video random access memory, random access memory, system memory, cache memory, hard disk drive, optical media, magnetic media, flash drive, buffer, database, combination thereof, or other memory device now known or developed later for storing data. Memory 412 is part of the memory in robot 400, user console 402, computer with processor 410, stand-alone device, or another location or device.

[0095] Memory 412 or another memory is alternatively or otherwise a non-transitory computer-readable storage medium storing data representing instructions executable by a programmed processor 410, component 404, or component 406. Instructions for implementing the processes, methods, and / or techniques discussed herein are provided on a non-transitory computer-readable storage medium or memory such as a cache, buffer, RAM, removable media, hard disk drive, or other computer-readable storage medium. Non-transitory computer-readable storage media include various types of volatile and non-volatile storage media. The functions, actions, or tasks shown in the figures or described herein are performed in response to one or more sets of instructions stored in or on a computer-readable storage medium. The functions, actions, or tasks are independent of a particular type of instruction set, storage medium, processor, or processing strategy and can be executed by software, hardware, integrated circuits, firmware, microcode, etc., operating individually or in combination. Similarly, processing strategies may include multi-processing, multi-tasking, parallel processing, etc.

[0096] In one embodiment, the instructions are stored on a removable media device for reading by a local or remote system. In other embodiments, the instructions are stored at a remote location for transmission over a computer network or telephone line. In still other embodiments, the instructions are stored within a given computer, CPU, GPU, or system.

[0097] Processor 410 is a general-purpose processor, central processing unit, control processor, graphics processor, digital signal processor, 3D rendering processor, application-specific integrated circuit, field-programmable gate array, digital circuit, combination thereof, or a library for generating filters, converting filters from the continuous time domain to the digital time domain, and / or implementing filters from discretization, or other means now known or later developed. Processor 410 may be a single device or multiple devices operating serially, in parallel, or individually. Graphics processor 410 may be the main processor of a computer (such as a laptop or desktop computer) or may be a processor for handling tasks in a larger system such as robot 400 or user console 402. Processor 410 is configured by instructions, design, hardware, and / or software to perform the actions discussed herein.

[0098] Processor 410 is configured to discretize filters from a library at a desired control rate. Different filters or the same filter are converted to the z-domain or discrete-time domain based on different control rates. Processor 410 is configured to generate discrete-time implementations of the discretized filters. For example, the filter is converted from continuous-time to a z-domain transfer function. The z-domain transfer function is implemented by processor 410 as a linear system.

[0099] The implemented filters are provided to components 404 and 406 for filtering and operation of the robot 400 and the user console 402. Alternatively, signals from components 404 and 406 are provided to processor 410 for filtering, and processor 410 provides the filtered results to components 404 and 406 for operation of the robot 400 and the user console 402.

[0100] The foregoing description of exemplary embodiments of the invention, including those described below in the abstract, is not intended to be exhaustive or to limit the invention to the specific forms disclosed. While specific embodiments and examples of the invention have been described herein for illustrative purposes, various modifications are possible within the scope of the invention, as will be recognized by those skilled in the art. These modifications can be made to the invention based on the detailed description above. The terminology used in the following claims should not be construed as limiting the invention to the specific embodiments disclosed in the specification. Rather, the scope of the invention is fully defined by the following claims, which will be interpreted according to the claims.

Claims

1. A method for filtering information in a surgical robot system, the method comprising: A first filter, defined as a continuous domain transfer function, is generated based on filtering requirements. The first filter is discretized based on the sampling rate of the information in the surgical robot system, the sampling rate being based on the operating mode of the surgical robot system; as well as The information is filtered using a first, discretized filter at the sampling rate.

2. The method according to claim 1, wherein, The generation includes generating the first filter as an s-domain transfer function independent of the sampling rate.

3. The method according to claim 1, wherein, Generate a library that generates filters including the first filter, wherein the filters in the library include filters of different types.

4. The method according to claim 3, wherein, Generating the library includes translating the filter definition into the continuous-domain transfer function based on the requirements.

5. The method according to claim 1, wherein, Discretization includes forming a z-domain transfer function as a discrete-time transfer function at the sampling rate.

6. The method according to claim 1, wherein, Discretization includes bilinear, bilinear with pre-warped, or matched substitution of the continuous-time variables of the first filter.

7. The method according to claim 1, wherein, The filtering includes implementing the first filter as a convolution of the information with a linear system implementation of the first filter.

8. The method according to claim 1, wherein, Filtering includes convolutions that are controllable, observable, or have an input-output form of time series.

9. The method according to claim 1, wherein, Filtering includes filtering using shift operations.

10. The method of claim 1, further comprising discretizing a second filter based on different sampling rates in the surgical robot system, and utilizing the linear system of the second filter to filter the signal at different sampling rates.

11. The method according to claim 10, wherein, The surgical robot system includes a distributed system in which the filtering of the information is performed for a first component of the distributed system, and the filtering of the signal is performed for a second component of the distributed system.

12. The method according to claim 1, wherein, Discretization includes discretization at the sampling rate based on the operating mode, which includes one of a clinical mode, a simulation mode, or a standalone mode.

13. A surgical robot system for filtering at different control rates, the surgical robot system comprising: A surgical robot having a first component capable of operating at a first control rate; User console, configured to receive user input for controlling the surgical robot, the user console being wirelessly or via wire connected to the surgical robot, the user console having a second component capable of operating at a second control rate different from the first control rate; A memory that stores a library of filters defined in a continuous domain; and A processor configured to discretize a first filter from the library using a first control rate and a second filter from the library using a second control rate, the processor being configured to generate discrete-time implementations of the first filter and the second filter.

14. The surgical robot system of claim 13, wherein, The first component is configured to apply the first filter, and the second component is configured to apply the second filter.

15. The surgical robot system according to claim 13, wherein, The surgical robot and the user console can operate in a clinical mode for operating on a patient, in a simulation mode for simulating operating on a patient, and in an independent mode in case of communication failure between the surgical robot and the user console.

16. The surgical robot system of claim 13, wherein, The filter defined in the continuous domain includes an s-domain transfer function having a defined transfer function, cutoff frequency, attenuation, bandwidth, and order, wherein the discretized first and second filters include z-domain transfer functions, and wherein the discrete-time implementations of the first and second filters include linear system implementations.

17. A method for a scalable filtering infrastructure, the method comprising: The input is a filter requirement for filtering at a first control rate, which is based on the operation of the surgical robot system; Based on the requirements, a filter is selected from a library of filters, the filters of which are independent of the first control rate and are defined in a continuous-time mode; Convert the selected filter to the first control rate; Generate filter kernels for the transformed filter; as well as The digital signal is filtered using the filter core at the first control rate. The conversion includes discretizing the filter from the continuous-time mode to the discrete-time domain at the first control rate, and the generation includes performing a linear system implementation from the discrete-time domain.

18. The method according to claim 17, wherein, The inputs include designer inputs of filter requirements for components of the surgical robot system operating at the first control rate, the filter requirements including an order limited by memory requirements.

19. The method of claim 17, wherein, The filter includes a first filter and the digital signal includes a first signal, wherein filtering includes filtering the first signal by a first processor of the surgical robot system having distributed components, the first processor being in a first component of the distributed components; and further includes repeating the input, selection, conversion, generation, and filtering of the second signal for a second filter at a second control rate different from the first control rate, the second signal being used by the second filter in a second component of the distributed components.

Images