MotionInput V2

MotionInput v2 was a final-year MSc Computer Science industry project completed in the summer of 2021. They were tasked with redeveloping and expanding on the functionality of MotionInput v1, creating 4 modules of interaction: hand, eye, head and full body gesturing. At the end of the project, they produced a fully functional, compiled proof-of-concept demonstrating their hard work and development.

In order to ensure that our development of MotionInput v3 is a vastly improved version over the last generation, it was crucial that we studied the old version’s implementation as in-depth as possible. We focused on finding the criticisms and areas of improvement, and created potential solutions for any problems found to form our final requirements, ensuring that MotionInput v3 would be better in the most crucial areas, and to set a high standard for any future development onwards with MotionInput.

The 2 main sources of information for MotionInput v2 was the development source code repository, allowing us to directly see the implementation of everything underneath, and also the MSc Computer Science dissertation papers of the final year students that authored MotionInput v2, which should compliment the code that each student wrote.

Firstly, each student’s project was wholly about implementing a particular functionality for MotionInput. For example, one dissertation is titled “Exercises Module with Extremity Triggers and Repetitious Exercises using Computer Vision” [2], whilst another is titled “Webcam-based Hand Gestures to Control Existing User Interfaces and Its Value in a Clinical Environment” [3]. Since each student mainly focused on their work for their dissertation, they would code only for their own functionality. This resulted in very different coding styles and file structure found in the base code.

As shown above, we can compare the file structures for the hand module and the body module, both worked on by different students. The concept of an ‘event’ class and ‘gesture’ class is defined in the hand module, but not in the body module or in any other module. The lack of consistency makes it very difficult for a developer to extend functionality for one module and then attempt to extend functionality for another because they are so different in implementation.

Likewise, each of the final year students came from undergraduate disciplines that were not Computer science-oriented, and as a result had little coding experience prior to starting the MSc Computer Science course. They only had about 2 months of coding training before starting the project. As a result, the code quality is further affected by the lack of experience and familiarity with high quality coding conventions and methods.

Examples include inconsistent variable and method naming:

The architecture of MotionInput v2 is also limited in that it did not allow for the use multiple modules at once. For example, you cannot exactly select “Hand Gesturing” with “Full Body Gestures”.

Strangely, however, there is a mode within “Full Body Gestures” that has full body tracking with some hand gestures allowing for controlling the cursor with the hand. However, instead of the code allowing for part of the hand module being activated alongside the body module, instead code from the Hands module is just copied over to the Body module’s file structure. This is an unnecessary repetition of code, breaking the DRY rule (Don’t Repeat Yourself).

Coded methods and classes are generally not cohesive and verbose, with some main classes having a huge number of input arguments, making them very hard to decipher.

Likewise, for all of the modules, the main body of code is located in each module’s __init__.py file, which is not the intended purpose of __init__ files and since the files are extremely long, they are difficult to understand. For example, the __init__ file for the head module consists of one class, but the class in total is over 1000 lines long, with a method to process a frame that is over 800 lines long

It is also mentioned in some dissertations that the Model-View-Controller (MVC) pattern is used in some areas of the codebase [3]. However, this is a misinterpretation of the design pattern as the software as a whole should use the MVC pattern rather than selectively. We can also see the attempts to use MVC are also not entirely correct. There is no model, view, or controller classes or files explicitly defined in the codebase, and there are many times where actions that should be performed separately by a model, view or controller are combined in a single class or method. An example of this is in the processFrame method for a module, which acts as all 3. It receives an image (model), validates and processes it (controller), and draws to the screen (View).

There are also a lot of “magic numbers”, or hard coded values that are repeated multiple times in a method.

Whilst sometimes it is necessary to have hard coded values, the example above may be a value that a developer may want to configure and change, rather than leave as is. If they wanted to change the value, they would need to manually go through code and change each occurrence every time. There is no centralised storage or file containing configurable parameters such as this one.

Finally, With regards to documentation, there is a severe lack of it, with the only documentation for developers being a compilation guide, and some system manuals that are placed in some of the MSc dissertation papers’ appendices [3]. This documentation is not very detailed, mainly outlining a few areas of code rather than extensively going through each file and classes. Since they are all found in different places, it is also difficult to keep them all organised. This means that the documentation for V2 doesn’t compliment the code well, and does not help with maintainability or future developers to get up to speed with understanding the codebase.