vrui_mdf testing
Opened this issue · 19 comments
I am interested in helping test vrui_mdf. Currently, I am working on a robotic sanding problem and have a Gazebo simulation of the system running. The lab I work in has an HTC Vive and a high end gaming PC capable of VR applications. I tried to install vrui_mdf yesterday, but ran into an issue, #1. Once installed I would be happy to help with any testing or provide feedback.
Hi there! Your problem sounds fun, and we'd be happy to have more testers and feedback :) --My student is currently working on a fix. We think we know what the problem is; we'll send a note to you under the issues page for vrui_mdf once the repository has been updated with a working fix. Thanks for letting us know!
Thanks for the quick response. I'll watch for a response to my issue in the vrui_mdf repository.
(Okay, kind of redundant to say this looks like a compilation issue, but more specifically it may be an issue with the linking that catkin_make is doing -- or 'not doing' right now that it should be doing, rather -- and potentially the environment variables for the workspace. We're going to need a bit more info from you. Please see the responses/asks under the vrui_mdf issues page? --Don't worry, we'll help you track this down :)
As I outlined in #1 I got the package to compile. I am now trying to figure out how to add vrui_mdf into my existing gazebo simulation. It looks like I need to add the vr_view gazebo model into my simulation. However, looking at the launch files I don't see where vr_view is included in the simulation. Do the Vrui_server or tracking nodes automatically spawn this model, or am I missing something else?
launch/VR_quadrotor_outdoor.launch should be fully-featured. I think you're right about the correct sensor being in the vr_view model. It looks like the generated file src/tracking.cpp may be the node responsible for opening the model up for you (lines 126 and 188?).
User beware though -- it looks like several places in the repo the '/home/username' my student uses is hardcoded into several of the gazebo model file loading calls currently, which is probably why it's not working right for you there. I'll talk to my student about cleaning this up... ^_^
I am trying to get the Vrui_server node running, but I get the following error message,
VRDeviceDaemon: Caught exception VRFactory: Could not load dynamic library /usr/local/lib/x86_64-linux-gnu/Vrui-4.5/VRDevices/libOpenVRHost.so due to /usr/local/lib/x86_64-linux-gnu/Vrui-4.5/VRDevices/libOpenVRHost.so: cannot open shared object file: No such file or directory while initializing VR devices
The file is not where it is supposed to be, and furthermore I cannot find it anywhere in the ~/src/Vrui-4.5-001/ directory. Have you experienced this issue, or should I contact the Vrui developers?
Ah, that may be one of those things with that one script needing help finding the libraries. ^_^
First, you need to make sure Vrui was installed system-wide. Then open a new terminal to clean up the environment variables.
Second, you may need to modify the RunViveTracker.sh file a bit...
See this page for the links discussing the issue: https://github.com/AS4SR/general_info/wiki/VR-and-Gazebo
Search for "reddit thread with help on the libraries" on the page.
Basically, there are a few "magic" lines you need to run to find where the libraries actually got installed on your system, and then you need to mod RunViveTracker.sh to include those library paths before running a few things. (At least, it did with some of the older / first Vive-supported Vrui versions.)
I think I have a copy of what I use / added on my older Ubuntu 16.04 system at home still, if you don't mind waiting a bit. The instructions at the reddit page are fairly straightforward though. (Yet another reason I need to get a proper install script written up for this thing...)
You're going to want to run either the Build-Ubuntu.sh or the old version of the script to install Vrui properly system-wide. See: http://idav.ucdavis.edu/~okreylos/ResDev/Vrui/Download.html
If you want to know more, see: http://idav.ucdavis.edu/~okreylos/ResDev/Vrui/InstallationGuide.html
Try the appropriate Build-Ubuntu.sh script first, see if that fixes it? I remember local compilation being touchy.
Part of my problem turned out to be that I hadn't installed Steam and SteamVR yet. Once I did that I am now getting an error,
grep: symbol lookup error: grep: undefined symbol: pcre_jit_stack_alloc
Based on a Google search it sounds like this may be an Nvidia driver issue, or an issue with a shared library.
I think I am getting closer. I am running VRDeviceDaemon -rootSection Vive and getting the following output,
VRDeviceDaemon: Reading configuration file
VRDeviceDaemon: Initializing device manager
VRDeviceManager: Loading device Vive of type OpenVRHost
OpenVRHost: Loading OpenVR driver module from /home/cameron/.local/share/Steam/steamapps/common/SteamVR/drivers/lighthouse/bin/linux64/driver_lighthouse.so
OpenVRHost: OpenVR driver module configuration directory is /home/cameron/.local/share/Steam/config/lighthouse
VRDeviceManager: Managing 3 trackers, 14 buttons, 6 valuators
VRDeviceManager: Managing 3 virtual devices
VRDeviceManager: Initializing 1 device driver modules
OpenVRHost: Starting event processing
OpenVRHost: Initializing OpenVR driver module
OpenVRHost: Error: Requested server interface IVRRenderModels_006 not found
OpenVRHost: Error: Requested server interface IVRRenderModelsInternal_001 not found
OpenVRHost: Error: Requested server interface IVRSettingsInternal_001 not found
OpenVRHost: Error: Requested server interface IVRPaths_001 not found
OpenVRHost: Error: Requested server interface IVRPathsInternal_001 not found
OpenVRHost: Error: Requested server interface IVRServer_XXX not found
OpenVRHost: Error: Requested server interface IVRCompositorInternal_001 not found
OpenVRHost: Error: Requested server interface IVRClientInternal_001 not found
OpenVRHost: Error: Requested server interface LocalizationManager not found
OpenVRHost: Error: Requested server interface IVRCompositorSystemInternal_001 not found
OpenVRHost: Error: Requested server interface IVRInputInternal_002 not found
OpenVRHost: Error: Requested server interface IVRChaperoneInternal_001 not found
OpenVRHost: Error: Requested server interface IVRApplications_006 not found
OpenVRHost: Error: Requested server interface IVRSystem_019 not found
OpenVRHost: Error: Requested server interface IVRMailbox_001 not found
OpenVRHost: Error: Requested server interface IVRPaths_001 not found
Segmentation fault (core dumped)
Progress! :) --If you are running Ubuntu 16.04, you should install the HWE (see: https://wiki.ubuntu.com/Kernel/LTSEnablementStack )
If you install the HWE stack or had to install updated Nvidia display drivers, you will need to restart your computer before things start working properly.
At this point, I would say that you should update to using the newest Vrui library. Every set of SteamVR and Vrui library doesn't interoperate. (There are ways to downgrade SteamVR to compatible versions if necessary, but you usually just want to use the newest versions of both.) You've already generated tracking.cpp, so that should be fine, and CMakeLists.txt can have that "set()" line rewritten to look for the newest version of Vrui instead.
If I remember correctly, you may also need to make sure SteamVR is running in the background first, too, before starting Vrui. (Sorry, silly of me to say this, but I've forgotten this myself on occasion.)
I'd also recommend running a couple of the Vrui test scripts and programs first to debug (/ make sure that Vrui is working correctly with SteamVR itself).
Nvidia drivers are already installed on the system I am working on, although I don't know how old they are. That may become an issue at some point.
I upgraded to the newest version of the Vrui library, but that didn't fix anything. I also noticed that the version of SteamVR that Vrui is designed to work with is listed, so I downgraded SteamVR using the guide here. RunViveTracker.sh now runs with minimal errors shown, and does not exit automatically.
Now I need to generate vrui_mdf from Vrui-4.6-005 and compile it.
There is something that was added to the DeviceTest.cpp file in the Vrui library between 4.5-001 and 4.6-005 which messed up the tracking.cpp file generated by cod_edi.py. Changing wanttedlinesnum to the following value fixed this issue,
wanttedlinesnum = [24,25,27,28,29,32,35,38,39,41,43,44, #header files 12
46,47,48,49,50,51,231,232,233,234,235, #definations 11
520,521, #main() 2
523,526,528,625,635, #definations in main() 5
636,637,638,639,640,641,642,643,644, #first try loop 9
814,815, #defination timer 2
816,817, #main try loop 2
818,819,820, #activate&startStream 3
821,822, #defination 2
826,827,828, #defination in while loop 3
833,834,855, #lockState define state 3
859, #unlockState() 1
935,936,937,938,939,940,941,942,943, #key checking 9
946, #getPacket 1
949,950,951,954,955, #end of the main try loop 5
956,957,958,959,960,961,962,963,964,965,966,971,972, #finishing up 13
973] #end of the main() 1...Ah, quick question. Are you doing this on a Windows machine? These don't look like the commandline Linux instructions for a downgrade... There is a ROS# + Unity + ROS + Gazebo solution that doesn't really require vrui_mdf, if you are wanting to (largely) work under Windows and/or just have a VM or second system running ROS and Gazebo for you. What is your use case?
(Note to self, need to get cmd line strings from Zhenyu. General Linux instruction pages are:
https://developer.valvesoftware.com/wiki/SteamCMD
OSVR/OSVR-Vive#20 )
I am running Ubuntu. The guide was definitely written for windows, but running steam -console on linux enabled the console tab.
Okay, cool. Glad there's an alternate method to "fall back" on if the Steam versions don't want to play nice via the command line with steamcmd.
I got it working with my gazebo simulation! This blog post was absolutely crucial for me to get the last bit of this set up. Thank you for all your help, and let me know if there is anything you would like me to test.
Excellent! Congrats! Glad it's working :)
We're working on the autoinstall stuff on this end. We may ask you to test a new update potentially, as long as it won't break your setup? (We're looking to try and implement the use of direct mode with vrui_mdf, not just extended mode, now that SteamVR for Linux is no longer in beta. There are a few things we'll be tweaking to try and increase the display speed (fps) under Ubuntu with Vrui as well.)
Thank you for letting us know what worked for you along the way! This will help us a lot with the updates we're doing to the repo and the install and 'error resolution' instructions.
I am willing to test any new updates.