System and methods for avoiding data collisions over a data bus

The disclosed system and methods involve controlling the timing and order in which numerous motors and sensors exchange data over a data bus. The method can be used with, for example, motion control, automotive, industrial automation, and medical equipment applications using data buses. As an example of one possible medical equipment application, the method of exchanging data on a bus can be used with a remote catheter guidance system. The disclosed system and methods help optimize data exchange over a bus and avoid collisions by grouping the transmission of sensor readings, by grouping the transmission of motor commands, and by predetermining the order of these groups. Further, the method provides a way of ensuring that incomplete data sets are not exchanged over the bus. The method also provides a way of synchronizing motor actuation based on data transmitted to the data bus.

BACKGROUND OF THE INVENTION

a. Field of the Invention

The present disclosure relates generally to a data bus collision avoidance system and methods that efficiently and effectively transmit data to and receive data from a data bus, and more particularly to a data bus system and methods that provide for the reliable exchange of data between components of a remote catheter guidance system.

b. Background Art

Many electrical, electronic and mechanical systems utilize components that cooperate or work together by exchanging data, often over a data bus. As these systems grow in complexity, the need to exchange this data orderly, efficiently, reliably, and predictably over the data bus increases. Often, the proper operation of these systems are dependent on the precise transmission of control commands and sensor information.

In particular, as medical systems progress to provide more control of instruments like catheters, so too must the means of communicating between components of those medical systems. Data buses are used to exchange data between multiple devices, which are connected to the data buses through nodes, which operably connect devices to the data bus.

In one type of medical procedure, a catheter is manipulated through a patient's vasculature to a patient's heart, and carries one or more electrodes which can be used for mapping, ablation, diagnosis, or other treatments. Once at the intended site, treatment can include ablation, cryoablation, lasers, chemicals, high-intensity focused ultrasound, etc. As readily apparent, such treatment requires precise control of the catheter during manipulation to, from, and at the treatment site. This can be accomplished by the effective and reliable transmission of data and return of sensor information.

Problematic data collisions occur when more than one node attempts to access the same node or physical media at the same time. The electrical signals from different nodes cannot coexist in the same physical media at the same time and remain intelligible. Collisions can cause missed input and output cycles, errors in transmitting data and reading data, and, in turn, unexpected system performance.

Many current solutions to the problem of bus collision involve attempts to re-transmit data through a number of retries. These solutions add overhead and delays in the system to achieve data transmission. Other solutions attempt to prioritize nodes in a hierarchy. These solutions unnecessarily complicate the system, make configuration and reconfiguration difficult, and add overhead—especially where the system needs to maintain priority directories on a dynamic basis.

The inventors herein have thus recognized a need for a data bus that can perform efficient yet accurate data exchange between the various components of a system.

BRIEF SUMMARY OF THE INVENTION

One advantage of the system and methods described, depicted, and claimed herein relate to the reliable and efficient exchange of data over a data bus in a system having multiple components.

The disclosure is directed to a data bus collision avoidance system and methods for controlling operations on a data bus used to transmit motor commands to and receive sensor readings from the components of a system. In particular, the data bus collision avoidance system and methods are described as used with a remote catheter guidance system. The system can include an electronic control system and a memory coupled to the electronic control system. Control logic is stored within the memory and is configured to be executed by the electronic control system. The electronic control system can control the transmission of motor commands to the data bus for further distribution to components such as motors ready to actuate upon those commands. The electronic control system can also control the transmission of sensor readings from components such as sensors.

In various embodiments, an input/output (IO) cycle on the data bus can involve motor operations, sensor operations, or both motor and sensor operations. In an embodiment involving motor operations, an electronic control system can provide motor commands to the data bus. Thereafter, a synchronization signal can prompt the motors to actuate upon these motor commands at the same time. This simultaneous actuation allows for coordinated motion, thereby reducing any possible erratic or semi-erratic motion from the motors. In an embodiment involving both motor and sensor operations, the data bus or a mechanism associated therewith can retrieve the sensor reading from each sensor one at a time after actuation of the motors. Once the data bus has received all of the sensor information or readings, the electronic control system or other components of the system can read the sensor information from the data bus. Further, since not every component needs to exchange data as frequently as others, more critical components can exchange data during IO cycles that recur more frequently. Less critical components can exchange data during IO cycles that recur less frequently. By providing order to the way in which data is exchanged, the reliability and efficiency of the data bus is improved.

DETAILED DESCRIPTION OF THE INVENTION

As described above, a data bus system and related methods are disclosed for providing more efficient and reliable exchange of data over a data bus and thereby reducing or eliminating data collisions or transmission errors. Such a data bus system and methods can be used in numerous applications that have need for the transmission of control commands and that receive sensor information. However, before proceeding to a detailed description of the data bus collision avoidance system, a brief overview, for context purposes, of an exemplary remote catheter guidance system (RCGS) for manipulating a medical device will first be described. The disclosed data bus system and methods are particularly applicable to such a system and the description of the RCGS will detail the need for efficient transmission of control commands and sensor information for a more effective use of the RCGS system. After the description of the RCGS, the present specification will then provide a description of the data bus technology and how it can be used in the RCGS.

Now referring to the drawings wherein like reference numerals are used to identify identical components in the various views,FIG. 1is a diagrammatic view of an exemplary RCGS10, in which several aspects of a system and methods for avoiding collisions of data on a data bus can be used.

Exemplary RCGS System Description. The RCGS10can be likened to power steering for a catheter system. The RCGS10can be used, for example, to manipulate the location and orientation of catheters and sheaths in a heart chamber or in another body cavity or lumen. The RCGS10thus provides the user with a similar type of control provided by a conventional manually-operated system, but allows for repeatable, precise, and dynamic movements. For example, a user such as an electrophysiologist can identify locations (potentially forming a path) on a rendered computer model of the cardiac anatomy. The system can be configured to relate those digitally selected points to positions within a patient's actual/physical anatomy, and can thereafter command and control the movement of the catheter to the defined positions. Once at the specified target position, either the user or the system can perform the desired diagnostic or therapeutic function. The RCGS10enables full robotic navigation/guidance and control.

As shown inFIG. 1, the RCGS10can generally include one or more monitors or displays12, a visualization, mapping and navigation (including localization) system14, a human input device and control system (referred to as “input control system”)100, an electronic control system200, a manipulator assembly300for operating a device cartridge400, and a manipulator support structure500for positioning the manipulator assembly300in proximity to a patient or a patient's bed.

