Wizdish ROVR Implementation

The integration of the Wizdish ROVR1 omnidirectional treadmill needed to be modular and to provide fine-tuning options for the device. So, to implement the ROVR treadmill in a more accurate, adjustable and usable way, a custom solution was developed for Gooze.

To achieve a modular structure, the provided code snippets were cleaned up and integrated into the FTROVRMicInput component. This singleton is accessible from anywhere in the code and works as a controller for the ROVR, but still provides the convenience of adjusting settings via the editor.

Because the ROVR is connected to a PC as a microphone and multiple microphones can be connected at once, an editor dropdown was implemented to select the correct input for signal interpretation (see light blue highlights in the image). A commercial application would additionally need a corresponding option in a settings menu, but this was not implemented for the Gooze demo.

To minimize the influence of possibly recording unwanted loud external noises, the corresponding Audio Mixer group for the ROVR was equipped with Low and Highpass filters, which would still let most of the sliding noises through (see pink highlights). The passable frequency band (100-3000 Hz) was determined through trial and error and is by no means exact, but nevertheless worked as a good tradeoff.

Several previously hardcoded parameters concerning the microphone signal processing were made easily adjustable through the editor interface. E.g. the average amplitude size – the size of an array, which stores several amplitude values to be averaged – was set very low (to 1), to achieve a more direct input interpretation (see yellow highlight).

Issues with unwanted but possible peaks in the sound could be mitigated by adding the amplitude min max range, which would be used to normalize the amplitude value to a 0-1 range for further processing (see orange highlight). Additionally, the min threshold is used to avoid unintended locomotion while a user physically turns and thus produces noise. The tradeoff to this approach is, that it prohibits a more fine-grained tracking of the user movements.

As the sliding sound’s amplitude is not direct proportional to the user’s actual movement speed, another transformation is required. Hence, the acceleration lookup curve was added as a fine-tuning option against this issue, providing more accurate forward motion values (see green highlights). Again, the applied curve was established through trial and error. According to the graph, the previously normalized amplitude values are mapped to a normalized forward input parameter (see red highlight), which can be accessed by other systems like the FTXRInputManager. Though, during the experiments with Gooze, it became clear that this single general curve is not optimal for all the different movement styles of various users, although it worked as a reasonable tradeoff. Nevertheless, an individually calibrated curve would likely result in more accurately translated movements of that specific user.

Finally, a deceleration lerp parameter was added to the FTRigidbodyPlayerController component, to configure how smooth the movement should be and how quick the user should be stopped, when there is no physical movement (see dark blue highlight). This decelerating parameter adjusts the short delay at the end of a physical movement, when the virtual player still pushes forward one last bit. That last inaccurate virtual movement is a tradeoff again and may induce some simulator sickness in players on the one hand, but on the other hand it smoothens the virtual movement, instead of resulting in chopped up separate movements.