4.3.1. Console

4.3.1.1. Overview

The dVRK console application is the main way to interact with a dVRK system. It comes in two versions:

dvrk_robot dvrk_console_json
- C+ application with a Qt based GUI and ROS interface, it depends on cisst/SAW
- Compatible with all dVRK controllers
- https://github.com/jhu-dvrk/sawIntuitiveResearchKit/tree/main/ros/dvrk_robot
sawIntuitiveResearchKitQtConsoleJSON
- C+ application with a Qt based GUI, it depends on cisst/SAW
- Compatible with all dVRK controllers (including for Windows/MacOS over UDP)
- https://github.com/jhu-dvrk/sawIntuitiveResearchKit/tree/main/core/applications

For ROS, start the node dvrk_console_json from the package dvrk_robot.

ros2 run dvrk_robot dvrk_console_json

The non-ROS version is an executable found in the dVRK path.

sawIntuitiveResearchKitQtConsoleJSON

4.3.1.2. Command line options

dvrk_console_json supports all the command line options of sawIntuitiveResearchKitQtConsoleJSON as well as options to configure the ROS publish rates and some optional ROS topics.

Shared options

-j <value>, --json-config <value>

json configuration file (required)

Full path to the console configuration file. This is the only required option.

-t, --text-only

text only interface, do not create Qt widgets (optional)

This is rarely needed, the dVRK console would have to be controlled and monitored over some kind of middleware (for example ROS, OpenIGTL…).

-c <value>, --collection-config <value>

json configuration file for data collection using cisstMultiTask state table collector (optional)

See examples of configurations files in the shared/collection directory. This feature predates the dVRK ROS integration. Users should look into ROS bags for data collection.

-C, --calibration-mode

run in calibration mode, doesn’t use potentiometers to monitor encoder values and always force re-homing. This mode should only be used when calibrating your potentiometers. (optional)

This command line option is required for many calibration steps. It shouldn’t be used on a regular basis since this disables some safety checks.

-m, --component-manager

JSON files to configure component manager (optional)

See dynamic components.

-S <value>, --qt-style <value>

Qt style, use this option with a random name to see available styles (optional)

See widget customization.

-D, --dark-mode

replaces the default Qt palette with darker colors (optional)

ROS extra options

-p <value>, --ros-period <value>: period in seconds to read all arms/teleop components and publish (default 0.01, 10 ms, 100Hz). There is no point to have a period higher than the arm component’s period (optional)
-P <value>, --tf-ros-period <value>: period in seconds to read all components and broadcast tf2 (default 0.02, 20 ms, 50Hz). There is no point to have a period higher than the arm component’s period (optional)
-i, --ros-io-config: json config file to configure ROS bridges to collect low level data (IO) (optional)
-s, --suj-voltages: add ROS topics for SUJ voltages (optional)
-I, --pid-topics: add some extra publishers to monitor PID state (optional)

4.3.1.3. Configuration file

dVRK console JSON schema.

4.3.1.4. Dynamic components

The command line option -m can be used to load one or more configuration files for the cisst component manager. One can also use the field "component-manager": {} in the dVRK console configuration file itself.

This allows users to dynamically load and connect custom components such as:

different middleware bridges (OpenIGTLink, plain UDP sockets)
custom applications/components (optionally with widgets and ROS bridges), either with components derived from existing ones or generic ones
alternative devices for the MTM, PSM, foot pedals, head sensor…

The full syntax for the cisstMultiTask component manager configuration files is documented in this JSON schema.