This section is closely related to the Collaboration Opportunities section in that both sections relate to continuing development after the end of this project. However, whereas the Collaboration Opportunities section describes how the system has been designed so that continuing development is easy for future developers, this section describes how exactly a developer would go about continuing development of the system.
As this project is a proof of concept - to show that depth sensing can be applied to surgery - it is essential that it be easy to continue development. Whether this be for depth sensing using the Kinect sensor or any other sensor, the ideas demonstrated in this project need to be easily understandable and the code informative and easy to add to. This will allow development to continue quickly and to its fullest potential.
In order to continue development, the future developer will need a copy of the system’s code, which can be found at the team’s GitHub repository:
In order to better understand the architecture of the system, reading the Architecture section of the website would be advantageous, particularly take a look at the class diagram:
Finally for a more in-depth understanding of how the logic behind the system works, read over the extensive comments included in the code and read the system manual pdf:
Once equipped with these items, the future developer is well placed to understand how the system works and continue development. In order to make development easier for future developers, the MainWindow class of the system already handles most of the tedious work associated with displaying a normal and augmented image from the Kinect. The following sections detail how a developer would go about adding to each of the strategies.
Visual Augmentations
In order for a future developer to add a new visual augmentation to the system, all they need to do is write a class that implements the IVIsualAugmenter interface, and then set a UI control to change the IVisualAugmenter object of the MainWindow class to the augmentation that they have written. For maximum efficiency, the sendCommand() method can be used and the necessary terms added to it to turn the new visual augmentation on and off.
ToolIdentifiers
To add to the tool identifier strategies, the developer will first need to ensure that a visual augmenter already exists that will use the output of one of these strategies, as the team’s visual augmentations have tool identification by bright green colour incorporated into them. This is because the augmentations were developed before the final system was assembled, so tool identification and visual augmentation were not separated as they should be. Future developers simply need to write a tool identification algorithm that returns an array of indexes of the main image at which pixels belonging to the tool can be found. This array is then received by a visual augmenter algorithm that will apply the augmentation only to the pixels found at these indexes, which should be pixels belonging to the tool.
Controllers The developer would simply need to write a class that implements the IController interface and has the sendCommand() method that can be used to tell the MainWindow class which augmentations to apply. Some redesign of the MainWindow class may be needed for this as it implements the Controller interface itself for control by clicking.
Development Suggestions
In the section “The Future”, under “Short Term Goals” are several subtitles that provide suggestions for the future developer about things that they may work on next to improve the system. These are things that the team believe are unfinished or could be improved upon, and would not take long to do.
Under the “Medium Term Goals” section are some suggestions for the more committed developer about features that could be added to the system. Developing these goals will take a significantly longer time than the short term goals, but would improve the system by a much larger amount.
The section referring to goals for future developers can be found here: