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 :
- Copy the sample plugin files and rename everything using com_vectionvr_osvr_motionPlatformDevicePlugin instead of com_osvr_example_DummyDetectAndCreateAsync
- Replace Json file content with what was defined in my previous article for motion platform plugin interface
- Update CMakeLists.txt to match the changes

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
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
{ | |
"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" | |
} | |
} | |
} | |
] | |
} |
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:
- On top of the sample class, change the include using #include <osvr/PluginKit/TrackerInterfaceC.h> instead of #include <osvr/PluginKit/AnalogInterfaceC.h>.
- Fix the various compilation issues
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 ...
Updated last screenshot for new random value generator
ReplyDeletepictures are all broken....
ReplyDelete