Configuration file format for the dVRK system.
sawIntuitiveResearchKitSystem and the ROS application dvrk_robot dvrk_systemsawIntuitiveResearchKit/core/components/code/system.cppSchema used for this configuration file
Schema version
List of IO components. Each IO (input/output) component corresponds to a physical connection to a set of dVRK controllers, usually over FireWire or Ethernet (UDP). IO components/ports are identified by their name once declared.
No Additional ItemsConfiguration for a single IO component/port
No Additional PropertiesArbitrary name picked to name a single connection to dVRK controllers. Traditionally, dVRK systems used a single IO with a FireWire port. Default convention is to name the IO something like IO, IO1, IO2...
The name is used later on by the arms, inputs and any other component that needs to know which IO port should be used to communicate with a dVRK controller.
The port defines the type of connection between the PC and the dVRK controllers. For anyone using FireWire for all the connections, the setting should be fw. If your system uses FireWire between the dVRK controller and Ethernet to bridge between the controllers and the PC, use udpfw. Finally, if your system is recent (post 2024) and only uses FPGA V3, you can connect everything using only Ethernet cables and use udp.
If you have multiple FireWire or Ethernet adapters on your PC, you will need to add the FireWire port number or Ethernet IP address after the port's type (e.g. fw:1).
Having multiple IOs is very convenient to handle systems with multiple surgeon's consoles and avoid board Id conflicts. For example, one might want a system with 2 MTMLs and 2 MTMRs. The issue is that each arm assumes a default board Id based on the arm's type. Therefore, both MTMLs would use the same board Id(s) and create a conflict if used on the same IO port. It would be possible to update all your arms configuration files to change some board Ids but it's easier to use multiple ports.
Accepted values are fw, fw:X (X is FireWire port), udpfw, udp or udp:xx.xx.xx.xx (xx.xx.xx.xx is the IP address of the dVRK controller. Default controller address is 169.254.0.100. Values are parsed by BasePort::ParseOptions in library Amp1394.
^fw$|^fw:[0-9]$|^udp$|^udp:[0-9]{2,3}.[0-9]{2,3}.[0-9]{2,3}.[0-9]{2,3}|^udpfw|^udpfw:[0-9]{2,3}.[0-9]{2,3}.[0-9]{2,3}.[0-9]{2,3}$
{
"name": "IO1",
"port": "fw"
}
{
"name": "IO1",
"port": "udpfw"
}
{
"name": "IO1",
"port": "udp"
}
Protocol used for all communications. This applies wether the controllers are connected to the computer using FireWired or Ethernet (UDP with Link-Local fw, udpfw or udp). This is an advanced setting and most users should avoid defining it.
sequential-read-write: the PC reads data from each board (2 FPGA/QLA per controller), performs its computations (conversions, safety checks, PID, ...) and then writes sequentially to each board (N reads, N writes). This is the only protocol supported on older firmware (3 and below).sequential-read-broadcast-write: the PC reads sequentially but performs a single write for all the boards. The write message is an array of values sent to the boards, each board access the data it needs by index (N reads, 1 write). This is the default protocol for the dVRK controllers with firmware 4 and above.broadcast-query-read-write: the PC sends a single query/synchronization to all boards, read values are aggregated in single packet over the bus and there's a single write (1 query, 1 read, 1 write). This is the fastest protocol available but some FireWire cards seem to have trouble synchronizing the read packets. You will have to test it on your hardware to see if it supports this protocol or not. broadcast-read-write is the older name for this protocol and is provided for backward compatibility.Periodicity for the IO and PID loop. Defined in seconds, i.e. interval between two iterations. The default is defined in mtsIntuitiveResearchKit.h and is set so the loop frequency is 1500Hz, ~0.66ms so 0.00066s. This is an advanced setting and most users should avoid defining it.
Value must be strictly greater than 0.0
{
"period": 0.001
}
Maximum lapse of time allowed between read/write accesses to the dVRK controllers. It is used to detect abnormally slow IOs or disconnected cables. The value is sent to the controllers and the controllers will turn off power if the communication loop time exceeds the watchdog timeout.
Defined in seconds. The default is defined in mtsIntuitiveResearchKit.h and is set to 30ms. This is an advanced setting and most users should avoid defining it. Setting it to zero disables the watchdog and should only be used by experts. The maximum value is 300ms, i.e. 0.3s
Value must be greater or equal to 0.0 and lesser or equal to 0.3
{
"watchdog-timeout": 0.05
}
Extra configuration files to configure the IO component. The IO component can also be configured to support custom hardware using the controllers spare digital and analog IOs.
This setting shouldn't be used for the hardware supported by the dVRK software stack such as foot pedals, head sensor, focus controller... See examples in directory share/io.
{
"configuration_files": [
"sawRobotIO1394_my_contact_sensor.json"
]
}
Close all the e-stop safety relays on all the controllers found on the current port (FireWire or Ethernet). This allows the user to skip the terminal based command: qlacommand -c close-relays.
{
"name": "IO1",
"port": "fw"
}
List of arms for the system. Arms can be native, i.e. dVRK supported retired da Vinci arms, or compatible arms (with CRTK interface) created using the cisst component_manager section of the system configuration
Configuration for a single arm proxy
No Additional PropertiesName of the arm. For dVRK arms, use one of MTML, MTMR, PSM1, PSM2, PSM3 or ECM. Note that the name of the arm is used to infer which other configuration files should be loaded.
For systems with multiple consoles, one should use MTML1, MTML2... The name of the IO port (name_on_IO) must then be provided to find all the arm's configuration files.
{
"name": "MTMR"
}
Type of arm. This determines which class should be used to instantiate the arm.
MTM, PSM and ECM correspond to the default classes provided for the dVRK arms. These are the most common ones.xxx_DERIVED corresponds to classes derived from the base classes provided in the dVRK stack. Users can derive the base arm classes to alter their behavior. In this case, the system knows that the derived class has all the features from the base class so the connections to the PID, IO, Qt widget and ROS bridge are the same as those for the base class.xxx_GENERIC corresponds to classes not derived from the dVRK base classes. The system will not create any IO, PID components for this arm. The system will use a generic Qt Widget and add ROS topics if and only if the provided interface has CRTK compatible commands and events. Examples include Force Dimension devices (sawForceDimensionSDK ) and the Sensable Omni (sawSensablePhantom ).SUJ_Classic and SUJ_Si are for the clinical systems with original setup jointsSUJ_Fixed is for arms on a custom mount. It can also be used to bypass the mechanical SUJs and replace the arms reference frame with the results from an external registrationxxx_DERIVED and xxx_GENERIC, the system has no way to automatically create the component, so the user has to provide the proper component_manager configuration to first create the component for the arm.{
"arms": [
{
"name": "MTML",
"type": "MTM",
"serial": "22723",
"IO": "IO_1"
},
{
"name": "MTMR",
"type": "MTM_GENERIC",
"component": "ForceDimensionSDK",
"interface": "MTMR"
}
]
}
Arm's serial number. To verify the serial number, locate the label on the arm itself (See the dVRK documentation). The serial number and the arm's name are used to locate the arm configuration file assuming the arm configuration file name is <arm_name>-<arm_serial>.json (e.g. MTML-22723.json).
{
"serial": "22723"
}
Name of the IO port to use to connect to this arm. This is required for arms of type PSM, ECM, MTM (and derived) as well as SUJ_Classic. The IO must have been declared in the "IOs" section of the "system".
Name of the arm on the IO port, used for multiple surgeon's console. For example, MTML1 is known as MTML on a given IO port. This is used to find all the required configuration files (arm, IO, PID) for the arm. In this example, this will allow the system to look for the file MTML-12345.json instead of MTML1-12345.json
Arm configuration file. Note that this is optional if the serial number has been provided. If the serial number has been provided, the application will assume the arm file is <name>-<serial>.json. For example PSM1-22723.json. This attribute is useful mostly if the arm is simulated ("simulation": "KINEMATIC").
Use the arm in simulation mode. In this case, the system doesn't need to create an IO component and can run without the physical arms and dVRK controllers (see examples in directory share/arm). The only simulation currently supported is KINEMATIC, i.e. the PID will set the measured positions (measured_js and setpoint_js) based on the commanded positions (servo_jp). This allows to test the kinematic but doesn't include any dynamic nor simulation of interactions with the world like Gazebo or VREP would.
Base frame prepended to the forward kinematics. The base frame is also taken into account when setting cartesian position goals
No Additional Properties{
"base_frame": {
"reference_frame": "HRSV",
"transform": [
[
-1.0,
0.0,
0.0,
0.18
],
[
0.0,
0.866025404,
0.5,
0.4
],
[
0.0,
0.5,
-0.866025404,
0.475
],
[
0.0,
0.0,
0.0,
1.0
]
]
}
}
{
"base_frame": {
"component": "ECM",
"interface": "Arm"
}
}
4 by 4 matrix, i.e. homogeneous transform
Must contain a minimum of 4 items
Must contain a maximum of 4 items
Must contain a minimum of 4 items
Must contain a maximum of 4 items
Name of the reference frame. This is used for Qt Widget and ROS tf
Name of the component that can provide the base frame at runtime. This is used for the full patient cart where the SUJ component can compute the base frame.
Name of the required interface used to set the base frame on the arm (using function set_base_frame)
Override the default periodicity of the arm class.
Most user should steer away from changing the default arm periodicity. This works only for the dVRK base types (MTM, PSM, ECM).
Value must be strictly greater than 0.0
Name of the JSON configuration file for the low level arm's IO (from sawRobotIO1394).
The name of the IO configuration file is now inferred from the name and serial attributes by default. It should be specified if and only if the user needs to change the default IO configuration file.
Name of the JSON configuration file for the arm's PID (from sawControllers, mtsPID).
The name of the PID configuration file is now inferred from the arm's name attribute by default. It should be specified if and only if the user needs to change the default PID configuration file.
For arm of type xxx_GENERIC only. Name of the component for the generic arm. For the dVRK arms, the component is named after the arm (e.g. "MTML"). For other devices (e.g. sawSensablePhantom) the component might be able to provide multiple arms so the arm name is used for the "interface".
For arm of type xxx_GENERIC only. Name of the provided interface for the generic arm.
For the dVRK arms, the component is named after the arm (e.g. "MTML") and the interface is always "Arm".
For other devices (e.g. sawSensablePhantom) the component might be able to provide multiple arms so the arm name is used for the "interface".
{
"component_manager": {
"components": [
{
"shared-library": "sawForceDimensionSDK",
"class-name": "mtsForceDimension",
"constructor-arg": {
"Name": "ForceDimensionSDK"
},
"configure-parameter": "sawForceDimensionSDK-MTMR.json"
}
]
},
"arms": [
{
"name": "MTMR",
"type": "MTM_GENERIC",
"component": "ForceDimensionSDK",
"interface": "MTMR"
}
]
}
Tell the dVRK system to not expose the arm commands to ROS. By default, the component manager will expose the arm to ROS using the cisst ROS CRTK bridge. It should be set when one uses an "arm from ROS" (see `dvrkarmfrom_ros") since the arm shouldn't publish on the topics it uses.
{
"component_manager": {
"components": [
{
"shared-library": "dvrk_arm_from_ros",
"class-name": "dvrk_psm_from_ros",
"constructor-arg": {
"Name": "PSM1",
"Period": 0.01
}
}
]
},
"arms": [
{
"name": "PSM1",
"type": "PSM_GENERIC",
"component": "PSM1",
"interface": "PSM1",
"skip_ROS_bridge": true
}
]
}
List of consoles (as in surgeon's console). A dVRK system can have multiple consoles to control (teleoperate) a single patient's cart.
Each console is defined by the IOs used for the clutch and camera pedals as well as the sensor used to detect operator presence.
Within the console, two lists are used to declare the teleoperation components to be created (PSM and ECM teleoperation).
All the arms and IOs used in the console must be declared at the top level of the system configuration file.
Configuration for a single console
No Additional PropertiesArbitrary name given to the console. Usually console, console1...
General configuration for the console's inputs. All surgeon's consoles are expected to provide at least 3 signals: clutch pedal, camera pedal and operator present.
To allow users to reposition their hands while teleoperating, original da Vinci systems provide a "clutch" pedal. Later systems (Xi) also provide a slider button on each MTM so one can clutch each MTM individually.
The "camera" pedal is used to determine if the MTMs should be used to teleoperate the PSMs or the ECM.
To enable any teleoperation, the dVRK needs to know if the operator is present and holding the MTMs. On the clinical systems, there is a sensor at the level of the stereo display to detect if the operator's head is facing the display. On the first versions of dVRKs, we didn't have a head sensor so we used one of the foot pedals as a deadman switch. The operator was considered present if and only if the "COAG" pedal was pressed. Having to press the pedal continuously is quite inconvenient, so we came up with a few alternatives.
The different options are:
PEDALS_ONLY: this can be used by all dVRK sites as long as you have the original (or compatible) foot pedals connected to the dVRK controller. If you're using the foot pedals, you must specify which IO configuration file to use based on the type of controller with IO_pedals.PEDALS_GOOVIS_HEAD_SENSOR: if you're using the Goovis HMD, you can use the USB connection to detect if the operator is present. When using this option, you must also provide the HID_file.PEDALS_ISI_HEAD_SENSOR: assuming you built the custom cable to connect the original ISI head sensor (Classic and S) to the dVRK controllers (QLA1 or DQLA), you can use this option. In this case, you also need to specify which controller is used by setting the IO_head_sensor (this assumes the head sensor is connected to DOF 1 on the dVRK controller)PEDALS_DVRK_HEAD_SENSOR: cheap head sensor designed in the early days of the dVRK, see PEDALS_ISI_HEAD_SENSOR for configuration.SIMULATED: used when no physical sensor is available. The events can be emulated using either the GUI in "direct mode" or ROS topics.COMPONENTS: this is the most flexible option. Any cisst/SAW component can be used but the user has to make sure the components are properly created and provide the names of components and interfaces for the clutch, camera pedal and operator present: clutch_component, clutch_interface, camera_component, camera_interface, operator_present_component, operator_present_interface.WARNING: dVRK Si controllers can't be used to connect pedals and head sensors, you need a Classic controller (QLA1 or DQLA) since these controllers are the only one with some extra IOs.
IO file used to specify the IOs for the foot pedals. Use one of the existing files in the share/io directory.
Make sure you use the correct IO configuration file based on the name of the controller (e.g. MTML vs MTMR). The controller's name is used to identify the Id of the FPGA board connected to the pedals. You must also make sure you use specific files for DQLA based controllers.
This is required if the input_type starts with PEDALS_.
{
"input_type": "PEDALS_ONLY",
"IO_pedals": {
"IO": "IO1",
"IO_file": "io/sawRobotIO1394-MTMR-foot-pedals-DQLA.json"
}
}
{
"input_type": "PEDALS_ONLY",
"IO_pedals": {
"IO": "IO1",
"IO_file": "io/sawRobotIO1394-MTML-foot-pedals-DQLA.json"
}
}
Optional name for the IO, can be used to provide slightly more helpful error messages.
Name of the IO declared in the IOs section of the overall system configuration file.
File used to configure the IO.
IO file used to specify the IOs for the head sensor. Use one of the existing files in the share/io directory
This is required if the input_type is PEDALS_ISI_HEAD_SENSOR or PEDALS_DVRK_HEAD_SENSOR.
{
"input_type": "PEDALS_ISI_HEAD_SENSOR",
"IO_pedals": {
"IO": "IO1",
"IO_file": "io/sawRobotIO1394-MTMR-foot-pedals-QLA1.json"
},
"IO_head_sensor": {
"IO": "IO1",
"IO_file": "io/sawRobotIO1394-MTMR-dv-head-sensor.json"
}
}
{
"name": "console",
"input_type": "PEDALS_DVRK_HEAD_SENSOR",
"IO_pedals": {
"IO": "IO1",
"IO_file": "io/sawRobotIO1394-MTMR-foot-pedals-QLA1.json"
},
"IO_head_sensor": {
"IO": "IO1",
"IO_file": "io/sawRobotIO1394-MTMR-dVRK-head-sensor.json"
}
}
Optional name for the IO, can be used to provide slightly more helpful error messages.
Name of the IO declared in the IOs section of the overall system configuration file.
File used to configure the IO.
File used to specify HID (Human Interface Device) parameters for the Goovis head sensor. Use one of the existing files in the share/hid directory
This is required if the input_type is PEDALS_GOOVIS_HEAD_SENSOR.
{
"input_type": "PEDALS_GOOVIS_HEAD_SENSOR",
"IO_pedals": {
"IO": "IO1",
"IO_file": "io/sawRobotIO1394-MTML-foot-pedals-QLA1.json"
},
"HID_file": "hid/goovis-hd.json"
}
Name of the CISST component used to provide the clutch pedal signal.
This should be specified if and only if the input_type is set to COMPONENTS.
Component name
Component name
Name of the CISST component used to provide the camera pedal signal.
This should be specified if and only if the input_type is set to COMPONENTS.
Component name
Component name
Name of the CISST component used to provide the operator_present signal.
This should be specified if and only if the input_type is set to COMPONENTS.
Component name
Component name
List of PSM tele-operation components. Each PSM tele-operation component requires a MTM and a PSM
No Additional ItemsConfiguration for a single PSM tele-operation component
No Additional PropertiesName of surgeon's side MTM arm to be used (MTML, MTMR, MTML1...). The arm must have been declared in the main system configuration file under "arms".
Name of patient's side PSM arm to be used (PSM1, PSM2...). The arm must have been declared in the main system configuration file under "arms".
Type of teleoperation. This determines which class should be used to instantiate the PSM teleoperation.
TELEOP_PSM corresponds to the default class provided for the dVRK. This is the most commonly used.TELEOP_PSM_DERIVED corresponds to classes derived from the base class provided in the dVRK stack. Users can derive the base PSM teleoperation class to alter its behavior. In this case, the system knows that the derived class has all the features from the base class so the connections to the Qt widget and ROS bridge are the same as those for the base class.TELEOP_PSM_GENERIC corresponds to classes not derived from the dVRK base.Override the default periodicity of the teleoperation class.
Most user should steer away from changing the default periodicity.
Value must be strictly greater than 0.0
Component and interface used to provide the base frame of the PSM.
This is used if the reference frame of the teleoperation might change during the teleoperation. For example, with automated or manual motion of the ECM while the operator is teleoperating. This feature is not available on clinical systems but sometime used with the dVRK for research putposes. This is useful for groups with setup joints (even fixed ones) and an ECM
No Additional Properties{
"teleop_PSMs": [
{
"MTM": "MTMR",
"PSM": "PSM1",
"PSM_base_frame": {
"component": "ECM",
"interface": "Arm"
}
}
]
}
Component name
Component name
Configuration passed to the teleoperation component after its creation. It is used by the component's Configure method.
Scale factor applied to translations from the MTM to the PSM
Value must be strictly greater than 0.0 and lesser or equal to 1.0
Ignore PSM jaws and incidentally the MTM gripper.
This can be used for PSM tools (or generic PSM arms) without jaws and/or MTM arms without a gripper.
Start the tele-operation component with the rotation locked, i.e. the PSM orientation will not change and the MTM wrist will be locked (for MTMs with motorized wrist such as the da Vinci MTM).
This can be overwritten at runtime using the GUI or ROS topics.
Start the tele-operation component with the translation locked, i.e. the PSM position will not change.
This can be overwritten at runtime using the GUI or ROS topics.
Maximum orientation difference between the MTM and PSM allowed before starting the tele-operation.
The error is computed by converting the difference of orientation to an axis-angle. This threshold is ingnored if "align-mtm" is set to false.
Most users should steer away from this setting. The default is defined in components/include/sawIntuitiveResearchKit/mtsIntuitiveResearchKit.h: `mtsIntuitiveResearchKit::TeleOperationPSM::OrientationTolerance
Value must be greater or equal to 0.0
This is one of two parameters used to detect hand motion from the operator to determine if their hand is on the MTM (see also "startrollthresold").
To prevent accidentally getting in follow mode, the tele-operation component tries to detect some motion on the MTM, using a combination of thresholds on the gripper and roll motion. In any of these motions exceed the corresponding thresholds, the tele-operation component assumes the operator have their hand on the MTM and tele-operation can start. If any of these threshold is set to zero, the tele-operation will start without any motion the on the MTM. This can be used for testing with a simulated MTM where emulating gripper and roll motion would be complicated (see "arm": "simulation").
Most users should steer away from this setting. The default is defined in components/include/sawIntuitiveResearchKit/mtsIntuitiveResearchKit.h: `mtsIntuitiveResearchKit::TeleOperationPSM::GripperThreshold
Value must be greater or equal to 0.0
See "start-gripper-threshold" for description.
Most users should steer away from this setting. The default is defined in components/include/sawIntuitiveResearchKit/mtsIntuitiveResearchKit.h: `mtsIntuitiveResearchKit::TeleOperationPSM::RollThreshold
Value must be greater or equal to 0.0
Enforce absolute orientation between the MTM and PSM.
On clinical da Vinci systems this is always true, i.e. the orientation of the operator's hands with respect to the display always matches the orientation of the tooltip with respect to the endoscopic camera.
For research purposes, it can be interesting to allow relative orientation between the MTM and PSM. This can also be useful for alternate MTMs (e.g. ForceDimension devices) with a smaller SO3 space which might require orientation "clutching". To note, the application publishes the error in orientation between the MTM and PSM when the tele-operation is in Following mode. This can be overwritten at runtime using the GUI or ROS topics.
Maximum rate (velocity) for the PSM jaw angle in radians per seconds.
Most users should steer away from this setting. The default is defined in components/include/sawIntuitiveResearchKit/mtsIntuitiveResearchKit.h: `mtsIntuitiveResearchKit::TeleOperationPSM::JawRate
Value must be strictly greater than 0.0
Maximum rate (velocity) for the PSM jaw angle in radians per seconds when returning from clutch. When the user returns from clutch mode and back in follow mode, the PSM jaw angle might not match the MTM gripper angle. To prevent sudden changes in jaw angle, the PSM jaws moves at a slower rate until it "recovers" and matches the MTM gripper angle. Most users should steer away from this setting. The default is defined in components/include/sawIntuitiveResearchKit/mtsIntuitiveResearchKit.h: `mtsIntuitiveResearchKit::TeleOperationPSM::JawRateBackFromClutch
Value must be strictly greater than 0.0
Scaling applied to the MTM gripper angle. All angles are in radians! This angle is then used to control the PSM jaw angle.
By default, the tele-operation component assumes that the MTM gripper maximum angle is 60 degrees (as defined in the gripper calibration and the angle 0 corresponds to the PSM jaws being closed. When closed (angle set to 0), the PSM jaws don't apply any significant torque (just enough for the PID control to maintain a zero angle) so to apply a stonger grip, the tele-operation component sends a negative jaw angle to the PSM. Since the jaws can't have a negative angle, this will lead to a higher tracking error and by direct consequence, the PID will apply a strong torque. The "gripper-scaling" parameters are used to linearly interpolate the MTM gripper angles to the default convention, i.e. [0, 60] for positive range and some room for negative angles. For example, if your MTM has an effective range of [0, 30], set the "max" to 30 and the "zero" to 5. This way the values between 5 and 30 will be mapped to [0, 60] and values below 5 will generate negative angles for the PSM jaws (i.e. applying extra torque)
No Additional PropertiesAngle in radians on the MTM corresponding to just closed jaws on the PSM
Maximum angle in radians the MTM can send. By default, 60 degrees (by convention for dVRK MTMs)
Use the MTM cartesian linear velocity, scale it and send it to the PSM along the position to define the setpoint used by servo_cp.
This is turned on by default on the dVRK. For this to work with alternate arms (e.g. ForceDimension for MTM, UR for PSM), you need to make sure the MTM velocities are not too noisy and the PSM can receive setpoints with both positions and velocities (twists).
Use the MTM cartesian angular velocity and send it to the PSM along the position to define the setpoint used by servo_cp.
This is turned off by default on the dVRK. For this to work with alternate arms (e.g. ForceDimension for MTM, UR for PSM), you need to make sure the MTM angular velocities are not too noisy and the PSM can receive setpoints with both positions and velocities (twists).
List of ECM tele-operation components. Each PSM tele-operation component requires a MTML, MTMR and a PSM
No Additional ItemsConfiguration for a single ECM tele-operation component
No Additional PropertiesName of surgeon's left side MTM arm to be used (MTML, MTML1...). The arm must have been declared in the main system configuration file under "arms".
Name of surgeon's right side MTM arm to be used (MTMR, MTMR1...). The arm must have been declared in the main system configuration file under "arms".
Name of patient's side ECM arm to be used (ECM, ECM1...). The arm must have been declared in the main system configuration file under "arms".
Type of teleoperation. This determines which class should be used to instantiate the ECM teleoperation.
TELEOP_ECM corresponds to the default class provided for the dVRK. This is the most commonly used.TELEOP_ECM_DERIVED corresponds to classes derived from the base class provided in the dVRK stack. Users can derive the base ECM teleoperation class to alter its behavior. In this case, the system knows that the derived class has all the features from the base class so the connections to the Qt widget and ROS bridge are the same as those for the base class.TELEOP_ECM_GENERIC corresponds to classes not derived from the dVRK base.Override the default periodicity of the teleoperation class. Most user should steer away from changing the default periodicity.
Value must be strictly greater than 0.0
Configuration passed to the teleoperation component after its creation. It is used by the component's Configure method.
Scale factor applied to insertion motion
Value must be strictly greater than 0.0 and lesser or equal to 1.0
General settings for the dVRK system configuration.
No Additional PropertiesDirectories used to locate dVRK configuration files.
Directories can be relative. In this case, the search will be relative to the current working directory. This feature should be used with caution as users might inadvertently include the wrong configuration files. The log file cisstLog-xxx.txt can be used to determine the full path and content of the files actually loaded.
Sets the audio volume (as a ratio of the operating state volume set on the computer).
This can be useful if you are getting tired of the beeps emitted by the dVRK system application when system events occur (e.g. clutch, camera, operator present...)
Value must be strictly greater than 0.0 and lesser or equal to 1.0
Make the system say something useless when it starts.
It's mostly a way to test the text-to-speech feature.
Configuration required to use the da Vinci endoscope focus controller. This requires a custom cable and will only work with the original da Vinci focus controller (Classic and S, not Si). The configuration depends on which dVRK controller you connected the focus controller, different files are provided in share/io for your convenience. This setting will:
- add a component to send focus in/out commands to the focus controller
- connect (in software) the foot pedals cam+/- to change focus
- add a Qt widget and ROS topics
Users can still change to focus using the +/- buttons on the controller itself.
{
"ISI_focus_controller": {
"IO": "IO1",
"IO_file": "io/sawRobotIO1394-MTML-dv-endoscope-focus.json"
}
}
Optional name for the IO, can be used to provide slightly more helpful error messages.
Name of the IO declared in the IOs section of the overall system configuration file.
File used to configure the IO.
Section used to dynamically create and connect cisst/SAW components to be used along the dVRK system. See cisstMultiTask component manager
No Additional Properties{
"components": [
{
"shared-library": "sawForceDimensionSDK",
"class-name": "mtsForceDimension",
"constructor-arg": {
"Name": "ForceDimensionSDK"
},
"configure-parameter": "sawForceDimensionSDK-MTMR.json"
}
]
}
{
"components": [
{
"shared-library": "sawSocketStreamer",
"class-name": "mtsSocketStreamer",
"constructor-arg": {
"Name": "streamerMTML",
"Period": 0.01
},
"configure-parameter": "streamerMTML.json"
}
],
"connections": [
{
"required": {
"component": "streamerMTML",
"interface": "Required"
},
"provided": {
"component": "MTML",
"interface": "Arm"
}
}
]
}
Class name, i.e. type, to be used to dynamically create the new instance.
String passed to the component's Configure virtual method. The component manager will attempt to find a file using this parameter. If a file is found, the component manager will call the configure method with the full path. Otherwise, the component manager will call the method with the parameter as-is. This is optional. If the configure-parameter is not provided, the component manager will call component->Configure("").
Attributes required to build a single object passed to the constructor of a component. These objects depend on the type of component, e.g. mtsComponent, mtsTask, mtsTaskPeriodic... and are defined in the file cisst/cisstMultiTask/mtsParameterTypes.cdg.
Name of the component instance to be created. This name must be unique for the component manager and will be used later for connections.
Value must be strictly greater than 0.0