MRC II Software Extensibility
Design Documentation
The MRC II Software provides an application programming interface (API) that allows Computer Integrated Surgery (CIS) applications to interface to the real-time robot control system. This document looks beneath the API to explain how researcher can modify the real-time robot control software.
The MRC II software releases will be provided as source code and as compiled binaries (e.g., library files) for multiple platforms.
There are 4 primary ways in which the MRC II software can be modified:
The difference between the third and fourth methods is that in the latter method, the application software can symbolically request that the MRC II software load a particular “package” or “plug-in”. This is similar to the loading of packages in the TCL interpreter.
Within these categories, there are several other design options to consider, such as whether to extend the existing software by sub-classing and/or by introducing new classes.
This document will identify certain key objects that are likely to require extension and will suggest some best practices.
We first review the concept of dynamic linking, which is provided on many different platforms. On Linux/Unix systems it is provided by Shared Libraries (.so extension) and on Windows systems it is provided by Dynamic Link Libraries (.dll extension).
Dynamic linking with C++ can be difficult due to the (implementation-dependent) name mangling and due to the lack of support (on most platforms) for dynamically linking classes. Nevertheless, there are several known methods for dynamically linking to C++ classes. One excellent source of information for Linux is provided by:
http://www.isotton.com/howtos/C++-dlopen-mini-HOWTO/.
This strategy assumes that the shared library contains a sub-class (derived class) of a class that is already defined in the executable. The shared library must then contain a C language class factory function that creates objects as well as a corresponding function that destroys objects.
Microsoft Windows contains a function called LoadLibrary that provides similar capabilities to the Linux dlopen function. The November 2000 issue of the C/C++ Users Journal contains an article that describes (among other things) how to create dynamically loaded libraries for Linux and Windows:
http://www.cuj.com/articles/2000/0011/0011b/0011b.htm.
For improved portability, the GNU libtool package (specifically its libltdl component) can be used instead of the Unix/Linux dlopen functions and the Windows LoadLibrary functions.
Another useful reference would be to investigate how TCL packages are created, especially using the stub library introduced with TCL 8.1.
The MRC II State Table consists of a (STL) vector of pointers to mrcStateDataArray objects. Each mrcStateDataArray object provides a circular buffer of time-indexed data. The State Table initially contains built-in state data such as the commanded joint position and the measured (feedback) joint position. New state objects can be added by calling mrcStateTable::AddElement. This function returns a handle to the state data (mrcStateDataId type) – this is really just an integer value that extends the enum of built-in state data types.