Project doesn't run on Linux yet

[HipsterSloth]

It should be close because most of the systems have been written using cross platform APIs. The one remaining hole is the bluetooth sub system. Each OS has their own gross custom layer for handling pairing and unpairing of devices. The Linux implementation isn't implemented yet. I have half of the implementation of the Linux device written on laptop at home. I'll check this in soon in a commented out state.

[cboulay]

I have a linux box at home right now but only for the rest of the day. Let me know if you push your linux code and I can help test. I have a linux box at work too but there I have less time to test.

[HipsterSloth]

Oh sorry I should have been more clear, the linux code I have written is only about half done and no where near a testable state. Once I finish getting it written and compiling on my linux laptop I'll check it in.

[HipsterSloth]

Note to self, turn open cv camera support back on when I do this task. It's currently disabled at the moment.

[cboulay]

My new PC is now dual-boot Win/Linux. I decided to give building in Linux Ubuntu 16.04 a shot. Branch here.

I'm updating the Wiki as I go.

Some notes:

-We make a bunch of shared libraries that link against static libraries. For this to work on a x64-based system, the static libraries must be built with -fPIC. This is not the default for boost and protobuf. It also wasn't the default for our own static libs. I added instructions to the wiki to rebuild these libraries with the correct options, and modified the CMakeLists for our own static libs. However, instead of manually building these libraries with non-default options, it might be better in Linux to link against shared objects. It makes the built binaries less portable (i.e., we can't distribute a Linux build), but I don't think that was ever going to happen anyway.

-Basic apt-get version of boost is 1.58 so I modified the cmake files to accept that, even though presently I'm building boost from source and that's 1.61

-We already know the camera doesn't work.

-I imagine you already know the openvr_plugin doesn't work.

-TrackerDeviceEnumerator.cpp includes libusb.h to enumerate devices. However, libusb is only included via PS3EYEDriver here. I can install libusb (sudo apt-get install libusb-1.0-0-dev) and include it in Linux too, but all we're using it for is enumerating the trackers and getting an ID. Do we need to enumerate the trackers this way or can we just ask OpenCV for a list of cameras? (I remember we need to get more info from OpenCV; I haven't looked into that yet).

I'm tired and heading to bed.

[HipsterSloth]

Thanks for looking into this!

Would you like me to check in the partially completed USB controller pairing work I was doing a while ago or should I just wait until that's actually finished? It shouldn't affect the windows or OSX builds in it's current state because the cmake scripts specifically specify the platform specific bluetooth pairing implementation.

Do we need to enumerate the trackers this way or can we just ask OpenCV for a list of cameras?

I think we could re-write the camera enumeration to just use the opencv spin through camera indices, try and open each index, stop iterating once the first open fails. When I originally authored the camera enumerator I wanted to make the tracker manager poll regularly for newly attached cameras the same way we do for controllers. This turns out be problematic to do with libusb (doesn't play nice with other threads using libusb in windows). That's actually why we only enumerate the camera list once at service startup now. When I finish the opencv camera whitelist work next week (finishing up ds4 work this week) I'll try and clean out our usage of libusb.

[cboulay]

the opencv camera whitelist work

Are we going to have a whitelist? Or is it that all trackers will be disabled by default unless turned on explicitly by the config tool? (Is that what you meant by 'whitelist'?)

Would you like me to check in the partially completed USB controller pairing work [...]?

No, I'd rather wait until that's done to check it in. I may have to hunt around for libraries or modify cmake files for the intermittent version only for dependencies to change.

What I would like to know, though, is if this branch still builds for you. I made some non-linux-only changes (e.g., isnan --> std::isnan; if this doesn't work then Eigen::isnan is an option) and I'm worried they might break MSVC builds.

[HipsterSloth]

What I would like to know, though, is if this branch still builds for you.

Yep. I was able to build a fresh sync of the build_ubuntu_1604 branch in Debug|x64 and Release|x64.

Are we going to have a whitelist? Or is it that all trackers will be disabled by default unless turned on explicitly by the config tool? (Is that what you meant by 'whitelist'?)

Ah sorry that was unclear. To me, a "whitelist" means everything is denied by default unless you are on the approved list).

So in this case I was thinking at service start-up the tracker enumerator tries to test-open each camera (open, fetch properties, then close) through the opencv interface (1..k_max_trackers). We stop iterating at the first camera index we can no longer open (from what I've read this is apparently the gross but standard way of getting the camera list with OpenCV). Each tracker config has an "enabled" flag that is false by default. So the user has to open the tracker settings in the config tool and enable cameras that they want to use. Clicking the "enabled" flag will tell the service to actually open the camera. Turning enabled back off will close the camera.

I'm not sure what the best way to deal with the camera order changing since I'm not sure how to get a unqiue camera identifier (there is no "CAP_PROP_UNIQUE_ID" camera property).

[ChristophHaag]

This might be a stupid question, but I have the controllers paired with psmovepair from https://github.com/thp/psmoveapi and that project also has camera support for it with some demo applications to show it. Is there a reason to roll your own support for this stuff? I mean sure, for multiple camera support something custom is needed, but most of the hard work seems to be done there already. (They write bluez 5 config files manually, so that's not ideal, but it works).

[cboulay]

We had an e-mail conversation with Thomas (thp) about this several months ago. There are good reasons. I can forward you the message if you like.

After we're happy with PSMoveService functionality and it's stable, then we will see what core parts can be shared among psmoveapi and PSMoveService in a common static library, get psmoveapi modified so that it builds only that core library, then we can just include psmoveapi as a dependency. But PSMoveService isn't there yet; we don't know what the core library will look like.

And I apologize that Linux support isn't ready yet. It's important to me, but more important to me is that we get it working properly first. There are 2 things that need to be finished before I'm comfortable saying the usability is good enough to move on to portability concerns: Kalman filter (#13 ) and camera calibration. Without these then IMO we're not even returning usable data. The fact that some people are using it for VR games at all is baffling to me because I find the tracking to be nowhere good enough for an enjoyable experience, but I also have 2 Vives.