Displays12are configured to visually present to a user information regarding patient anatomy, medical device location or the like, originating from a variety of different sources. Displays12can include (1) an ENSITE VELOCITY monitor16(coupled to system14—described more fully below) for displaying cardiac chamber geometries or models, displaying activation timing and voltage data to identify arrhythmias, and for facilitating guidance of catheter movement; (2) a fluoroscopy monitor18for displaying a real-time x-ray image or for assisting a physician with catheter movement; (3) an intra-cardiac echo (ICE) display20to provide further imaging; and (4) an EP recording system display22.

The system14is configured to provide many advanced features, such as visualization, mapping, navigation support and positioning (i.e., determine a position and orientation (P&O) of a sensor-equipped medical device, for example, a P&O of a distal tip portion of a catheter). Such functionality can be provided as part of a larger visualization, mapping and navigation system, for example, an ENSITE VELOCITY system running a version of NavX software commercially available from St. Jude Medical, Inc., of St. Paul, Minn. and as also seen generally by reference to U.S. Pat. No. 7,263,397 entitled “METHOD AND APPARATUS FOR CATHETER NAVIGATION AND LOCATION AND MAPPING IN THE HEART” to Hauck et al., owned by the common assignee of the present disclosure, and hereby incorporated by reference in its entirety. System14can comprise conventional apparatus known generally in the art, for example, the ENSITE VELOCITY system described above or other known technologies for locating/navigating a catheter in space (and for visualization), including for example, the CARTO visualization and location system of Biosense Webster, Inc., (e.g., as exemplified by U.S. Pat. No. 6,690,963 entitled “SYSTEM FOR DETERMINING THE LOCATION AND ORIENTATION OF AN INVASIVE MEDICAL INSTRUMENT” hereby incorporated by reference in its entirety), the AURORA® system of Northern Digital Inc., a magnetic field based localization system such as the gMPS system based on technology from MediGuide Ltd. of Haifa, Israel and now owned by St. Jude Medical, Inc. (e.g., as exemplified by U.S. Pat. Nos. 7,386,339, 7,197,354 and 6,233,476, all of which are hereby incorporated by reference in their entireties) or a hybrid magnetic field-impedance based system, such as the CARTO 3 visualization and location system of Biosense Webster, Inc. (e.g., as exemplified by U.S. Pat. Nos. 7,536,218, and 7,848,789 both of which are hereby incorporated by reference in its entirety). Some of the localization, navigation and/or visualization systems can involve providing a sensor for producing signals indicative of catheter location and/or orientation information, and can include, for example one or more electrodes in the case of an impedance-based localization system such as the ENSITE VELOCITY system running NavX software, which electrodes can already exist in some instances, or alternatively, one or more coils (i.e., wire windings) configured to detect one or more characteristics of a low-strength magnetic field, for example, in the case of a magnetic-field based localization system such as the gMPS system using technology from MediGuide Ltd. described above.

The input control system100, which can include a joystick110for allowing a user to control a catheter, is configured to allow a user, such as an electrophysiologist, to interact with the RCGS10, in order to control the movement and advancement/withdrawal of both a catheter and sheath (see, e.g., commonly assigned U.S. patent application Ser. No. 12/751,843 filed Mar. 31, 2010 entitled “ROBOTIC CATHETER SYSTEM” and PCT/US2009/038597 entitled “ROBOTIC CATHETER SYSTEM WITH DYNAMIC RESPONSE”, published as WO 2009/120982; the entire disclosure of both applications being hereby incorporated by reference). Generally, several types of input devices and related controls can be employed, including, without limitation, instrumented traditional catheter handle controls, oversized catheter models, instrumented user-wearable gloves, touch screen display monitors, 2-D input devices, 3-D input devices, spatially detected styluses, and traditional joysticks. For a further description of exemplary input apparatus and related controls, see, for example, commonly assigned U.S. patent application Ser. No. 12/933,063 entitled “ROBOTIC CATHETER SYSTEM INPUT DEVICE” and U.S. patent application Ser. No. 12/347,442 entitled “MODEL CATHETER INPUT DEVICE”, the entire disclosure of both applications being hereby incorporated by reference. The input devices can be configured to directly control the movement of the catheter and sheath, or can be configured, for example, to manipulate a target or cursor on an associated display.

The electronic control system200is configured to translate (i.e., interpret) inputs (e.g., motions) of the user at an input device or from another source into a resulting movement of the catheter and/or surrounding sheath. In this regard, the system200includes a programmed electronic control unit (ECU) in communication with a memory or other computer readable media (memory) suitable for information storage. Relevant to the present disclosure, the electronic control system200is configured, among other things, to issue commands (i.e., actuation control signals) to the manipulator assembly300(i.e., to the actuation units—electric motors) to move or bend the catheter and/or sheath to prescribed positions and/or in prescribed ways, all in accordance with the received user input and a predetermined operating strategy programmed into the system200. In addition to the instant description, further details of a programmed electronic control system can be found in commonly assigned U.S. patent application Ser. No. 12/751,843 filed Mar. 31, 2010 entitled “ROBOTIC CATHETER SYSTEM”, described above. It should be understood that although the exemplary ENSITE VELOCITY system14and the electronic control system200are shown separately, integration of one or more computing functions can result in a system including an ECU on which can be run both (i) various control and diagnostic logic pertaining to the RCGS10and (ii) the visualization, mapping and navigation functionality of system14.

The manipulator assembly300, in response to such commands, is configured to maneuver the medical device (e.g., translation movement, such as advancement and withdrawal of the catheter and/or sheath), as well as to effectuate distal end (tip) deflection and/or rotation or virtual rotation. In an embodiment, the manipulator assembly300can include actuation mechanisms/units (e.g., a plurality of electric motor and lead screw combinations, or other electric motor configurations, as detailed below) for linearly actuating one or more control members (e.g., steering wires) associated with the medical device for achieving the above-described translation, deflection and/or rotation (or virtual rotation). In addition to the description set forth herein, further details of a manipulator assembly can be found in commonly assigned U.S. patent application Ser. No. 12/347,826 titled “ROBOTIC CATHETER MANIPULATOR ASSEMBLY”, the entire disclosure of which is hereby incorporated by reference.

A device cartridge400is provided for each medical device controlled by the RCGS10. For this exemplary description of an RCGS, one cartridge is associated with a catheter and a second cartridge is associated with an outer sheath. The cartridge is then coupled, generally speaking, to the RCGS10for subsequent robotically-controlled movement. In addition to the description set forth herein, further details of a device cartridge can be found in commonly owned U.S. patent application Ser. No. 12/347,835 entitled “ROBOTIC CATHETER DEVICE CARTRIDGE” and U.S. patent application Ser. No. 12/347,842 “ROBOTIC CATHETER ROTATABLE DEVICE CARTRIDGE”, the entire disclosure of both applications being hereby incorporated by reference.

