`psmove_tracker_new` freezes the application

[PolGraphic]

Hi.
I've compiled the libpsmoveapi_tracker.dll from psmoveapi. The PS Move is already working fine, but now I wanted to use the tracker.

I am working in Unity 5.0.1. The problem is, when I call to either psmove_tracker_new or psmove_tracker_new_with_camera (with parameter 0 or 1 as I have both PS Eye and default laptop camera attached), the Unity project freezes along with the Unity itself (infinite loop, another thread or something?).

I guess that the psmove_tracker_new should either success or fail, not freeze the application.

The situation is exactly the same for both connected and disconnected PS Eye.

I've installed the PS Move (I already have an working orientation/buttons/bulb color in Unity) & PS Eye property.

I work with x64 code / DLLs, on Windows 8.1 x64.
I use libusbK and not the CL Eye Driver. The "frozen" application consumes much of CPU.

While compiling the psmoveapi, I've used:
cmake .. -G "MinGW Makefiles" -DPSMOVE_USE_LOCAL_OPENCV=1.
As cboulay explained in another issue, I've used the option(PSMOVE_USE_MADGWICK_AHRS "Use AHRS algorithm (GPL license)" ON) while compiling the source code.
I was following the great tutorial by cboulay: https://github.com/cboulay/psmove-ue4/wiki/Windows-PSEye-Setup

---

When I've added some printf to the code, I see that those lines of psmove_tracker.c are responsible for infinite loop:

IplImage* frame = NULL; while (!frame) { frame = camera_control_query_frame(tracker->cc, NULL, NULL); }

[cboulay]

If test_tracker works, and you're compiling the psmoveapi_tracker.dll together with test_tracker, then there's no reason why calling those functions shouldn't work.

Are you sure Unity is expecting 64-bit binaries?

Which README did you follow when you compiled? The cmake command I use is actually much longer than that. See here

[PolGraphic]

I've re-checked the test_tracker and unfortunately it was working yesterday, but not today (for some reason).

So whenever I use the Unity + dll, c++ program + dll or just test_tracker or anything that calls to psmove_tracker_new, when the code reaches while (!frame) { frame = camera_control_query_frame(tracker->cc, NULL, NULL); } of psmove_tracker.c, it never leaves the loop.

Sorry for not checking the test_tracker again today.

I was following the https://github.com/thp/psmoveapi/blob/master/README.win32 and the test_tracker.exe was (for 100%) working yesterday. I've not made the changes to software/hardware today.

The PS Move camera is listed in my Device Manager (libusb-win32 devices etc.), when I connect it to usb, the LED on it goes blue.

[cboulay]

The notes in that README that you have/want to compile for 32-bit are outdated. That's not necessary anymore. I've mentioned this before, but I've lost track of the changes I've made to make things work in Windows. Many are upstream in thp's repo, but not all. Try my fork to see if it works and follow the README I linked above. Or, if you prefer Visual Studio, try that README instead.

Also, get ps3eye_sdl.exe and SDL2.dll from here. Those can test your camera without using the psmoveapi. If those don't work, then your camera isn't working properly and it probably has nothing to do with the psmoveapi.

If both of the above work, then the problem is something specific to thp's psmoveapi. Take a look at #162 (not yet merged) to see if that helps.

[PolGraphic]

Ok. Your ps3eye_sdl.exe works fine (I see the camera input). Moreover, your test_tracker (from your repo) works too and the one form psmoveapi does not work on my laptop.

Then, I will switch to your fork. I am using it for Unity, but I guess that's not the problem (your repo is an independent fork and I can use the api without using the ue4 plugin itself)?

P.s. I wish I could buy you a dinner or something, for all the help you give me lately on this and other issues on github.

[cboulay]

One more thing I just remembered...
The camera has to be specified at compile time. i.e., if you build psmoveapi for using the PSEye, then you can only use the PSEye. You need separate binaries if you want to use the webcam. Yes, we know this is silly and we've discussed changing it, but no one has the time.

[cboulay]

Just pay it forward to the community. Improve the code, or make your own repo for all the Unity-specific stuff with documentation on how to get it all running with some examples.

The easier the user experience -> the more people will use it -> the more likely it is someone will improve it.

If you want a list of things to work on just let me know.

[PolGraphic]

That's good to know (about the PSEye compile-time camera).

I'm quite busy with the project I am working on right now (which involves PS Move & Oculus Rift), but I will definitely make an repo for Unity Plugin and post any improvements there (if they will be worth it) at the time I will be sure that everything is stable. With some step-by-step documentation.

[cboulay]

I've never used Unity or looked at UniMove, but why didn't you go that route?

Me, a student working with me, @Fredz66 (see here ) are all working on getting the PSMove working with the Oculus Rift. One hurdle that's slowing us down a bit is co-registration. Once the PSEye and DK2 are placed you have to figure out the transform between the two coordinate systems. The DK2 camera only sees IR, the PSEye has an IR filter and only sees visible light.

See Fred's repo for links to the oculus forum thread where this was talked about at length.

I think that the student and I, for our next case (when we do research in humans), will simply place the two cameras next to each other as aligned as possible, press the PSMove sphere to the face of the DK2, then press a button to re-zero the PSMove to that location (not a transformation, just a 3D pos subtraction). And we'll only use a sphere for feedback, so the rotation won't matter.

[Fredz66]

@PolGraphic

You may have a look here for an updated version of UniMove that supports positional tracking with the stock PS Move API, the original UniMove only supported orientation tracking : https://www.youtube.com/watch?v=FrJGh6AQmf4

I didn't update it yet for @cboulay version of the PS Move API but I'll do when I'm finished with the coregistration implementation. Even with manually aligned cameras it was basically unusable in VR because the tracking was not 1:1, that's why I'm concentrating my efforts on coregistration for now.

[PolGraphic]

For my game I've used the PS Eye position tracking + some casting position on the cylinder to get the ray. That "cheat" worked for my game because the person was standing in one place, with hand straighten.

For the universal solution, I will surely check out the update of UniMove.

[thp]

Closing this as outdated. Please reopen if it's still an issue.