Patent Application
20230136248
This invention relates to a testing unit for testing at least a portion of a surgical robotic system. In particular, the invention relates to a testing unit for coupling to one or more subsystems of a surgical robotic system for testing those subsystems of the surgical robotic system.
It is known to use robots for assisting and performing surgery.
The surgical robot 100 is controlled remotely by an operator (e.g. surgeon) via an operator console 200 shown in
The operator console 200 also comprises a display 206. The display 206 is arranged to be visible to a user operating the input devices 202, 204. The display is used to display a video stream of the surgical site (e.g. endoscope video).
Some surgical procedures may require several surgical robots, each one carrying an instrument or other implement which is used concurrently with the others at the surgical site.
The endoscope can interface with the robot arm to which it is mounted, or to another part of the robotic system to provide power and data connections to the endoscope. The power connection can provide power to articulations of the endoscope and/or a light of the endoscope. The data connection can provide control signals for controlling the endoscope. The endoscope can capture still and/or moving images (video). The data connection suitably permits the image(s) to be transferred from the endoscope, for example to the operator console for display and/or storage.
In addition to the endoscope video, data including telemetry data can be passed between the robot arms (and instruments coupled to the robot arms) and the operator console. Such data can comprise control signals for effecting operation of the robot arms and instruments, and sensed data generated by sensors located on the arms and/or instruments. The data can therefore relate to the state of the robotic system. It would be useful to be able to determine a state of the robotic system in a more flexible manner.
This summary is provided to introduce a selection of concepts that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.
According to an aspect of the present invention, there is provided a surgical robotic testing unit for testing a surgical robotic system, the surgical robotic system comprising a first subsystem configured to generate a first signal having a first characteristic behaviour and a second subsystem configured to receive the first signal and to respond to the received first signal, the testing unit being configured to:
emulate the first subsystem by:
The testing unit may be configured to analyse the received response signal by comparing the received response signal with an expected signal. The boundary of the first characteristic behaviour may comprise a maximum signal value, and the testing unit may be configured to generate the emulated signal with a value greater than the maximum signal value.
The boundary of the first characteristic behaviour may comprise a minimum signal value, and the testing unit may be configured to generate the emulated signal with a value less than the minimum signal value.
The testing unit may be configured to generate the emulated signal over a range of values that encompasses a first range of values of the first signal.
The boundary of the first characteristic behaviour may comprise a repeatability indication of the first signal, and the testing unit may be configured to generate the emulated signal with a repeatability greater than the indicated repeatability. The repeatability indication may comprise a standard deviation, and the testing unit may be configured to generate the emulated signal with a standard deviation smaller than that of the repeatability indication.
The boundary of the first characteristic behaviour may comprise a rate of change of values of the first signal, and the testing unit may be configured to generate the emulated signal with a rate of change greater than and/or less than the boundary rate of change.
The testing unit may be configured to generate one or more emulated signals from a set of emulated signals, each emulated signal in the set of emulated signals being representative of a signal that can be generated by the first subsystem.
The testing unit may be configured to:
The testing unit may be configured to analyse the received further response signal by comparing the received further response signal with a further expected signal. The first subsystem may comprise one of a control console and a bedside unit and the second subsystem may comprise the other of the control console and the bedside unit.
The testing unit may be configured to emulate a plurality of control consoles and/or bedside units. The emulated signal may be representative of an arm control signal. The emulated signal may comprise one or more desired joint torques and/or speeds. The emulated signal may be representative of an instrument control signal. The emulated signal may comprise an electrosurgical signal.
The emulated signal comprises a desired range of movement of the arm and/or of the instrument.
According to another aspect of the present invention, there is provided a surgical system comprising:
According to another aspect of the present invention, there is provided a method of testing a surgical robotic system, the surgical robotic system comprising a first subsystem configured to generate a first signal having a first characteristic behaviour and a second subsystem configured to receive the first signal and to respond to the received first signal, the method comprising:
According to another aspect of the present invention, there is provided a testing unit configured to perform the method described herein.
According to another aspect of the present invention, there is provided a surgical robotic system comprising a robot having a base and an arm extending from the base to an attachment for an instrument, and a testing unit configured to perform the method described herein.
According to another aspect of the present invention there is provided a non-transitory computer readable storage medium having stored thereon computer readable instructions that, when executed at a computer system, cause the computer system to perform the method as described herein.
Any feature of any aspect above can be combined with any one or more other feature of any aspect above. Any method feature may be rewritten as an apparatus feature, and vice versa.
The present invention will now be described by way of example with reference to the accompanying drawings.
In the drawings:
The following description is presented by way of example to enable a person skilled in the art to make and use the invention. The present invention is not limited to the embodiments described herein and various modifications to the disclosed embodiments will be apparent to those skilled in the art. Embodiments are described by way of example only.
A surgical robotic system will typically comprise many different subsystems. The subsystems, such as an operator console and one or more bedside units, interact with one another to achieve the functionality of the robotic system as a whole. The operator console can operatively control robot arms and instruments coupled to the bedside units, and can receive responses from the bedside units. It is possible to connect the various subsystems of the robotic system together, and to operate the system, so as to be able to determine the states of the various subsystems or the whole system by monitoring data transferred between the subsystems.
In an improved approach, a surgical robotic testing unit can be coupled to one or more of the subsystems of the robotic system. The testing unit can emulate another subsystem, for example by generating signals and transmitting them to the subsystem under test. The testing unit can monitor the response of the subsystem under test, and can thereby determine a state of the subsystem under test. For example, the testing unit can couple to a bedside unit having an arm mounted thereto. The testing unit can generate drive signals to drive the arm joints in a particular manner. The testing unit can monitor sensor signals, such as from torque and/or acceleration sensors on the arm, to determine how the arm responds to the drive signals. If the arm behaves in an unexpected way, the testing unit can determine that a fault has occurred in the arm. Thus the testing unit can be used to diagnose faults in one or more subsystems. The testing unit can also be used in maintenance testing, by analysing responses to one or more of a series of test signals, which may be predetermined.
An advantage of the testing unit described herein is that it is able to generate signals beyond the capability of the subsystem that it emulates. For instance, it can generate signals outside a range of signals of the subsystem being emulated. The testing unit can suitably generate signals that change at a faster or slower rate than that possible from the subsystem being emulated. The testing unit can suitably generate signals with a higher repeatability than is possible from the subsystem being emulated. This can enable a higher accuracy in testing subsystems.
Enabling the testing unit to test the respective subsystem with a signal having a characteristic that exceeds a boundary signal characteristic of a different subsystem signal means that the testing unit can ‘stress-test’ the respective subsystem. That is, the testing unit can test the respective subsystem under conditions that are more extreme than would be experienced during standard operation of the surgical robotic system. This testing approach permits a greater confidence in the response of the subsystem during standard operation.
The surgical robotic testing unit is for testing a surgical robotic system. Suitably, the surgical robotic system comprises a first subsystem. The first subsystem can be an operator console or a bedside unit. The first subsystem is configured to generate a first signal having a first characteristic behaviour. The robotic system comprises a second subsystem, such as a bedside unit or an operator console, configured to receive the first signal and to respond to the received first signal. The testing unit is configured to emulate the first subsystem. The testing unit suitably emulates the first subsystem by generating an emulated signal. The emulated signal is representative of the first signal of the first subsystem. The emulated signal has an emulated behaviour. The emulated behaviour exceeds a boundary of the first characteristic behaviour of the first signal, such that the testing unit is operable to test the second subsystem beyond the capability of the first subsystem.
The testing unit can further emulate the first subsystem by transmitting the generated emulated signal for receiving at the second subsystem. The testing unit is further configured to receive a response signal from the second subsystem indicative of the response of the second subsystem to the emulated signal.
The testing unit is configured to compare the received response signal with an expected signal and to determine a state of the second subsystem based on the comparison.
Thus, the testing unit can perform a maintenance or diagnostic test on the second subsystem, by transmitting a desired signal to the second subsystem and monitoring the response of the second subsystem to the transmitted signal.
Generally, the operator console can be considered to be a subsystem of the surgical robotic system. A bedside unit can be considered to be a further subsystem of the surgical robotic system. The subsystems may be taken at a higher level of generality than this. For example, a plurality of bedside units may be coupled together and considered a subsystem as a whole. The subsystems may be taken at a lower level of generality. For example, an instrument or endoscope coupled to an arm can be considered to be a subsystem. A robot arm coupled to a bedside unit can be considered to be a subsystem. A processing or control module within the operator console can be considered to be a subsystem. However, the precise division of what is to be considered a subsystem of the surgical robotic system is not critical.
The present techniques are applicable where a portion of the surgical robotic system can receive an input and generate an output in response to the received input. This enables that portion to be ‘queried’ by the testing unit. The response of that portion to the testing unit query can be used in regular maintenance and/or fault diagnostics procedures.
In the following discussion, a bedside unit will be considered as a subsystem of the surgical robotic system. The bedside unit may have a robot arm attached thereto. When attached to the bedside unit, the robot arm can also be considered, for the purposes of the present discussion, to be part of that subsystem. The robot arm may have an instrument or endoscope attached thereto. When attached to the arm, the instrument or endoscope can also be considered, for the purposes of the present discussion, to be part of that subsystem. It will be appreciated that the robot arm and instrument need not be part of the bedside unit subsystem.
A typical setup of a surgical robotic system 400 is illustrated in
Thus, the testing unit 502 can be operatively coupled to the robotic system 500 in a quick manner. Where testing is carried out when a surgical procedure is not being performed, being able to couple the testing unit 502 to the robotic system with minimal disruption can reduce the down time for which the robotic system is unable to perform a surgical procedure. Hence a maintenance check or fault diagnostic procedure can be carried out in an efficient manner. If a replacement is needed, for example because there is a fault with an instrument coupled to the robotic system, this can be done before the system is used for another procedure. This can potentially reduce a harmful interruption if the fault is detected, and a replacement carried out, only once another procedure has started. Where no replacement is needed, the testing unit 502 can be decoupled from the surgical system, enabling the surgical system to be ready for another procedure without needing to be connected back together.
Another approach is to couple the testing unit 502 to a subsystem of the surgical robotic system when that subsystem is decoupled from the remainder of the surgical robotic system. This approach is illustrated in
Suitably, the testing unit 502 is configured to couple to up to three bedside units at once, as illustrated in
The testing unit 502 is suitably also able to couple to the operator console 402 (as indicated by the dashed line in
The operator console, bedside unit and testing unit will now be further described with reference to
It will be appreciated that the above description of the operator console has focussed on selected elements of an operator console, for the purposes of understanding the present techniques. This description is not necessarily to be taken as a complete description of a practical implementation of such an operator console.
An example of a bedside unit 800 is illustrated in
The sensors 802 shown schematically in
The electrosurgical generator 814 is configured to provide power to an electrosurgical instrument such as a cauteriser. A particular power profile can be supplied by the electrosurgical generator 814 in response to control signals sent by the processor 816. The power provided by the electrosurgical generator can be coupled to the electrosurgical instrument (not shown).
The processor 816 is configured to receive sensor inputs from the sensors 802 and to provide drive signals to the actuators 808. The processor is configured to process the signals in accordance with a control system to effect appropriate control over portions of the bedside unit 800. The processor may operate in response to signals received from another subsystem such as the operator console. The processor may transmit signals to another subsystem such as the operator console.
Suitably one or more of the sensors 802, the actuators 808, the electrosurgical generator 814 and the processor 816 are coupled to the memory 820. This enables signals and/or other data to be saved to the memory and read from the memory.
The processor 816 couples to the transceiver 822, which facilitates transfer of signals generated by the bedside unit 800 to another subsystem. The transceiver also facilitates reception of signals from such other subsystems. The received signals may be processed at the bedside unit, for example at the processor 816.
It will be appreciated that the above description of the bedside unit 800 has focussed on selected elements of a bedside unit (where the robot arm and instrument coupled to the robot arm are considered part of the bedside unit), for the purposes of understanding the present techniques. This description is not necessarily to be taken as a complete description of a practical implementation of such a bedside unit.
An example of a testing unit 502 is illustrated in
The processor 900 is also suitably configured to process a signal received from an operator console and to generate appropriate signals in response, such as response signals characteristic of a response of a bedside unit (optionally including emulated sensor signals and/or actuator signals, and/or electrosurgical signals). The testing unit 502 is thus able to emulate one or more bedside units, for example when coupled to an operator console.
The processor 900 is coupled to the memory 902, the database 904 and the transceiver 906. The memory 902 permits the processor to store signals and data relating to the subsystem being emulated by the testing unit 502. The processor is able to access data stored in the memory 902. The database 904 comprises testing routines 912. The testing routines suitably relate to predetermined ways in which the testing unit is to test subsystems of the surgical robotic system, as is described in more detail elsewhere herein.
The transceiver 906 facilitates transfer of signals generated by the testing unit 502 to a subsystem under test. The transceiver 906 also facilitates reception of signals from such a subsystem. The received signals may be processed at the testing unit, for example at the processor 900.
It will be appreciated that the above description of the testing unit 502 has focussed on selected elements of a testing unit for the purposes of understanding the present techniques. This description is not necessarily to be taken as a complete description of a practical implementation of such a testing unit.
The testing unit 502 is useful when testing one or more subsystems of the surgical robotic system. The testing unit can couple to the operator console to enable testing of the output generated by the operator console and/or the response of the operator console to emulated signals generated in dependence on the operator console output signals. An example of a way in which this testing can be advantageous is now provided, but it will be understood that this is merely exemplary of many different ways in which a testing unit such as the one described herein can be used.
The operator console is typically used to drive the motion of surgical robotic arms and instruments that form part of the bedside units described herein. It may be desired to troubleshoot or test a new drive algorithm, or to identify the occurrence of a fault in an existing drive algorithm. Use of the testing unit 502 can enable the operator console to be tested without needing the bulkier bedside units to be provided during the test. The bedside units can therefore be used, in conjunction with a different operator console, to perform a surgical procedure, increasing the operational efficiency of the system as a whole. Further, a single testing unit can be used together with an operator console in place of multiple bedside units. This reduces the space requirements for the test, not only for the dimensions of the bedside units themselves, but also for the space needed to ensure arm clearances as the robot arms and instruments move in response to control signals output by the operator console.
Use of a testing unit can be particularly effective where collision avoidance is to be tested. Using bedside units with the operator console runs the risk of arm collisions occurring, which can damage the arms, requiring maintenance and possible replacement. Where the testing unit is used with the operator console in place of the bedside units, it can be determined from the testing unit whether or not an arm collision would have occurred.
Thus, the use of the testing unit can increase the efficiency and help reduce potential costs of testing procedures.
The testing unit can be used to recover the system efficiently after a fault, e.g. a collision, has occurred, for example during a surgical procedure. Such fault recovery can for example be achieved by using the testing unit to emulate data such as telemetry data from a portion of the system that may have experienced the fault. This emulated data can then be analysed, for example compared with data from the portion of the system that may have experienced the fault. The comparison of the emulated data (which could be data expected where no fault has occurred) with data from the potentially faulty system portion can help reveal whether the fault has caused any damage to occur and/or whether it remains safe to continue using the system as a whole or that portion of the system in particular. The comparison can comprise comparing characteristic values of the data. The comparison can comprise comparing signal profiles.
The testing unit may be configured to emulate data in accordance with a fault having occurred in the system portion being emulated. In this case, the testing unit may generate multiple data streams. Each data stream may be generated in accordance with a different fault, or different set of fault conditions, being emulated. For example, a first fault condition to be emulated can comprise a first type of collision (for example a collision of an arm with a tabletop). A second fault condition to be emulated can comprise a second type of collision (for example a collision between two arms). A third fault condition to be emulated can comprise an arm actuator becoming faulty. It will be appreciated that many other faults and so on can similarly be emulated, including combinations: for example a fourth fault condition to be emulated can comprise the first type of collision and an arm actuator becoming faulty.
The emulated data streams can be compared with the data obtained from the system portion under test. The comparison can help identify the fault or set of fault conditions that has occurred. For instance, the emulated data stream that most closely matches the obtained data (e.g. in accordance with known comparison metrics, for example overall signal profile, comparing predefined characteristics of the signal, and so on) can be identified and the fault condition or set of fault conditions associated with that emulated data stream can be identified as the fault condition or set of fault conditions that has occurred, or is most likely to have occurred. As above, the comparison can comprise comparing characteristic values of the data streams. The comparison can comprise comparing signal profiles.
It may not always be possible to correctly identify the fault condition in this way. However, the identification of a most likely fault condition can help save time in later analysis and maintenance tasks, so the testing unit can still provide a benefit.
An example will now be discussed in the context of a collision of an arm with another object. The testing unit can be coupled to the arm in question. The testing unit may analyse data from the arm, for example by comparing telemetry data from the arm with an expected signal, such as one generated at the testing unit itself, or accessible to the testing unit, to see whether the collision of the arm caused any mechanical damage to the arm or whether it is safe to continue using the arm and/or the system as a whole. The comparison may be carried out for example by comparing the force of impact of the collision (as determined from the arm telemetry data) to a threshold value (generated at or accessible to the testing unit). The analysis may be carried out by running a test on the arm (such as by driving it using the testing unit) and analysing the signals received from the actuators to ensure they are working correctly.
This approach of using the testing unit can increase efficiency by removing the need to replace a bedside unit that is not damaged and is still working well and is safe to use.
The testing unit can be used for design verification and/or specification testing. The testing unit is suitably able to test subsystems such as the operator console and bedside units to ensure that those subsystems operate in line with the design requirements. For example, to ensure that a response to a given emulated signals is in line with the design specification for that subsystem. The use of the testing unit enables an accurate review of the responses of those subsystems to be made, without necessitating careful control by a human operator of, for example, the input controllers of the operator console, and/or manipulation of robotic arms.
Aspects of the testing unit will now be further described.
The subsystem to which the testing unit is configured to couple (which might be the operator console or a bedside unit) is, as discussed elsewhere, able to generate a first signal having a first characteristic behaviour. The boundary of the characteristic behaviour suitably comprises a maximum signal value. The testing unit is configured to generate the emulated signal with a value greater than the maximum signal value.
The boundary of the characteristic behaviour may comprise a minimum signal value. The testing unit is configured to generate the emulated signal with a value less than the minimum signal value. Suitably, the testing unit is configured to generate the emulated signal over a range of values that encompasses a first range of values of the first signal. For example, where the subsystem under test is able to generate a signal with a range of values of [x, y], the testing unit is suitably able to generate the emulated signal with a range of values of [p, q], where (i) p<x; and/or (ii) q>y.
The boundary of the first characteristic behaviour may comprise a repeatability indication of the first signal. The repeatability indication is an indication of how repeatable a signal value is. The repeatability indication may comprise a standard deviation. The testing unit is configured to generate the emulated signal with a repeatability greater than the indicated repeatability. That is, the emulated signal value can be more stable than the first signal value. The increased signal stability can assist in more accurate testing procedures.
The boundary of the first characteristic behaviour may comprise a rate of change of values of the first signal. The testing unit is suitably configured to generate the emulated signal with a rate of change greater than the boundary rate of change. This can enable the subsystem to be ‘stress-tested’ by applying a greater rate of change than would be applied during standard operation of the surgical robotic system. This can enable the testing unit to test that the subsystem under test is able to appropriately respond at faster processing speeds than should be required during such standard operation.
The testing unit is suitably configured to generate the emulated signal with a rate of change less than the boundary rate of change. Thus, the testing unit can check that the subsystem under test is able to respond appropriately to more slowly time-varying signals. This may be used to test the response to signal drift over time, for example.
The testing unit is suitably configured to generate one or more emulated signals from a set of emulated signals, each emulated signal in the set of emulated signals being representative of a signal that can be generated by the first subsystem. The first subsystem is suitably configured to be operational in one of a group of modes. For example, there may be an operative control mode, in which the operator console is operatively coupled to drive a surgical robot arm and operate a surgical robotic instrument. There may also be a clutch mode, in which the operator console is configured such that operator inputs do not drive at least one instrument. Many other modes are possible. The set of emulated signals can correspond to the group of modes of the surgical robotic system. For example, one emulated signal of the set of emulated signals can correspond to the operative control mode. Another emulated signal of the set of emulated signals can correspond to the clutch mode. Selection of an emulated signal from the set of emulated signals can therefore be used to emulate a selective enable and/or disable of various of the control modes possible in the surgical robotic system.
The testing unit need not just couple to one subsystem of the surgical robotic system. In some implementations, the testing unit can couple to more than one subsystem. The different subsystems to which the testing unit is configured to couple need not be of the same type. For example, the testing unit can couple both to an operator console and to a bedside unit. Suitably, the testing unit is configured to emulate the second subsystem by generating a further emulated signal representative of a second signal of the second subsystem for receiving at the first subsystem, the second signal having a second characteristic behaviour. The further emulated signal suitably has an emulated behaviour that exceeds a further boundary of the second characteristic behaviour of the second signal, such that the testing unit is operable to test the first subsystem beyond the capability of the second subsystem. Suitably, the testing unit is configured to emulate the second subsystem by transmitting the generated further emulated signal for receiving at the first subsystem. The testing unit can further be configured to emulate the second subsystem by receiving a further response signal from the first subsystem indicative of the response of the first subsystem to the further emulated signal. The testing unit is suitably configured to compare the received further response signal with a further expected signal, and to determine a state of the first subsystem based on the comparison.
The emulated signal can be representative of an arm control signal, for example a signal that commands movement of a robot arm. The emulated signal can comprise one or more desired joint torques and/or speeds, for example of one or more joints of the robot arm.
The emulated signal can be representative of an instrument control signal, for example a signal that commands movement of an instrument. The instrument is suitably coupled to a surgical robot arm, and the instrument control signal can be for transmission to the instrument via the robot arm. The emulated signal can comprise one or more desired joint torques and/or speeds, for example of one or more joints of the instrument. The emulated signal can comprise a desired instrument state, for example the opening angle between a pair of jaws of a grasper tool. The emulated signal may comprise an electrosurgical signal, such as the electrical activation level of an electrosurgical tool. The electrical activation level may comprise a voltage to be applied to the tool, or a power level for the tool.
The emulated signal may comprise a desired range of movement of the arm and/or of the instrument.
The testing unit described herein may be provided as part of a surgical system. The surgical system may comprise a surgical robotic system having the first subsystem (e.g. an operator console or a bedside unit) configured to generate a first signal having a first characteristic behaviour, and a second subsystem (e.g. a bedside unit or an operator console) configured to receive the first signal and to respond to the received first signal. The surgical system may further comprise the surgical robotic testing unit.
A method of operating the testing unit will now be described with reference to
The testing unit receives a response signal, from the second subsystem, indicative of the response of the second subsystem to the emulated signal 1006. The testing unit analyses the received response signal, for example by comparing the received response signal with an expected signal 1008, and determines a state of the second subsystem based on the analysis, for example the comparison 1010. Thus, the testing unit is operable to test the second subsystem beyond the capability of the first subsystem.
The testing unit can comprise a stand-alone module. The testing unit may therefore be provided with the necessary processors and so on, and transceivers for communicating with the subsystems. The testing unit can comprise multiple modules which may be physically or conceptually separate. For example, a processing module may be coupled to a data storage and transmission module. In some examples, the testing unit comprises a computing device such as a laptop or tablet computer. The functionality of the testing unit as described herein may be provided across any one or more, or combination of two or more, of such modules.
Any of the processors or kinematics controllers herein described may be microprocessors, controllers or any other suitable type of processor for processing computer executable instructions. In some examples, for example where a system-on-a-chip architecture is used, the processors and/or kinematics controllers may include one or more fixed function blocks (also referred to as accelerators) which implement a part of the method described herein in hardware (rather than software or firmware). Platform software comprising an operating system or any other suitable platform software may be provided to enable application software, such as software implementing the method of
The computer executable instructions may be provided using any computer-readable media that is accessible by a computing-based device. Computer-readable media may include, for example, computer storage media such as a memory and communications media. Computer storage media (i.e. non-transitory machine-readable media), such as the memory, includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EPROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information for access by a computing-based device. In contrast, communication media may embody computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave, or other transport mechanism. As defined herein, computer storage media does not include communication media. Although the computer storage media (i.e. non-transitory machine-readable media, e.g. the memory) may be within the computing-based device, it will be appreciated that the storage may be distributed or located remotely and accessed via a network or other communication link (e.g. using a communication interface).
In the description above actions taken by the system have been split into functional blocks or modules for ease of explanation. In practice, two or more of these blocks could be architecturally combined. The functions could also be split into different functional blocks.
The present techniques have been described in the context of surgical robotic systems, though at least some features described are not limited to such systems, but may be applied more generally to robotic systems comprising various subsystem that communicate with one another.
Robotic systems can include manufacturing systems, such as vehicle manufacturing systems, parts handling systems, laboratory systems, and manipulators such as for hazardous materials or surgical manipulators.
The applicant hereby discloses in isolation each individual feature described herein and any combination of two or more such features, to the extent that such features or combinations are capable of being carried out based on the present specification as a whole in the light of the common general knowledge of a person skilled in the art, irrespective of whether such features or combinations of features solve any problems disclosed herein, and without limitation to the scope of the claims. The applicant indicates that aspects of the present invention may consist of any such individual feature or combination of features. In view of the foregoing description it will be evident to a person skilled in the art that various modifications may be made within the scope of the invention.
| Number | Date | Country | Kind |
|---|---|---|---|
| 2004739.5 | Mar 2020 | GB | national |
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/GB2021/050796 | 3/31/2021 | WO |