FIG. 2is a side view of an exemplary robotic catheter manipulator support structure, designated structure510(see commonly owned U.S. patent application Ser. No. 12/347,811 entitled “ROBOTIC CATHETER SYSTEM” described above). The structure510can generally include a support frame512including retractable wheels514and attachment assembly516for attachment to an operating bed (not shown). A plurality of support linkages520can be provided for accurately positioning one or more manipulator assemblies, such as manipulator assembly302. The assembly302is configured to serve as the interface for the mechanical control of the movements or actions of one or more device cartridges, such as catheter and sheath cartridges402,404described below. Each device cartridge is configured to receive and retain a respective proximal end of an associated medical device (e.g., catheter or sheath). The assembly302also includes a plurality of manipulation bases onto which the device cartridges are mounted. After mounting, the manipulator assembly302, through the manipulation bases, is capable of manipulating the attached catheter and sheath.

In the Figures to follow,FIGS. 3a-3bwill show a manipulator assembly,FIGS. 4a-4cwill show a manipulation base, andFIGS. 5a-5bwill show a device cartridge.

FIG. 3ais an isometric view, with portions omitted for clarity, of manipulator assembly302. Assembly302includes a catheter manipulator mechanism304, a sheath manipulator mechanism306, a catheter manipulation base308, a sheath manipulation base310, a first (catheter) drive mechanism312, a second (sheath) drive mechanism314, and a track356. As further shown, assembly302further includes a catheter cartridge402and a sheath cartridge404, with a catheter406having a proximal end opening408coupled to the catheter cartridge402and a sheath410coupled to the sheath cartridge404.

Catheter and sheath manipulator mechanisms304,306are configured to manipulate the several different movements of the catheter406and the sheath410. First, each mechanism304,306is configured to impart translation movement to the catheter406and the sheath410. Translation movement here refers to the independent advancement and retraction (withdrawal) as shown generally in the directions designated D1and D2inFIG. 3a. Second, each mechanism304,306is also configured to effect deflection of the distal end of either or both of the catheter and sheath406,410. Third, each mechanism304,306can be operative to effect a so-called virtual (omni-directional) rotation of the distal end portion of the catheter406and the sheath410. Virtual rotation, for example, can be made through the use of independent four-wire steering control for each device (e.g., eight total steering wires, comprising four sheath control wires and four catheter control wires). The distal end movement is referred to as “virtual” rotation because the outer surface of the sheath (or catheter) does not in fact rotate in the conventional sense (i.e., about a longitudinal axis) but rather achieves the same movements as conventional uni-planar deflection coupled with axial rotation. In addition to the present description of virtual rotation, further details can be found in PCT/US2009/038597 entitled “ROBOTIC CATHETER SYSTEM WITH DYNAMIC RESPONSE”, published as WO 2009/120982.

Each manipulator mechanism304,306further includes a respective manipulation base308,310onto which are received catheter and sheath cartridges402,404. Each interlocking base308,310can be capable of travel in the longitudinal direction of the catheter/sheath (i.e., D1, D2respectively) along a track356. In an embodiment, D1and D2can each represent a translation of approximately 8 linear inches. Each interlocking base308,310can be translated by a respective high precision drive mechanism312,314. Such drive mechanisms can include, for example and without limitation, an electric motor driven lead screw or ball screw.

The manipulator mechanisms304,306are aligned with each other such that catheter406can pass through sheath410in a coaxial arrangement. Thus, sheath410can include a water-tight proximal sheath opening408. Overall, the manipulator mechanisms304,306are configured to allow not only coordinated movement but also relative movement between catheter and sheath cartridges402,404(and thus relative movement between catheter and sheath).

FIG. 3bis an isometric view of manipulator assembly302, substantially the same asFIG. 3aexcept that catheter and sheath cartridges402,404are omitted (as well as catheter and sheath406,410) so as to reveal an exposed face of the manipulation bases308,310.

FIG. 4ais an isometric, enlarged view showing manipulation base308(and base310) in greater detail. Each cartridge402,404has an associated manipulation base308,310. Each base308,310can include a plurality of fingers316,318,320and322(e.g., one per steering wire) that extend or protrude upwardly to contact and interact with steering wire slider blocks (i.e., such as slider blocks412,414,416,418are best shown inFIG. 5b) to independently tension select steering wires420,422,424,426(also best shown inFIG. 5b). Each finger can be configured to be independently actuated (i.e., moved back and forth within the oval slots depicted inFIG. 4a) by a respective precision drive mechanism, such as a motor driven ball screw324. A plate326provides a surface onto which one of the cartridges402,404are seated.

