Going the OSVR way - Stubbing

This article is somehow a "man in middle" one. In fact, I wanted to dive into the creation of our motion cancellation plug-in and then I settled back and thought "How am I going to test this ?".
First of all, it must be mentioned that these articles are written by a seasoned consultant programmer ( mainly in Java - I'll get back to that later) spending quite some time every day in public transportation.

Public transportation are really nice to get you from point A to B while blogging, reading or programming, but unfortunately usually too crowded to deploy and setup a full blown motion simulator. This led me to think about how one could stub a device plug-in to allow easier testing and validation of the analysis plug-in.

In previous article, I defined the motion simulator device interface. Let's use this interface and build a fake plugin that will simulate some motion platform movement. The goal here is not to reproduce realistic motion simulator movements but only to be able to fake it with a dumb algorithm to validate our analysis plugin.

Creating an empty OSVR plugin

To achieve that, we first need to make sure that we can create and deploy a simple plug-in and have it detected by the OSVR server. Let’s follow the excellent tutorial available here. For the current case, this mean :

1. Copy the sample plugin files and rename everything using com_vectionvr_osvr_motionPlatformDevicePlugin instead of com_osvr_example_DummyDetectAndCreateAsync
2. Replace Json file content with what was defined in my previous article for motion platform plugin interface
3. Update CMakeLists.txt to match the changes

At the end your original folder (MotionPlatformStub folder in my case) should contain something like



Next, we update the com_vectionvr_osvr_motionPlatformDevicePlugin.cpp  file and remove everything except the return statement from the update method (around line 60). Again, the goal of this first step is not to actually do something, only to have something running in the OSVR container.

After this initial setup, we can fire cMake and configure it as described in the tutorial.



And run the configure and generate steps



If everything is successful, you should have a build folder containing something like

Building and running the plugin

Now we are ready to fire the generated sln file in our favorite C++ IDE, and do a rebuild all. This generate a DLL stored in the bin\osvr-plugins-0\Debug folder. To run this generated DLL, copy the file to the bin\osvr-plugins-0 folder of your OSVR installation and fire the osvr_server.exe. You should obtain something like



Et voilà ! Self high five ! you have successfully created, build and deployed an empty plugin in OSVR !

Linking the dots in OSVR

Now that we have our first plugin running we have to make sure that OSVR routes correctly the requests to it. Looking at OSVR documentation, it is only a matter of configuring a JSON file. To test the changes we first update the osvr_server_config.json file to contain

	{
	"server": {
	"sleep": 1
	},
	"plugins": [], /* only need to list manual-load plugins */
	"routes": [
	{
	"destination": "/platform/orientation",
	"source": {
	"child": {
	"sensor": 0,
	"tracker": "/com_vectionvr_osvr_motionPlatformDevicePlugin/current_orientation0"
	}
	}
	}
	]
	}

view raw gistfile1.json5 hosted with ❤ by GitHub

We now restart osvr_server.exe and call it from TrackerCallback_cpp.exe. This app calls our server and list the available routes like.



Hurray !!! our route is defined.

 

Analog to Tracker interface

As defined in our Json interface, our device plugin share the data using the tracker interface class. To achieve that, we first migrate from the Analog interface based sample class to the Tracker interface based one. This is quite easily done:

1. On top of the sample class, change the include using #include <osvr/PluginKit/TrackerInterfaceC.h> instead of #include <osvr/PluginKit/AnalogInterfaceC.h>.
2. Fix the various compilation issues

As a true believer in SOLID principles, I also renamed the inner class to be TrackerSyncDevice instead of AnalogSyncDevice and change the device object reference to OSVR_TrackerDeviceInterface m_tracker.

 

Generating stub data

Now that our class is using the right interface, we change the update method to generate some random data and output it to standard output. The output of osvr_server console is now as follow :



For more details about the class created in this article please refer to https://github.com/VectionVR/OSVR-MotionPlatformStub. I made the project availablefor re-use and will update it to have more relevant output than 0,0,0.

Thanks to those who had the patience to read me until here. If you like this article series, we need your support, follow us on Twitter  like us on Facebook or just share this article as much as you want.

TO BE CONTINUED ...