Collaboration Opportunities

Collaboration Opportunities

  The Collaboration Opportunities section details how the team have designed the system so that it is easy for future developers to understand and develop further. Any future developers wishing to work on the Depth Sensing Surgical System can find all code related to the project in the team’s GitHub repository:

 One of the team’s key goals when designing the Depth Sensing Surgical System was to advocate simplicity, in both interface design and code structure. To aid future developers, the code is heavily commented to give maximum understanding of how the various algorithms contained in the system work.
 The system the team has built is by no means a finished product. It is a prototype - a proof of concept that proves that depth sensing can be applied to surgery, and provides several computer vision algorithms for this purpose that would be useful in surgery. This means that it is particularly important for future developers to be able to understand and add to the system quickly and efficiently without having to spend hours attempting to understand the system so that development can continue. To this end, the system architecture was designed with maximum simplicity in mind.
 The team has built the system according to a Strategy design pattern, with separate families of strategies for visual augmentation (VisualAugmenters), tool identification (ToolIdentifiers) and system control (Controllers). This makes it much easier for potential developers to add to the system. For example say a developer wanted to add a way of controlling the system through an iPad app - rather than having to wade through the code of the MainWindow file and find how it’s controlled, they simply write a class that implements the IController interface and communicates with the iPad app, then sets the system controller which is simply an object and an assignment in the main class, then the system can be controlled by app as well as voice and click control.
 Separating the main components of the system into three separate families of strategies like this allows future developers to choose an area of the system they want to develop and focus only on that. There is no need for them to build a visual augmenter just because they built a tool identifier, for example. This advocates simplicity in the continuation of development beyond the end of this project.
 Separating the main class that handles the displaying of images from the functionality of the system also makes development a more simple process. This is because if a developer wants to build a new augmentation for example, then all they need to do is write a class that implements the IVisualAugmenter interface, and then assign a button on the UI that turns their augmentation on by setting the system’s IVisualAugmenter object to the class they have written. There is no need for the developer to handle the actual displaying of the image or any of the locking and unlocking actions of the image bitmaps.
 All of these principles used in designing and constructing the Depth Sensing Surgical System mean that continuing development should be a simple process for future developers, who will be able to add to the system quickly and efficiently.
 If these future developers wish to use the algorithms that the team has designed with a different depth sensor, some recoding of the system will be required on major parts of it such as the MainWindow file before this is possible. However, the overall architecture can be used with any depth sensor, from the Kinect to a depth sensing endoscope.