Defining and Validating

Our initial task was to define what information needed to be transferred, when that need to happen, and in which direction.

With the sync needing to be both bi-directional and the potential for users to pick up any available headset, we needed a single source of truth that could validate both requests for, and submissions of, data.

Validation needed to occur at different levels of the system; when was the headset last synced [outofdate timestamp], when did the user last connect [usage timestamp], overall progress, module and module data results.

To mitigate the flow of traffic and reduce complexity, we designed the headset sync code to be less compicated. The headset would simply make a request for progress along with its existing progress file (if any) and the server would check against the canonical progress, update if required and return the progress. If the headset progress was newer, it would just receive the same data.

By simplifying the logic on the headset, we were able to streamline the process for every sync request. All requests and data passed in the requests are assigned timestamps enabling reliable comparisons to be made at shallow, deep, or at multiple, fully recursive, levels.

Generating the API and Testbed 

With the above in place, We could then generate all of the API endpoints that the VR headsets needed to access. We made this available via Postman, an API collaboration platform, which offers an easy-to-use desktop web-app allowing both technical and non-technical stakeholders to make requests and see the results.

Opening up the process in this way gave stakeholders insights that they would normally not see until the alpha release. Enabling everyone to see the system working, albeit at a data level, inspired confidence across the whole project team and generated discussions about changes to data structures at a much earlier stage.

We wrote the testbed in C# that implemented all of the headset api requests. We added it to a Unity project allowing us to validate both the API and the data synchronisation logic without needing to continuously push to the headset.

With the client-server integration in place, we were in a position to write all of  the code for user, headset & data management.

Defining User Access

Using an open-source content management framework with highly customisable permissions, we created a data management system with integrated API. Using ACLs (access control lists) we created custom permissions for the different roles in the system: headsets, headset users, data managers, administrators and sysadmins.

Synchronisation

After hooking up all api calls for data interop, storage and retrieval, we were finally ready to implement our synchronisation solution between the headsets and server.

Using the rules outlined above, synchronisation was cascaded down through all of the various data files generated during each training session, enabling straightforward management of all data and allowing changes to bubble up through the data hierarchy.

All data is stored in original format, and transformed for monitoring in the data management system. Data administrators are able to transform the data at different scales for export to other systems. 

Outcomes

DeftMD has been deployed to 16 Meta Quest Pro headsets and is currently being trialled in locations across the UK.

Findings from the trials will be published in peer-reviewed journals, before work begins on the commercial product.