FIG. 4bis an isometric, enlarged view of base308(and base310), substantially the same asFIG. 4aexcept with plate326omitted. Each motor-driven ball screw324(best shown inFIG. 4a, i.e., for both finger control and for cartridge translation control, can further include encoders to measure a relative and/or an absolute position of each element of the system. Moreover, each motor-driven ball screw324(i.e., for both finger control and cartridge translation control) can be outfitted with steering wire force sensors to measure a corresponding steering wire tension. For example, a corresponding finger316,318,320or322can be mounted adjacent to a strain gauge for measuring the corresponding steering wire tension. Each motor-driven ball screw324can include a number of components, for example only, a rotary electric motor (e.g., motors342,344,346and348), a lead screw328, a bearing330and a coupler332mounted relative to and engaging a frame340. In the depicted embodiments linear actuation is primarily, if not exclusively, employed. However, some known examples of systems with rotary-based device drivers include U.S. application Ser. No. 12/150,110, filed 23 Apr. 2008 (the '110 application); and U.S. application Ser. No. 12/032,639, filed 15 Feb. 2008 (the '639 application). The '110 application and the '639 application are hereby incorporated by reference in their entirety as though fully set forth herein. These and other types of remote actuation can directly benefit from the teaching of the instant disclosure.

FIG. 4cis an isometric, enlarged view of base308(and base310) that is taken from an opposite side as compared toFIGS. 4a-4b. Bases308,310can include components such as a plurality of electrically-operated motors342,344,346and348, respectively coupled to fingers316,318,320and322. A bearing354can be provided to facilitate the sliding of bases308,310on and along track356. A plurality of inductive sensors (e.g. home sensors)358can also be provided for guiding each manipulation base to a home position.

FIG. 5ais an isometric, enlarged view showing, in greater detail, sheath cartridge404. It should be understood that the description of sheath cartridge404, except as otherwise stated, applies equally to catheter cartridge402. Catheter406and sheath410can be substantially connected or affixed to respective cartridges402,404(e.g., in the neck portion). Thus, advancement of cartridge404correspondingly advances the sheath410and retraction of cartridge404retracts the sheath410. Likewise, although not shown, advancement of cartridge402correspondingly advances catheter406while a retraction of cartridge402retracts catheter406. As shown, sheath cartridge404includes upper and lower cartridge sections428,430.

FIG. 5bis an isometric, enlarged view showing, in greater detail, sheath cartridge404, with upper section428omitted to reveal interior components. Cartridge404can include slider blocks (e.g., as shown for cartridge404, slider blocks412,414,416,418), each rigidly and independently coupled to a respective one of a plurality of steering wires (e.g., sheath steering wires420,422,424,426) in a manner that permits independent tensioning of each steering wire. Likewise, cartridge402for catheter406also includes slider blocks for coupling to a plurality (i.e., four) steering wires. Device cartridges402,404can be provided as a disposable item that is capable of being easily positioned (e.g., snapped) into place (i.e., onto a respective base408,410). Sheath cartridge404can be designed in a similar manner as the catheter cartridge402, but will typically be configured to provide for the passage of catheter406.

Referring toFIGS. 4aand5a, catheter and sheath cartridges402,404are configured to be secured or locked down onto respective manipulation bases308,310. To couple cartridge402(and404) with base308(and310), one or more locking pins (e.g.,432inFIG. 5a) on the cartridge can engage one or more mating recesses360in the base (seeFIG. 4a). In an embodiment, such recesses360can include an interference lock such as a spring detent or other locking means. In an embodiment, such other locking means can include a physical interference that can require affirmative/positive action by the user to release the cartridge. Such action can include or require actuation of a release lever362. Additionally, the cartridge can include one or more locator pins (not shown) configured to passively fit into mating holes on the base (e.g.,364inFIG. 4a).

In operation, a user first manually positions catheter406and sheath410(with catheter406inserted in sheath410) within the vasculature of a patient. Once the medical devices are roughly positioned in relation to the heart or other anatomical site of interest, the user can then engage or connect (e.g., “snap-in”) the catheter and sheath cartridges into place on respective bases308,310. When a cartridge is interconnected with a base, the fingers fit into the recesses formed in the slider blocks. For example, with respect to the sheath cartridge404and sheath base310, each of the plurality of fingers316,318,320or322fit into corresponding recesses formed between the distal edge of slider blocks412,414,416,418and a lower portion of the cartridge housing (best shown inFIG. 5b). Each finger can be designed to be actuated in a proximal direction to respectively move each slider block, thereby placing the respective steering wire in tension (i.e., a “pull” wire). Translation, distal end bending and virtual rotation can be accomplished through the use of the RCGS10.

FIG. 6is a diagrammatic view of a node suitable for connection to a communications or data bus700in the RCGS10. The node includes an actuation unit600, similar to the actuation mechanisms described above (e.g., catheter actuation mechanism304). The RCGS10can have at least ten such actuation units (i.e., one for each of the four catheter steering wires, four sheath steering wires, one catheter manipulation base and one sheath manipulation base), which as described include electric motors. Operations on the data bus700used to transmit data to and receive data from the actuation unit600are scheduled so that the actuation unit600can exchange data reliably and predictably.

FIG. 6shows in diagrammatic or block form many of the components described above—where appropriate, references to the earlier describe components will be made. Actuation unit600includes a first, slidable control member602(i.e., slider as described above) that is connected to or coupled with a second, tensile control member604(i.e., steering wire as described above). The slider602can be configured to interface with a third, movable control member606(i.e., finger as described above). The finger606can further be operatively coupled with a portion of a sensor608(e.g., a force sensor), which, in turn, can be coupled with a translatable drive element610that can be mechanically moved. For example, without limitation, translatable drive element610can ride on or can otherwise be mechanically moved by a mechanical movement device612that, in turn, can be coupled with an electric motor614. The mechanical movement device612can comprise a lead screw while the translatable drive element610can comprise a threaded nut, which can be controllably translated by screw612in the X+ or X− directions. In another embodiment, mechanical movement device612can include a ball screw, while translatable drive element610can include a ball assembly. Many variations are possible, as will be appreciated by one of ordinary skill in the art.

The actuation unit600can also include a rotary motor position encoder616that is coupled to the motor614and is configured to produce a signal indicative of the position of the motor614. The encoder616can comprise an internal, optical encoder assembly, integral with motor614, configured to produce a relatively high accuracy signal. The motor position sensor can operate in either absolute or relative coordinates. In an embodiment, a second motor position sensor (not shown) can also be provided, such as a potentiometer (or impedance-based), configured to provide a varying voltage signal proportional to the motor's rotary position. The signal of the secondary position sensor can be used as an integrity check of the operating performance of the primary position sensor (encoder) during start-up or initialization of the actuation unit.

Actuation unit600can also include one or more local controllers including a bus interface618to facilitate exchange of information between actuation unit600and electronic control system200or the ECU via the data bus700. The local controller communicates with the main electronic control system200via the bus interface and is configured, among other things, to (1) receive and execute motor actuation commands issued by the electronic control system200for controlling the movements of motor614; and (2) receive and execute a command (issued by the electronic control system200) to take a motor position sensor reading, for example, from encoder616and subsequently report the reading to system200.

Data Bus Collision Avoidance in the RCGS Environment. Although motors, sensors, actuation units, cartridges, and various other components have been described with some detail, such descriptions serve merely to provide an environment in which to describe a system and methods for operating the data bus700, as shown inFIG. 7.

It is contemplated that the data bus700can exchange data between many or even all components and subcomponents of a system that produce input data for or receive output data from an electronic control system. One example of such a component is the actuation unit600, as shown inFIG. 6, which has several subcomponents. The data bus700can exchange data (i.e., both transmit data and receive data) in a system that includes many mechanical, electrical, electromechanical, and computer-based components. While components producing input data or receiving output data can conceivably include a vast array of components, for sake of simplicity, the following description refers to such components simply in terms of “motors” (requiring output) and “sensors” (producing input).

For a system with many components to function properly, its components must be capable of exchanging data predictably, reliably, and efficiently between and amongst one another. Therefore, the components of a system can transmit and receive data in a controlled manner by way of the data bus700. Examples of the types of data that a system can exchange over the data bus700can include without limitation motor commands such as position, velocity, or acceleration; error conditions; sensor readings; and various other inputs and outputs.

In one embodiment, the system utilizing the data bus700can be the RCGS10. As part of the RCGS10, the electronic control system200can transmit motor commands to a plurality of motors710of the RCGS10over the data bus700. The electronic control system200can also receive sensor readings from a plurality of sensors720of the RCGS10over the data bus700. Still further, the electronic control system200can exchange data with the human input device and control system100, which can include the joystick110for receiving input from a user. The electronic control system200, described in more detail above, can include, for example, a bus controller730, computer readable media740, an ECU750, and a processor760. Since the electronic control system200controls the movement of the catheter and/or surrounding sheath, it follows that the electronic control system200can be configured to compute motor commands and receive and process sensor readings.

Various motors, such as the motor614of the actuation unit600, can receive motor commands from the electronic control system200via the data bus700. One exemplary motor command that can be transmitted over the data bus700can involve the catheter and sheath manipulator mechanisms304,306imparting translational movement to the catheter406and the sheath410. Also, various sensors of the RCGS10can transmit sensor readings back to the electronic control system200over the data bus700. An exemplary sensor reading can include a strain gauge measuring steering wire tension. Another exemplary sensor reading can involve the encoder616measuring the position of the motor614inFIG. 6.

In some embodiments, it is contemplated that the electronic control system200computes the motor commands at least in part in response to the sensor readings. In other words, the sensor readings can serve as a form of closed-loop feedback for the RCGS10. For example, if the encoder616measures that the motor614is not in its expected position, the electronic control system200can use this information to generate a motor command that compensates for this discrepancy. During the next cycle that the motor614is scheduled to receive a motor command, the electronic control system200can provide the motor614with the compensatory motor command.

Generally, motors and sensors can be operably connected to the data bus700at representative nodes, such as that shown by the actuation unit600inFIG. 6. More specifically, motors and sensors can interface with the data bus700by way of a bus interface, such as the bus interface618shown inFIG. 6. The bus interface618can be configured to fetch data from the data bus700, typically through some device driver. The bus interface618can also be configured to perform sampling of input data periodically. As shown and described, a node can be configured to accommodate the data exchange for more than one component or subcomponent, such as an encoder sensor and a motor. Moreover, nodes can include components and subcomponents other than those shown inFIG. 6. For example, nodes can have an associated local memory, or more generally, a local “buffer,” in which data values are stored, in some cases, temporarily. In some embodiments, there can be a local buffer for each motor or sensor of a node. In other embodiments, there can be a shared local buffer. In yet other embodiments, the bus interfaces can contain the local buffer(s). In still further embodiments, the local buffer can even be at or on the data bus700. In other embodiments, however, a local buffer is not necessary.

One aspect of the data bus700can involve broadcasting. A component node operably connected to the data bus700can transmit or “broadcast” data to more than one or even all other nodes connected to the data bus700. For example, the electronic control system200or the bus controller730can broadcast a startup message system-wide, that is, to all of the nodes connected to the data bus700. However, nodes can be tuned to “listen” only to the transmissions of certain other nodes. For example, the motors of the RCGS10that control the steering wires can be tuned to listen only to the node or nodes corresponding to the electronic control system200. Thus the motors would not listen to data transmissions directly from the sensors of RCGS10. On the other hand, the electronic control system200can be tuned to listen to the input from the sensors of the RCGS10.

Generally, the bus controller730can be responsible for overseeing the operations of the data bus700. More specifically, the bus controller730can include at least one program, algorithm, control logic, memory, and/or the like for scheduling, timing, and/or coordinating access to the data bus700. The processor760of the electronic control system200can execute a program or the like of the bus controller730. In one embodiment, the bus controller730can be based on a standard called CANopen. CANopen relates to the application layer of the OSI/ISO layer model, and one objective of CANopen is to control how data buses exchange real-time process data. In another exemplary embodiment, the bus controller730can be based on a general purpose input output (GPIO) standard. In yet other embodiments, the bus controller730can be based on a serial peripheral interface (SPI) bus standard. Furthermore, as shown in FIG.7, the bus controller730can be part of the electronic control system200in one embodiment. In another embodiment, however, the bus controller730can be separate and distinct from the electronic control system200.

To optimize usage of the data bus700and to minimize bus traffic, the bus controller730can be programmed to schedule data exchanges on the data bus700in predetermined sequences of input/output (IO) cycles. An IO cycle can involve transmitting over the data bus700at least one motor command to at least one motor and actuating the motor(s) based on the motor command(s). These events can be referred to collectively as motor “operations.” On the other hand, an IO cycle can involve receiving, retrieving, obtaining, sampling, acquiring, or otherwise collecting at least one sensor reading from at least one sensor and transmitting over the data bus700the sensor reading(s) to the electronic control system200and other interested components. These events can be referred to collectively as sensor “operations.” Further, an IO cycle can involve performing both motor operations and sensor operations.

As shown by the exemplary bus access timeline inFIG. 8, the bus controller730can be programmed to schedule IO cycles in predetermined sequences. IO cycles can recur at different frequencies such that some IO cycles can have a shorter cycle period than other IO cycles. Moreover, IO cycles can have different cycle durations such that some IO cycles take longer to complete than other IO cycles. For example, IO cycle-A800inFIG. 8has a cycle period of 40 milliseconds and a cycle duration of 20 milliseconds. This means that IO cycle-A800performs its list (or “thread”) of operations when a cycle timer specific to IO cycle-A800expires every 40 milliseconds. This also means that IO cycle-A is allotted 20 milliseconds of bus access time to complete its thread of operations. The cycle timer for each IO cycle can be defined when the bus controller730is programmed. IO cycle-B810, on the other hand, has a cycle period of 20 milliseconds and a cycle duration of 10 milliseconds. This means that IO cycle-B810recurs every 20 milliseconds and is allotted 10 milliseconds of bus access time to complete its thread of operations. Further, IO cycle-C820has a cycle period of 50 milliseconds and a cycle duration of 10 milliseconds to complete its thread of operations.

It should be noted thatFIG. 8is merely exemplary. The RCGS10can have more or considerably more than three IO cycles, some of which can have IO cycle periods in the range of one or more seconds. Moreover, IO cycle periods and IO cycle durations need not be in 10 millisecond increments. AlthoughFIG. 8shows some instances where multiple IO cycles start performing operations at the same time, such as between 0-10, 40-50, and 80-90 milliseconds, there can be some instances where multiple IO cycles do not start at the same time. For example, one IO cycle can be halfway completed when another IO cycle is scheduled to begin.

Components of the RCGS10that produce input data or receive output data (IO components) can be assigned to the thread of a specific IO cycle based on need for data in the RCGS10. Need for data can involve determining the frequency with which each IO component should have access to the data bus700. Hence critical components, which have a high need for data or that produce data for which the electronic control system200has a high need, can be assigned to IO cycles that recur more frequently. This would allow more critical components to perform operations via the data bus700more frequently than less critical components. Also, it can be advantageous in some embodiments to group and assign motors performing similar functions to the same IO cycle. Likewise, it can be advantageous to group and assign sensors measuring similar attributes of the RCGS10to the same IO cycle.

One example of a critical component is the motor614shown inFIG. 6, which ultimately controls the steering wire604. The motor614could be assigned to IO cycle-B810, which has a relatively short cycle period of 20 milliseconds. Another example of a critical component that deserves frequent data exchange can be sensors instrumented throughout the human input device and control system100. Some of these sensors can measure the deflection of the joystick110caused by a user desiring to manipulate the catheter406. These sensor readings provide input to the electronic control system200, which in turn computes motor commands based on those sensor readings. By contrast, a less critical component, such as a motor driving a fan blowing air over the electronic control system200, could be assigned to an IO cycle that only recurs once every second.

IO cycles can communicate with the data bus700at mutually exclusive points in time. However, as mentioned above, instances can occur in which more than one IO cycle requires common access to the data bus700.FIG. 8shows several of these instances at time periods represented at 0-10, 40-50, 80-90, 120-140, and 160-170 milliseconds, and so on. Yet before an IO cycle can perform its thread of IO operations, it must acquire “mutex” (based on principles of mutual exclusion) to write to and read from a buffer of the data bus700. One way to reduce instances where different IO cycles are competing for mutex is by predetermining and spreading out the bus load, which is the general amount of activity occurring on the data bus700at any given time. Furthermore, through iterative programming of the bus controller730and testing of the RCGS10and the data bus700, these instances can be minimized or even eliminated completely if desired.

Where these instances of competition for mutex are not eliminated completely, several techniques can be used to help ensure that data is still exchanged reliably and efficiently over the data bus700. First, where two IO cycles desire mutex starting at the same time, the bus controller730can utilize a principle of priority inheritance mutex. Priority inheritance mutex means that the IO cycle with the higher priority will acquire mutex first, enabling the higher priority IO cycle to perform its operations first. One way for the bus controller730to determine priority is based on the cycle period of the IO cycle. Hence the IO cycle-B810inFIG. 8would have priority over IO cycle-A800and IO cycle-C820since IO cycle-B810has the shortest cycle period (i.e., 20 milliseconds). Second, once a high priority IO cycle has acquired mutex and is performing operations on the data bus700, the bus controller730can lock out or block lower priority IO cycles from using the data bus700. Third, another scenario is presented where a lower priority IO cycle has mutex and is performing its operations when a higher priority IO cycle requests access to the data bus700. Here, instead of suspending the lower priority IO cycle, the RCGS10can allocate more system resources to accelerate performance of the lower priority IO cycle. In turn, this still provides the higher priority IO cycle with prompt access to the data bus700.

The IO cycle(s) is terminated at the end of its cycle duration regardless of whether the entire thread of operations are completed during an IO cycle and regardless of whether all IO cycles are able to access the data bus700during a given time period. IO cycles are terminated at the end of their cycle durations because the predetermined sequence for bus access time must continue. As a result, the electronic control system200can be left to compensate for the effects of any missed IO cycles. As a preventative measure, though, during testing of the data bus700with a particular system, it can be determined whether the system can tolerate certain operations that are missed on occasion. If the system can tolerate these missed operations, then the bus controller730need not be reprogrammed. If the system cannot tolerate these missed operations, the bus controller730can be reprogrammed such that these operations are not missed.

In addition to providing order to the sequence of IO cycles, the bus controller730can also provide order to the operations performed within IO cycles. Providing order within the IO cycle can help reduce collisions and the duration of IO cycles.

FIG. 9shows several examples of how the bus controller730can provide order within IO cycles. One example of how the bus controller730can provide order within an IO cycle pertains to IO cycles900involving both motor and sensor operations. In such an IO cycle900, the bus controller730can be programmed so that motor operations are grouped together and performed during a motor time interval910that occurs before a sensor time interval920for performing sensor operations. Sensor operations can be grouped separately from motor operations, and sensor operations can be performed in the sensor time interval920occurring after the motor time interval910. In the context of the RCGS10, IO cycle900can be explained as data flowing from the electronic control system200to a group of motors during motor time interval910, and then from a group of sensors to the electronic control system200during the sensor time interval920.

It is important to note several aspects aboutFIG. 9. First, the group of motors and the group of sensors referred to above consist, respectively, of those motors and of those sensors that are scheduled to exchange data during this particular IO cycle900. Second, the bus controller730could also be programmed so that sensor operations occur before motor operations. However, one benefit to performing motor operations first is evident in an emergency condition where one or more motors needs to be stopped as soon as possible. Third, although IO cycle900is shown to involve both motor operations and sensor operations, IO cycles can also involve solely motor operations or solely sensor operations. Lastly, the exemplary IO cycle900and its intervals and subintervals will be referred to throughout this disclosure.

Another example of how the bus controller730can provide order within an IO cycle is by grouping data writes and grouping data reads separately within time intervals, such as motor time interval910and sensor time interval920. For example, as shown inFIG. 8, the bus controller730can allocate bus access time for all motor commands to be written from the electronic control system200to the data bus700during an initial motor time subinterval930. As will be described below, the motors can quasi-simultaneously read and actuate upon the motor commands during a subsequent motor time subinterval940. Similarly, the bus controller730can allocate bus access time for sensor readings to be written to the data bus700during a preliminary sensor time subinterval950. Thereafter, the electronic control system200and other interested components can read these sensor readings during a latter sensor time subinterval960.

It can be advantageous for the bus controller730to coordinate motors of the RCGS10to actuate based on motor commands at the same time. For example, the RCGS10can have ten actuation units with each unit having a motor for independently controlling a steering wire of the catheter406. If the ten motors are actuated at different times, movement of the catheter406can be relatively sporadic. Thus one skilled in the art will understand the advantages of actuating all ten motors simultaneously or quasi-simultaneously.

One way for the bus controller730to achieve coordinated actuation is to broadcast a synchronization signal to a group of motor nodes connected to the data bus700during IO cycles that involve motor time intervals. To illustrate, with continued reference to the exemplary IO cycle900inFIG. 9, the electronic control system can write at least one motor command to the data bus700during the initial motor time subinterval930. Also during this initial motor time subinterval930, the data bus700can distribute motor commands from the electronic control system200to a local buffer associated with each motor node. The motor nodes can be from a group of motors that are scheduled to actuate in this IO cycle900. Thereafter, the bus controller730can broadcast a synchronization signal970to the group of motor nodes that are scheduled to actuate during this particular IO cycle900. The synchronization signal970can indicate the beginning of the subsequent motor time subinterval940in which the group of motors are to actuate. In an alternative embodiment, the expiration of a synchronization timer within IO cycle900can signal the beginning of the subsequent motor time subinterval940. In immediate response to either the synchronization signal or the expiration of the synchronization timer, the motors read the motor command stored in their respective local buffers and actuate simultaneously or quasi-simultaneously. In this way, the data bus700in effect “releases” all motor commands to the motors at the same time, allowing for coordinated actuation. In effect, the receipt of a synchronization signal controls the moment when motors interact with the process environment of the RCGS10.

It should be noted that if the data bus700is “active,” the data bus700can be capable of distributing motor commands, sensor readings, and the like without any preconfigured mapping or routing scheme between connected nodes. However, if the data bus700is “passive,” the data bus700can be preconfigured to “distribute” motor commands, sensor readings, and the like according to a routing or mapping scheme.

One embodiment of the motor time interval910that facilitates quasi-simultaneous motor actuation is shown in more detail inFIG. 10. As with all timelines in the figures,FIG. 10is not drawn to scale. During the initial motor time subinterval930, the electronic control system200can transmit to the data bus700motor commands1010,1012, and1014for three motors acting as constituents of a group of motors scheduled to perform operations during this IO cycle. The data bus700can further distribute these motor commands1010,1012, and1014to local buffers1020,1022, and1024of motors1030,1032, and1034. During the subsequent motor time subinterval940, which can in one embodiment be triggered by the bus controller730broadcasting a synchronization signal970, the motors1030,1032, and1034can actuate upon the motor commands1010,1012, and1014at the same time. Although the subsequent motor time subinterval940is depicted as a period of time during which the motors1030,1032, and1034can actuate, the motors1030,1032, and1034together actuate in immediate response to the synchronization signal970.

The data bus700can receive sensor readings in several different ways during the sensor time intervals920. In one embodiment where the bus controller730is based on CANopen, the bus controller730can write requests for sensor readings to a group of sensor nodes scheduled to report data in a particular IO cycle. In response, the sensor nodes can write the sensor readings to the data bus700. Thereafter, the electronic control system200and other components interested in the sensor readings can read the sensor readings from the data bus700. In another embodiment where the bus controller730is based on a GPIO, the bus controller730or other bus interface mechanisms can write sensor readings from a group of sensor nodes to the data bus700at every recurrence of an IO cycle that involves the sampling of the group of sensor nodes.

To illustrate basic operation of the data bus700in the RCGS10, an example will be described in which deflection of the joystick110used to control the catheter406results in the motors manipulating the steering wires to move the catheter406—all within milliseconds. Continued reference will be made to the IO cycle900shown inFIG. 9.

As a user deflects the joystick110, values measured by sensors positioned alongside the joystick110begin to change. Bus interface mechanisms can then write the sensor readings of these joystick110sensors to the data bus700during the next IO cycle in which these sensors are scheduled to perform operations. Given the critical nature of the joystick110, the IO cycle to which these sensors are assigned will likely be programmed to recur within milliseconds. After the sensor readings are written to the data bus700during a preliminary sensor time subinterval, the electronic control system200can read the sensor readings from the data bus700in a latter sensor time subinterval.

After the electronic control system200has read the sensor readings from the data bus700, the electronic control system200can compute motor commands based on the sensor readings. One such motor command can, for example, be directed to the motor614shown inFIG. 6. At the next IO cycle in which a group of motors controlling the steering wires are scheduled to perform operations, the electronic control system200can transmit the motor commands to the data bus700during the initial motor time subinterval930. Also during this initial motor time subinterval930, the data bus700can distribute these motor commands to the local buffer of each respective motor. Given the critical nature of catheter406movement, the IO cycle to which this group of motors is assigned will likely be programmed to recur within milliseconds. As stated previously, the initial motor time subinterval930can be triggered by the expiration of an IO cycle timer specific to IO cycle900. Next, the synchronization signal970can trigger this group of motors to actuate simultaneously or quasi-simultaneously based on the motor commands previously distributed to their respective local buffers. In this way, the bus controller730can coordinate the group of motors to manipulate respective steering wires to guide the catheter406as desired by the user.

This sequence of events can happen many times as the joystick110is being deflected. This means that many IO cycles involving the joystick110sensors and many IO cycles involving the steering wire motors (if not part of the same IO cycle) can occur during joystick110deflection. As this sequence of events is occurring, the encoders (e.g., the encoder616inFIG. 6) and other sensors measuring similar attributes of the steering wire motors (e.g., the motor614inFIG. 6) can be intermittently providing closed-loop feedback to the electronic control system200. The feedback is intermittent if the IO cycle(s) to which these encoders are assigned perform operations between each successive group of motor operations. This closed-loop feedback can, for example, indicate the actual positions of the steering wire motors. Moreover, if the motor614is not positioned as expected based on the encoder616feedback, the electronic control system200can transmit compensatory motor commands in the next IO cycle involving steering wire motor operations.

Only cyclical (i.e., periodic) operations on the data bus700have been described. With cyclical operations, bus load at any given point in time is known because the periods with which each IO cycle recurs are known. However, the bus coordinator730can also utilize some acyclical operations to optimize the data bus700since bus access time is not used when the need is not present. Acyclic operations can be used to communicate, for example, event-driven conditions that are not normally present in the RCGS10.

Both cyclic and acyclic operations are performed within IO cycles, but acyclic operations are not performed periodically, as are cyclic operations. As explained in the example with the steering wire motor and the fan blowing air over the electronic control system200, some (cyclic) operations can recur periodically, but with different respective frequencies. However other (acyclic) operations can only occur, for example, when triggered by certain events or requests from other devices.

With reference toFIG. 11, an exemplary timeline of bus access is shown with a cyclic operation1100and an acyclic operation1110occurring within IO cycles1120. The cyclic operation1100is performed during every IO cycle1120to which it is assigned. The acyclic operation1110does not occur periodically with every IO cycle1120to which it is assigned. In an alternative embodiment, acyclic operations are not assigned to specific IO cycles. Instead, the bus controller730can as needed generate an IO cycle for the acyclic operation or assign the acyclic operation to an existing IO cycle.

In one example of an acyclic operation, such as acyclic operation1110inFIG. 11, the electronic control system200can provide haptic feedback to a user of the joystick110. Haptic feedback involves imposing counteracting forces on the joystick110as it is deflected by the user. The counteracting forces signal to the user that the tip of the catheter406has contacted or is about to contact an object. The tip of the catheter406can be instrumented with a force sensor configured to transmit a sensor reading during the next occurrence of an IO cycle to which the force sensor is assigned. Since the sensor reading is not transmitted periodically, the sensor reading can be an acyclic message to the electronic control system200indicating such contact or imminent contact. The electronic control system200can read this data from the data bus700and compute a motor command for at least one motor disposed along the joystick110. During the next IO cycle to which such motor operations are assigned, the electronic control system200can then transmit the motor command to the data bus700. Upon receipt of the motor command from the data bus700, the motor disposed along the joystick110can then actuate the motor command, signaling to the user that the tip has contacted or is about to contact an object.

Some of the operations described thus far, such as motor actuation, for example, are synchronous. All of the operations described thus far, though, can be referred to as being generally synchronous. The operations are generally synchronous because motor operations occur together during motor time intervals and because sensor operations occur together during sensor time intervals.

In addition to generally synchronous operations, it can be helpful in various embodiments to perform at least some operations asynchronously. Asynchronous operations can occur at any point in time, without respect to time intervals or IO cycles. Asynchronous operations, therefore, are not assigned to specific IO cycles or time intervals. For example, an asynchronous motor operation occurs immediately rather than waiting for the next motor time interval or the next IO cycle. With reference toFIG. 9, this means that the asynchronous motor operation could occur, for example, during the preliminary sensor time subinterval950. As a further example, an asynchronous sensor operation occurs immediately rather than waiting for the next sensor time interval or the next IO cycle. With reference toFIG. 10, this means that the asynchronous sensor operation could occur, for example, during the time interval shown by 70-80 milliseconds, where no IO cycle is scheduled to occur.

Both cyclic and acyclic operations are different from asynchronous operations because asynchronous operations need not necessarily occur during respective motor and sensor time intervals of an IO cycle. Generally synchronous operations, even those that are acyclic, only occur during respective motor and sensor time intervals and hence must wait for the respective motor or sensor time interval of the next IO cycle to which it is assigned.

In the example above, it is also contemplated that haptic feedback could be configured for asynchronous operation. Yet a user would not likely recognize a difference in receiving the counteracting force on the joystick110milliseconds earlier (because asynchronous operations do not wait until the next time window).

Asynchronous operations can be of particular value when used to communicate event-driven conditions. For example, it can be desirable to communicate the existence of an error state in the RCGS10as it occurs, as opposed to waiting for the next sensor time interval, even if it is just milliseconds away. In addition, error states can be infrequent and unpredictable, so it can be wasteful to allocate recurring bus access time for transmitting the status of a potentially nonexistent error state. If the event sensor corresponding to the asynchronous operation is important, the bus controller730recognizes this and provides prompt access to the data bus700, whether during an IO cycle or not. Time can either be built into IO cycles to account for asynchronous operations or the priority of the asynchronous message can simply allow it to take precedence over other scheduled operations.

The data bus700can combine generally synchronous operations (both cyclic and acyclic) and asynchronous operations to provide order and predictability to the way in which data is exchanged on the data bus700. Different interests depending on the application can be considered when initially configuring these operations on the bus700. A few examples of competing interests include the priority of certain communication paths, safety margins for bus error states, guaranteed reaction times for events, and cycle times for closed control loops.

In one embodiment, the bus controller730can be configured to prevent incomplete sets of data from being transmitted and received over the data bus700. The operation of this embodiment during the motor time interval910is depicted in the flow diagram ofFIG. 12. In step1210, an IO cycle timer expires, prompting an IO cycle with the motor time interval910to begin performing its thread of operations. Then, in step1220, the electronic control system200writes motor commands to the data bus700for distribution to the local buffers of the motors scheduled to actuate in this IO cycle. Next, in step1230, the bus controller730performs a verification operation on the data bus700to ensure that all expected data has been successfully and completely transmitted to the data bus700. If motor commands are complete, the bus controller730can, in one embodiment, broadcast a synchronization signal in step1240. In response, all the motors assigned to this IO cycle actuate in step1250based on the motor commands provided to their respective local buffers.

If, however, in step1230the expected data set is not complete, the motors are prevented from actuating in step1260. For example, if ten motors are scheduled to actuate in this motor time interval910and the bus controller730recognizes that only nine motor commands are provided to the data bus700, the bus controller730can prevent the motor commands from being distributed to the local buffers of the motors. Discarding the motor commands if any portion is missing can prevent the motors from actuating in uncoordinated fashion and can prevent the RCGS10from entering an incomplete state. After the motor commands are discarded, motor time period910ends. Alternatively, the electronic control system200or the bus controller730can be configured to adjust or compensate for incomplete data sets and manage the system response thereto, instead of simply discarding the incomplete data set. One skilled in the art will recognize that a similar preventative measure can be taken for other sets of data, such as, for example, sensor readings.

Through the use of the data bus700and the bus controller730, the RCGS10can facilitate communication between many components every few milliseconds. For some components, this entails frequently recurring exchanges of data. For others, the exchange of data can be triggered, for example, by internal events, remote requests from other devices, and other internal timers. Based on this exchange of data from the various components over the bus700, the electronic control system200can be constantly aware of the current state of the RCGS10.

The electronic control system200can make ongoing adjustments as needed, transmitting data over the data bus700to the motors used to actuate the RCGS10, particularly motors controlling the steering wires. One such adjustment can involve, for example, slowing, accelerating, or stopping motors. Likewise, if motors receive motor commands, attempt to perform the commands, and encoders measure that the motors are not where they are expected, the electronic control system200can compensate for this in its next transmission of motor commands.

It will be appreciated that in addition to the methodologies of the disclosed invention as described above, another aspect of the present disclosure involves the structure of the electronic control system200, the bus controller730, and the data bus700configured to optimize bus traffic and to provide order to the way in which components of a system exchange data. It will be further appreciated that the methodology and constituent steps thereof performed and carried out by the electronic control system200, the bus controller730, and the data bus700, which were described in great detail above, apply to this aspect of the disclosure with equal force. Therefore, the description of the methodology as set forth above will not be repeated in its entirety.