10.1. Options
The dVRK software stack is meant to be as open as possible, so it can
be integrated in an end-user application. Once you’ve configured your
subset of dVRK arms to use in your system.json, the dVRK system
class will automatically set up some Qt widgets for visual debugging
as well as some ROS topics, services and tf2 transforms. This is
described in the software architecture page.
The API is described in the dVRK API 2.x. The
dVRK API uses the CRTK naming convention as much as possible, so you
should familiarize yourself with CRTK.
Default components for the dVRK process
If you decide to use ROS and treat the dVRK system as a “black box”, you will end-up with two (or more processes). ROS is one example of middleware between the processes, we also provide some support for OpenIGTLink and plain UDP sockets. You can write your ROS nodes using ROS directly or use the CRTK Python Client. The latter offers a simple Python API that doesn’t require any ROS knowledge.
Alternatively, you can opt to implement your application’s logic using a new or existing cisstMultiTask component. In this case, your application will be a single process with multiple threads. If C++ is your programming language of predilection, you can write your own (custom) components or derive an existing one. If you prefer Python, you should try the IRE (embedded Python interpreter).
Note
Even though the exact syntax depends on the programming language, all the dVRK APIs, C++, Python, ROS topics, JSON over UDP (sawSocketStreamer) use the CRTK naming convention!
Note
There is at least two ways to write dVRK applications using Python. Over ROS topics with the CRTK Python Client or with the embedded Python interpreter (IRE). Pick based on your requirements.