It is currently Wed Aug 23, 2017 7:47 am



Reply to topic  [ 344 posts ]  Go to page Previous  1 ... 4, 5, 6, 7, 8, 9  Next
 Razer hydra emulation 
Author Message
Cross Eyed!
User avatar

Joined: Thu Apr 09, 2015 4:27 am
Posts: 108
Reply with quote
InfinateXtremer wrote:
n8rockerasu wrote:
Got a chance to try Zelmon's newest FreePIE build and for whatever reason, everything is working fine now. I've even got the libusb-win32 driver on my PS Eye (which I do think runs smoother...all indications shows better fps with that driver than with CL Eye).

Into SteamVR with my DK2 I went. The first thing I noticed is that for some reason, the representation of the "Vive wands" in SteamVR was a bit twitchy. They would kind of shake back and forth in a real glitchy way. That sounds dumb describing it that way, but I'll try to grab some video of it later to better explain it.

Secondly, I'm pretty sure the yaw tracking doesn't need to be inverted. Using the latest script Zelmon posted (PSAPI_hydra2move_new6), when I would point one of the moves to the left, in SteamVR, it would point to the right. So, I changed "hydra[0].yaw = -psmove[0].yaw" to "hydra[0].yaw = psmove[0].yaw" for each controller and it fixed it.

Not sure if anybody else ran into that or if it's somehow backward for me. A good game to test this in is "Skeet: VR Target Shooting". It's a very simple game, but gives a decent sense of aiming and real gaming usefulness (and it loads about a million times faster than "The Lab"...which I love, but that game is a pain, man).

One other thing, I definitely notice the difference in raising the multiplying factor. I almost think it might be a bit too high now though. It's nice to be able to cover more ground with smaller movements, but I found myself making very unnatural gestures to try to do things. Obviously, the tracking isn't totally 1:1 like with the Vive wands...and I'm not sure if we can ever get it there. But it's definitely getting closer, and that's encouraging. The effort everybody is putting into this is greatly appreciated.


You're right about yaw, it doesn't need to be inverted like moveframework.
This time i inverted pitch, position z and x (don't trust me on this one i quickly tested it and had no problems.)

You're also right about multiplying factor, it's definately not 1:1 but we can fine tune-it. I actually halfed z x y values so they are z=100 x=50 y=50 it's not perfect but it's something.


@InfinateXtremer Are the PSMoveAPI scripts still crashing for you? If you're able to run the MoveFramework scripts I think that means that you're running the wrong plugin. The plugin in the last build I posted is the one for PSMoveAPI and it also contains the needed DLLs.

For me the yaw does need to be inverted. I tested this with the sixense sample program sixense_simple3d and awkardly in SteamVR (I'm having to emulate a HMD using VRidge :) - hence why I don't have such a good sense of scale for the position multipliers).

@n8rockerasu To smooth out the motion you can use
Code:
   hydra[0].x = filters.simple(-psmove[0].position.x, 0.5) * 50
   hydra[0].y = filters.simple( psmove[0].position.y, 0.5) * 50
   hydra[0].z = filters.simple(-psmove[0].position.z, 0.8) * 100
   # (adjust numbers to taste)


@troziepoo I'll have a look at adding in the missing sharp shooter buttons. I was able to add the missing racing wheel triggers etc so it should be sort of the same deal :).


Sat May 14, 2016 7:36 pm
Profile
One Eyed Hopeful

Joined: Fri Jul 31, 2015 11:31 am
Posts: 14
Reply with quote
I fixed crashing turns out all i needed to do was unplug and replug camera :D


Sun May 15, 2016 6:57 am
Profile
Cross Eyed!
User avatar

Joined: Thu Apr 09, 2015 4:27 am
Posts: 108
Reply with quote
@troziepoo here's the new version I promised with Sharp Shooter (and racing wheel) support (plugin and DLLs only). The relevant code is:

Code:
   diagnostics.watch(psmove[0].shooter.fire) # true when pressed
   diagnostics.watch(psmove[0].shooter.rl) # true when pressed
   diagnostics.watch(psmove[0].shooter.weapon) # one, two, or three depending on switch position


Although the fire trigger sets psmove[0].trigger = 255 and psmove[0].getButtonDown(PSMoveButton.Trigger) = true it can be used separately with an if statement like:
Code:
if (psmove[0].shooter.fire == False):
   hydra[0].trigger = psmove[0].trigger
   hydra[0].bumper = False
else :
   hydra[0].bumper = True


InfinateXtremer wrote:
I fixed crashing turns out all i needed to do was unplug and replug camera :D

haha :). I had that trouble a couple of times when I was using the CL-eye driver but hasn't seemed to be a problem since I swapped to libusb-win32. Which are you using?


You do not have the required permissions to view the files attached to this post.


Sun May 15, 2016 8:02 am
Profile
One Eyed Hopeful

Joined: Fri Jul 31, 2015 11:31 am
Posts: 14
Reply with quote
I am using CL-eye but i'm going to install libusb-win32 one today.


Sun May 15, 2016 8:09 am
Profile
One Eyed Hopeful

Joined: Sun Mar 29, 2015 2:10 am
Posts: 13
Reply with quote
zelmon freepie "relase" with "patch"
freepie crashing
test_opengl.exe from unity is working, libusb drivers
Any ideas?


Sun May 15, 2016 12:33 pm
Profile
Cross Eyed!
User avatar

Joined: Thu Apr 09, 2015 4:27 am
Posts: 108
Reply with quote
Remlas wrote:
zelmon freepie "relase" with "patch"
freepie crashing
test_opengl.exe from unity is working, libusb drivers
Any ideas?

Have you tried just using the build in this post? When does it crash - when you run freepie, start a script or stop it? Is it libusb-win32 you are using? Does it crash if you run a script that doesn't have any ps move bits?


Sun May 15, 2016 1:14 pm
Profile
One Eyed Hopeful

Joined: Sun Mar 29, 2015 2:10 am
Posts: 13
Reply with quote
zelmon64 wrote:
Remlas wrote:
zelmon freepie "relase" with "patch"
freepie crashing
test_opengl.exe from unity is working, libusb drivers
Any ideas?

Have you tried just using the build in this post? When does it crash - when you run freepie, start a script or stop it? Is it libusb-win32 you are using? Does it crash if you run a script that doesn't have any ps move bits?


Yes, build from linked post + viewtopic.php?f=139&t=18265&start=240#p161365 (also without this)

Crashing when starting script ( viewtopic.php?f=139&t=18265&start=200#p161344)
Ps-Eye with libusb-win32 driver (camera is working in unity tests like opengl_test.exe)
Orbs not lighting up, even camera don't turn on red led.
2 motion moves, native windows bt stack,
Freshly installed win10proX64 (for testing


Sun May 15, 2016 1:26 pm
Profile
Cross Eyed!
User avatar

Joined: Thu Apr 09, 2015 4:27 am
Posts: 108
Reply with quote
Remlas wrote:
zelmon64 wrote:
Remlas wrote:
zelmon freepie "relase" with "patch"
freepie crashing
test_opengl.exe from unity is working, libusb drivers
Any ideas?

Have you tried just using the build in this post? When does it crash - when you run freepie, start a script or stop it? Is it libusb-win32 you are using? Does it crash if you run a script that doesn't have any ps move bits?


Yes, build from linked post + viewtopic.php?f=139&t=18265&start=240#p161365 (also without this)

Crashing when starting script ( viewtopic.php?f=139&t=18265&start=200#p161344)
Ps-Eye with libusb-win32 driver (camera is working in unity tests like opengl_test.exe)
Orbs not lighting up, even camera don't turn on red led.
2 motion moves, native windows bt stack,
Freshly installed win10proX64 (for testing

You may need to install Visual C++ Redistributable for Visual Studio 2015 (I can't seem to find the build option to check if it's being included automatically) and possibly .NET Framework.


Sun May 15, 2016 1:49 pm
Profile
Cross Eyed!
User avatar

Joined: Thu Apr 09, 2015 4:27 am
Posts: 108
Reply with quote
For anyone wondering why the emulated trigger flaps around so wildly when pressed, it's because the hydra wants a value betreen zero and one instead of 255. Simply divide by 255.0 (".0" to make it a float instead of an int) to correct this.
Code:
hydra[1].trigger = psmove[1].trigger / 255.0


Sun May 15, 2016 3:09 pm
Profile
One Eyed Hopeful

Joined: Thu Oct 17, 2013 2:33 am
Posts: 35
Reply with quote
Yup...back to crashing for me too. Not sure what is going on, but it feels super inconsistent. I have both C++ VS 2015 and .NET Framework...and I've been able to run things previously. So, I can't imagine it's something I'm missing. And I am using libusb-win32 with my camera. Every time I click "start script" FreePIE crashes with the error "FreePIE.GUI has stopped working". I've tried unplugging my camera and plugging it back in, but it's still crashing every time now.


Sun May 15, 2016 3:13 pm
Profile
One Eyed Hopeful

Joined: Fri Jul 31, 2015 11:31 am
Posts: 14
Reply with quote
n8rockerasu wrote:
Yup...back to crashing for me too. Not sure what is going on, but it feels super inconsistent. I have both C++ VS 2015 and .NET Framework...and I've been able to run things previously. So, I can't imagine it's something I'm missing. And I am using libusb-win32 with my camera. Every time I click "start script" FreePIE crashes with the error "FreePIE.GUI has stopped working". I've tried unplugging my camera and plugging it back in, but it's still crashing every time now.


It's super inconsistent, i'm also getting crashes... again :D changed to libusb-win32 still getting crashes and now i can't even get FreePIE GUI i can only see it from task manager.


Sun May 15, 2016 3:23 pm
Profile
Cross Eyed!
User avatar

Joined: Thu Apr 09, 2015 4:27 am
Posts: 108
Reply with quote
InfinateXtremer wrote:
n8rockerasu wrote:
Yup...back to crashing for me too. Not sure what is going on, but it feels super inconsistent. I have both C++ VS 2015 and .NET Framework...and I've been able to run things previously. So, I can't imagine it's something I'm missing. And I am using libusb-win32 with my camera. Every time I click "start script" FreePIE crashes with the error "FreePIE.GUI has stopped working". I've tried unplugging my camera and plugging it back in, but it's still crashing every time now.


It's super inconsistent, i'm also getting crashes... again :D changed to libusb-win32 still getting crashes and now i can't even get FreePIE GUI i can only see it from task manager.

I can't figure out why I'm not getting all these crashes (apart from when I break something in a new build). Here's the complete build folder again.

Here's my system specs for comparison:
    Intel Core i5 4690K Processor (3.5 GHz)
    Crucial Ballistix 8GB (4GBx 2) DIMM DDR3 PC3-12800
    MSI Z97 Gaming 7 Motherboard
    PNY Geforce GTX 660 XLR8 NVIDIA Graphics Card (2GB GDDR5)
    Windows 10 Pro N 64-bit
FreePIE runs at about 25% CPU load out of a total load of 30% when using two moves.

I have both x64 and x86 versions of ms Visual C++ redist 2005, 2008, 2010, 2012, 2013 and 2015 and .NET 4.5, 4.5.1, 4.5.2, 4.6, and 4.6.1 (I didn't realise I had so many).

I also have SCPDriver running in the background (but that's for a separate nav I use as a mouse). There's also a Windows 8.1 partition but I can't see that affecting anything.

I'm using a USB 3.0 port in my motherboard and a 5m extension cable (USB 2.0) for the PS EYE and a random Chinese Bluetooth 4.0 adapter also connected to a USB 3.0 port in my motherboard but on a ~1m USB 3.0 extensoin cable.

I'm then using VRidge (over wifi - pc connected to hub via ethernet then wifi to android phone) to emulate a HMD so that I can use SteamVR.

[edit]
Also I'm not running FreePIE in "C:\Program Files (x86)" (although I do have an older version installed there). I'm building it on a separate internal HDD and so running it from there in portable mode.


You do not have the required permissions to view the files attached to this post.


Sun May 15, 2016 4:06 pm
Profile
One Eyed Hopeful

Joined: Thu Oct 17, 2013 2:33 am
Posts: 35
Reply with quote
Well, the newest version Zelmon just posted was crashing for me just the same as the others.

So, I went into full on troubleshooting mode, tried a bunch of different scripts...all crashed. Tried running the latest stable release of FreePIE on github (1.9.629) installed to my Program Files (x86) folder, but added Zelmon's PSAPI dll files and the FreePIE.Core plugin...still crashed every script. Downloaded the last Zelmon release that was working for me the other day (viewtopic.php?f=139&t=18265&start=200#p161346)...and I still got crashes (WTF right?)

On a hunch, I decided to uninstall the libusb-win32 driver and reinstall CL-eye. After installation, I again started my last working FreePIE build, ran one of the most recent scripts (PSAPI_hydra2move_new6)...and it worked. Both Moves lit up and the red light turned on on the camera.

Now we're talking. Next, I tried the build that Zelmon just posted...and it also worked.

Just to put the final nail in and remove all doubt, I reinstalled the libusb-win32 driver, went back to FreePIE...and boom...crash every time.

SO...something is off with libusb-win32. Are we missing a dll file or something in the FreePIE folder? Is the driver just not very stable? Unless I just got lucky, all signs would seem to point to the camera driver creating some kind of issue or incompatibility.

Just for reference, my system specs:

Intel Core i5 4690K (3.5Ghz)
Kingston HyperX FURY 16GB (8GBx2) DIMM DDR3 PC3-1280
Gigabyte GA-Z97X-UD3H-BK Motherboard
EVGA NVidia GTX 970 SC ACX 2.0 (4GB GDDR5)
Windows 10 Pro 64-bit


Sun May 15, 2016 5:48 pm
Profile
One Eyed Hopeful

Joined: Tue May 10, 2016 9:15 pm
Posts: 15
Reply with quote
n8rockerasu wrote:
Well, the newest version Zelmon just posted was crashing for me just the same as the others.

So, I went into full on troubleshooting mode, tried a bunch of different scripts...all crashed. Tried running the latest stable release of FreePIE on github (1.9.629) installed to my Program Files (x86) folder, but added Zelmon's PSAPI dll files and the FreePIE.Core plugin...still crashed every script. Downloaded the last Zelmon release that was working for me the other day (viewtopic.php?f=139&t=18265&start=200#p161346)...and I still got crashes (WTF right?)

On a hunch, I decided to uninstall the libusb-win32 driver and reinstall CL-eye. After installation, I again started my last working FreePIE build, ran one of the most recent scripts (PSAPI_hydra2move_new6)...and it worked. Both Moves lit up and the red light turned on on the camera.

Now we're talking. Next, I tried the build that Zelmon just posted...and it also worked.

Just to put the final nail in and remove all doubt, I reinstalled the libusb-win32 driver, went back to FreePIE...and boom...crash every time.

SO...something is off with libusb-win32. Are we missing a dll file or something in the FreePIE folder? Is the driver just not very stable? Unless I just got lucky, all signs would seem to point to the camera driver creating some kind of issue or incompatibility.

Just for reference, my system specs:

Intel Core i5 4690K (3.5Ghz)
Kingston HyperX FURY 16GB (8GBx2) DIMM DDR3 PC3-1280
Gigabyte GA-Z97X-UD3H-BK Motherboard
EVGA NVidia GTX 970 SC ACX 2.0 (4GB GDDR5)
Windows 10 Pro 64-bit


I remember reading something from a fair few years ago about this, can't remember exactly what it was but the resolution was try using different usb ports, possibly if you have multiple USB controllers on your motherboard, such as intel controller for USB 2.0 and renesas controller for USB 3.0.


Sun May 15, 2016 6:14 pm
Profile
One Eyed Hopeful

Joined: Tue May 10, 2016 9:15 pm
Posts: 15
Reply with quote
InfinateXtremer wrote:
Happy to help, also are you having any problems with steamvr? when i rotate ps move to back my whole tracking is reversed.


I did have this problem when I first got it working but then ran out of time but have seen you guys have solved it anyway ;).


zelmon64 wrote:
@troziepoo here's the new version I promised with Sharp Shooter (and racing wheel) support (plugin and DLLs only). The relevant code is:

Code:
   diagnostics.watch(psmove[0].shooter.fire) # true when pressed
   diagnostics.watch(psmove[0].shooter.rl) # true when pressed
   diagnostics.watch(psmove[0].shooter.weapon) # one, two, or three depending on switch position


Although the fire trigger sets psmove[0].trigger = 255 and psmove[0].getButtonDown(PSMoveButton.Trigger) = true it can be used separately with an if statement like:
Code:
if (psmove[0].shooter.fire == False):
   hydra[0].trigger = psmove[0].trigger
   hydra[0].bumper = False
else :
   hydra[0].bumper = True



Awesome work dude. I'll test it when I get home from work tonight and let you know the results. I'm surprised about RL because windows game controllers didn't even detect that a button was pressed but I did read on psmoveapi wiki that they have been able to get all buttons working so I guess it was always possible.


Sun May 15, 2016 6:22 pm
Profile
One Eyed Hopeful

Joined: Thu Oct 17, 2013 2:33 am
Posts: 35
Reply with quote
troziepoo wrote:
I remember reading something from a fair few years ago about this, can't remember exactly what it was but the resolution was try using different usb ports, possibly if you have multiple USB controllers on your motherboard, such as intel controller for USB 2.0 and renesas controller for USB 3.0.


Well, I'm hoping there's a better fix than "a different USB port". Just gotta track down what the exact problem is and what's causing it.


Sun May 15, 2016 9:06 pm
Profile
One Eyed Hopeful

Joined: Tue May 10, 2016 9:15 pm
Posts: 15
Reply with quote
n8rockerasu wrote:
troziepoo wrote:
I remember reading something from a fair few years ago about this, can't remember exactly what it was but the resolution was try using different usb ports, possibly if you have multiple USB controllers on your motherboard, such as intel controller for USB 2.0 and renesas controller for USB 3.0.


Well, I'm hoping there's a better fix than "a different USB port". Just gotta track down what the exact problem is and what's causing it.


Give it a shot to at least troubleshoot it, might be as simple as updating your bios or chipset drivers.


Sun May 15, 2016 10:23 pm
Profile
One Eyed Hopeful

Joined: Thu Oct 17, 2013 2:33 am
Posts: 35
Reply with quote
troziepoo wrote:
n8rockerasu wrote:
troziepoo wrote:
I remember reading something from a fair few years ago about this, can't remember exactly what it was but the resolution was try using different usb ports, possibly if you have multiple USB controllers on your motherboard, such as intel controller for USB 2.0 and renesas controller for USB 3.0.


Well, I'm hoping there's a better fix than "a different USB port". Just gotta track down what the exact problem is and what's causing it.


Give it a shot to at least troubleshoot it, might be as simple as updating your bios or chipset drivers.


Well, I tried it. Updated the bios on my motherboard, plugged into two different USB ports (a 3.0 and a 2.0 that were direct lines into the motherboard...as opposed to front ports on my case). I even unpaired and repaired the Move controllers to make sure all of the steps were done in proper order. Once I finally got everything set back up, I loaded up the script in FreePIE, pressed "Run Script"...and it crashed instantly.

I just have zero luck with libusb-win32. It is murdering any Move functionality I've got right now. Naturally, when I went back to CL-eye, the script ran just fine. On the bright side, the tracking is getting closer and closer to being fully functional. The biggest problem I have is when turning to face away from the camera (not even a full 180 degree turn...maybe something like 120 degrees), the orientation goes way off. It starts to twist and tilt like all of the axis are going crazy. This makes games that need a big range of movement (like Brookhaven Experiment) mostly unplayable.

I know HipsterSloth made that Reddit post a week or so ago about a full on SteamVR plugin and service for the Move. So, I'm not sure if what we're doing is just redundant anyway. But hopefully the more minds working on this, the better the results will be. Because PS Move is definitely the way to go for anybody who doesn't have $800 to buy a Vive.


Mon May 16, 2016 6:54 pm
Profile
One Eyed Hopeful

Joined: Tue May 10, 2016 9:15 pm
Posts: 15
Reply with quote
zelmon64 wrote:
@troziepoo here's the new version I promised with Sharp Shooter (and racing wheel) support (plugin and DLLs only). The relevant code is:

Code:
   diagnostics.watch(psmove[0].shooter.fire) # true when pressed
   diagnostics.watch(psmove[0].shooter.rl) # true when pressed
   diagnostics.watch(psmove[0].shooter.weapon) # one, two, or three depending on switch position


Although the fire trigger sets psmove[0].trigger = 255 and psmove[0].getButtonDown(PSMoveButton.Trigger) = true it can be used separately with an if statement like:
Code:
if (psmove[0].shooter.fire == False):
   hydra[0].trigger = psmove[0].trigger
   hydra[0].bumper = False
else :
   hydra[0].bumper = True



Only had about 15 minutes for a quick test last night but I think it might need a little tweaking.

Only working on single fire mode of the Sharp Shooter, 2 and 3 didn't detect them.

All 3, trigger, RL and bumper are coming through individually but they're random and laggy, one press it will work the next it might not and the next it will work but will take a second to register that it did.

I'll check it out when I get some time, it might just be where I put it in the script or something.


Mon May 16, 2016 7:22 pm
Profile
One Eyed Hopeful

Joined: Tue May 10, 2016 9:15 pm
Posts: 15
Reply with quote
troziepoo wrote:
zelmon64 wrote:
@troziepoo here's the new version I promised with Sharp Shooter (and racing wheel) support (plugin and DLLs only). The relevant code is:

Code:
   diagnostics.watch(psmove[0].shooter.fire) # true when pressed
   diagnostics.watch(psmove[0].shooter.rl) # true when pressed
   diagnostics.watch(psmove[0].shooter.weapon) # one, two, or three depending on switch position


Although the fire trigger sets psmove[0].trigger = 255 and psmove[0].getButtonDown(PSMoveButton.Trigger) = true it can be used separately with an if statement like:
Code:
if (psmove[0].shooter.fire == False):
   hydra[0].trigger = psmove[0].trigger
   hydra[0].bumper = False
else :
   hydra[0].bumper = True



Only had about 15 minutes for a quick test last night but I think it might need a little tweaking.

Only working on single fire mode of the Sharp Shooter, 2 and 3 didn't detect them.

All 3, trigger, RL and bumper are coming through individually but they're random and laggy, one press it will work the next it might not and the next it will work but will take a second to register that it did.

I'll check it out when I get some time, it might just be where I put it in the script or something.


Haha cancel that, it's all working perfectly, looks like it happens when you don't have a proper connection with the move controller to the sharp shooter.


Tue May 17, 2016 2:21 am
Profile
Cross Eyed!
User avatar

Joined: Thu Apr 09, 2015 4:27 am
Posts: 108
Reply with quote
troziepoo wrote:
troziepoo wrote:

Only had about 15 minutes for a quick test last night but I think it might need a little tweaking.

Only working on single fire mode of the Sharp Shooter, 2 and 3 didn't detect them.

All 3, trigger, RL and bumper are coming through individually but they're random and laggy, one press it will work the next it might not and the next it will work but will take a second to register that it did.

I'll check it out when I get some time, it might just be where I put it in the script or something.


Haha cancel that, it's all working perfectly, looks like it happens when you don't have a proper connection with the move controller to the sharp shooter.


Oh good :). I was going to try and make a video (but couldn't seem to find any good software - any recommendations?). You can reconnect the shooter (or wheel) while the script is running and it should say in the console what is connected and when it gets disconnected. It also seems to work fine with multiple devices.

How is the orientation for you? I thought I had already fixed the issue n8rockerasu is having. It works fine for me with the latest build I posted. The issue was with the conversion from the quaternion to the pitch/yaw/roll. I use:
Code:
      hydra[0].yaw = - psmove[0].yaw
      hydra[0].pitch = - psmove[0].pitch
      hydra[0].roll = psmove[0].roll

and the sixense sample sixense_simple3d.exe to test.


Tue May 17, 2016 3:55 am
Profile
One Eyed Hopeful

Joined: Tue May 10, 2016 9:15 pm
Posts: 15
Reply with quote
Yeah I saw the disconnected message while I was fiddling with it ;)

I haven't tested the orientation yet, I will tonight and let you know. The last time I used it was working great but in reverse but that was a few days ago and that's been solved.

I did start work on a keyboard/mouse script for the sharpshooter and mapped everything around the Doom control scheme just for initial testing without a HMD.
I have got mouse movement working but it's pretty choppy at this point, I'm using:

Code:
mouse.deltaX = filters.delta(filters.continuousRotation(psmove[0].yaw)) * 1000
mouse.deltaY = filters.delta(filters.continuousRotation(psmove[0].pitch)) * 1000


Just had a look at how people are doing it for the wiimote and found this:

Code:
mouse.deltaX = filters.deadband(filters.delta(wiimote[0].ahrs.yaw), 0.1) * 10
mouse.deltaY = filters.deadband(-filters.delta(wiimote[0].ahrs.pitch), 0.1) * 10


Will give that a shot tonight too but question: do we have to do anything special to tap into the psmoveapi ahrs algorithm or is it just baked in by default?


Tue May 17, 2016 7:29 pm
Profile
One Eyed Hopeful

Joined: Tue May 10, 2016 9:15 pm
Posts: 15
Reply with quote
Hmmmmm, just discovered this http://sixense.com/motioncreator, might not have to rewrite anything at all.

Has anyone used it?


Tue May 17, 2016 8:01 pm
Profile
Cross Eyed!
User avatar

Joined: Thu Apr 09, 2015 4:27 am
Posts: 108
Reply with quote
troziepoo wrote:
Hmmmmm, just discovered this http://sixense.com/motioncreator, might not have to rewrite anything at all.

Has anyone used it?

That looks cool :) . I just tried replacing the fake sixsense.dll but it wouldn't run after that. It said that it couldn't find certain entry points in the motioncreatorengine.dll and motioncreator.exe :(. I don't know if we can change sixense_fake.dll to make it work?

[edit]
troziepoo wrote:
Will give that a shot tonight too but question: do we have to do anything special to tap into the psmoveapi ahrs algorithm or is it just baked in by default?

I'm pretty sure that it's already using an ahrs algorithm. They discuss the new one which improved the yaw drift here. The wiimote doesn't have a way to retrieve the orientation without putting .ahrs before the yaw/pitch/roll. This is similar to how we now have to put .position before x, y or z whereas when using MoveFramework we didn't. It's just the way FreePIE is set up to call the DLLs (for instance I could make it so that psmove[0].jelly.raspberry gave the x direction of the magnetometer :)).


Last edited by zelmon64 on Wed May 18, 2016 4:51 pm, edited 1 time in total.



Wed May 18, 2016 2:41 am
Profile
One Eyed Hopeful

Joined: Fri Jul 31, 2015 11:31 am
Posts: 14
Reply with quote
Hello everyone i'm back! I had little bit of problems about my computer and i needed to reinstall my windows.

I don't know why but like n8rockerasu whenever i install libusb-win32 driver FreePIE not working until install CL-eye-Driver.

Also this time i'm having another problem when i run script nothing happens, no errors, no warnings, 2 minutes later one psmove lights up purple than again nothing happens.

My specs are

AMD FX-8350
Sapphire Amd R9 270
8-GB Ram
Windows 10 Pro 64-Bit


You do not have the required permissions to view the files attached to this post.


Wed May 18, 2016 11:01 am
Profile
Cross Eyed!
User avatar

Joined: Thu Apr 09, 2015 4:27 am
Posts: 108
Reply with quote
I'm trying to figure out why this isn't working for some people. I set up a new VM with Windows 10 but couldn't get anything PSMoveAPI related to work (though the MoveFramework version worked). I'm now trying a clean Windows 10 install on an older PC.

Here's my current build for anyone who wants it.


You do not have the required permissions to view the files attached to this post.


Fri May 20, 2016 9:54 am
Profile
One Eyed Hopeful

Joined: Thu Oct 17, 2013 2:33 am
Posts: 35
Reply with quote
zelmon64 wrote:
I'm trying to figure out why this isn't working for some people. I set up a new VM with Windows 10 but couldn't get anything PSMoveAPI related to work (though the MoveFramework version worked). I'm now trying a clean Windows 10 install on an older PC.

Here's my current build for anyone who wants it.


Appreciate you troubleshooting it. I got to a point where I kind of feel stuck. Getting it narrowed down to "something is wrong with libusb-win32" was the best I could do. After that, I just reinstalled CL-eye. I still have those orientation issues though where when I pass a certain rotation, the Moves just freak out. It starts to make me question if I've done all of the set up steps properly though...or if all of the various telemetry info is being read/tracked correctly.

I know in the MoveFramework days, there were different calibration methods, copying settings info, etc. I'm not really clear on how much of that is handled natively with PSMoveAPI. Maybe writing up a new "guide" would be beneficial to make sure we're all doing the same steps to get everything set up. I'm currently using the "psmove-unity5-master" exe's for most of my setup. (psmovepair, psmove-pair-win, magnetometer_calibration, etc). But at one point there was talk of Calibration Tool 3.2...and the MoveManager.dll in the FreePIE folder. I get a bit lost on what's not needed with PSMoveAPI anymore.


Fri May 20, 2016 12:17 pm
Profile
Cross Eyed!
User avatar

Joined: Thu Apr 09, 2015 4:27 am
Posts: 108
Reply with quote
n8rockerasu wrote:
zelmon64 wrote:
I'm trying to figure out why this isn't working for some people. I set up a new VM with Windows 10 but couldn't get anything PSMoveAPI related to work (though the MoveFramework version worked). I'm now trying a clean Windows 10 install on an older PC.

Here's my current build for anyone who wants it.


Appreciate you troubleshooting it. I got to a point where I kind of feel stuck. Getting it narrowed down to "something is wrong with libusb-win32" was the best I could do. After that, I just reinstalled CL-eye. I still have those orientation issues though where when I pass a certain rotation, the Moves just freak out. It starts to make me question if I've done all of the set up steps properly though...or if all of the various telemetry info is being read/tracked correctly.

I know in the MoveFramework days, there were different calibration methods, copying settings info, etc. I'm not really clear on how much of that is handled natively with PSMoveAPI. Maybe writing up a new "guide" would be beneficial to make sure we're all doing the same steps to get everything set up. I'm currently using the "psmove-unity5-master" exe's for most of my setup. (psmovepair, psmove-pair-win, magnetometer_calibration, etc). But at one point there was talk of Calibration Tool 3.2...and the MoveManager.dll in the FreePIE folder. I get a bit lost on what's not needed with PSMoveAPI anymore.


The results are in and I beleive I may have a solution. The short version is uninstall all PS Eye camera drivers in the device manager (right-click uninstall, check delete drive, scan for hardware changes, repeat uninstall again if there are still libusb or CL drivers latching onto the camera). Then launch zadig and install libusbK then select libusb-win32 and click Replace Driver then FreePIE should work. I restored my test rig twice to before I installed anything related and this seemed to work reliably.

For a fresh install first install the 2013 x64 and x86 versions of vcredist. Secondly use psmovepair.exe and psmove-pair-win.exe from HipsterSloth's psmove-unity5 to pair the ps moves. Thirdly install FreePIE, replace FreePIE.Core.Plugins.dll in the plugins folder with the one attached and place the attached libpsmoveapi.dll and libpsmoveapi_tracker.dll in the same folder as FreePIE.exe. Finally launch zadig and install libusbK then replace with libusb-win32. Then it should all work correctly with the attached script (I added a part where if you hold down square the orientation acts like the touch pad and cross is press - sensitivities and polarities may need adjusting to taste). magnetometer_calibration.exe can be run any time if desired (run from the command window to see error messages if needed).

I really hope this fixes it :)


You do not have the required permissions to view the files attached to this post.


Fri May 20, 2016 6:31 pm
Profile
One Eyed Hopeful

Joined: Thu Oct 17, 2013 2:33 am
Posts: 35
Reply with quote
Just wanted to pop in and say that this fix worked. I haven't had a chance to test it in SteamVR or anything outside of FreePIE yet. But for whatever reason, installing libusbK first, and then switching to libusb-win32 makes all the difference in the world. No idea why that is...but scripts now run just fine with zero crashes.

Going to try to test the new script in SteamVR and see if I notice any improvements in terms of general tracking or orientation. Great job finding that workaround though, Zelmon! :D


Sat May 21, 2016 3:16 pm
Profile
Cross Eyed!
User avatar

Joined: Thu Apr 09, 2015 4:27 am
Posts: 108
Reply with quote
n8rockerasu wrote:
Just wanted to pop in and say that this fix worked. I haven't had a chance to test it in SteamVR or anything outside of FreePIE yet. But for whatever reason, installing libusbK first, and then switching to libusb-win32 makes all the difference in the world. No idea why that is...but scripts now run just fine with zero crashes.

Going to try to test the new script in SteamVR and see if I notice any improvements in terms of general tracking or orientation. Great job finding that workaround though, Zelmon! :D

Oh good, that's fantastic news :D ! I was worried that it might have been a fluke on my test rig.

I noticed that the trigger values were misbehaving around 120-160 so I fixed it with the attached DLLs.

I also noticed that the v1.0.1.7 release of betavr/steamvr_driver_hydra apparently fixed an incorrect rotation axis so if there is still some discrepancy with the orientation it may be because of this.

Lastly there was a typo on the last script I posted (number 9). On line 108 it reads "hydra[0].joyy = touchx_posy1" but it should be "hydra[1].joyy = touchx_posy1".


You do not have the required permissions to view the files attached to this post.


Sat May 21, 2016 4:22 pm
Profile
One Eyed Hopeful

Joined: Sat May 14, 2016 12:55 am
Posts: 4
Reply with quote
FreePIE sees the PS Move. Displays button presses, and position.
But how to make what PS Move SteamVR worked as a razer hydra ???


Sun May 22, 2016 5:43 am
Profile
Cross Eyed!
User avatar

Joined: Thu Apr 09, 2015 4:27 am
Posts: 108
Reply with quote
slavian wrote:
FreePIE sees the PS Move. Displays button presses, and position.
But how to make what PS Move SteamVR worked as a razer hydra ???

This guide at Tales From The Rift will walk you though setting up hydra support for SteamVR. Once that's done you simply replace the sixense.dll files in the "SteamVR Hydra Driver" folder that will be installed with the ones by CyberVillain on the first page of this thread. Have fun :D


Sun May 22, 2016 6:40 am
Profile
One Eyed Hopeful

Joined: Thu Oct 17, 2013 2:33 am
Posts: 35
Reply with quote
Well, good news and bad news. Good news is I'm still not getting crashes and scripts run just fine. Bad news...I'm getting some really freaky issues in SteamVR. I'm not sure if this is libusb-win32 related or if I've got other issues going on. But I've got one Move controller just glitching out like crazy. And then, I can't get consistent positioning resets either. Even If I'm just standing in the same place and do the "hold both controllers up and press the start button" (which is now mapped to the PS button, it seems), it actually resets the controllers in different locations without me moving. Using the FreePIE command of pressing both Cross buttons yields similar (though less unpredictable) results.

I recorded a video of it so you can see what I'm talking about. I don't think there's anything wrong with this build or what you've done that is causing this. I tried removing and repairing my Move controllers and it seemed to fix it (both Moves were stable). But then I had to change the yaw inversion in the script (yeah, mine still doesn't need to be inverted for whatever reason)...and when I restarted it, the left hand Move (ie. psmove[0]) started freaking out again. I couldn't get it to stop after that, and then I just got irritated and turned everything off.



Again, not really anything I expect a clear answer to. Just a frustrating issue that is going to slow down my testing. Feels like I'm fighting just to get them working right now. I might reinstall CL-eye later and see if that problem persists.


Sun May 22, 2016 4:28 pm
Profile
Cross Eyed!
User avatar

Joined: Thu Apr 09, 2015 4:27 am
Posts: 108
Reply with quote
n8rockerasu wrote:
Well, good news and bad news. Good news is I'm still not getting crashes and scripts run just fine. Bad news...I'm getting some really freaky issues in SteamVR. I'm not sure if this is libusb-win32 related or if I've got other issues going on. But I've got one Move controller just glitching out like crazy. And then, I can't get consistent positioning resets either. Even If I'm just standing in the same place and do the "hold both controllers up and press the start button" (which is now mapped to the PS button, it seems), it actually resets the controllers in different locations without me moving. Using the FreePIE command of pressing both Cross buttons yields similar (though less unpredictable) results.

I recorded a video of it so you can see what I'm talking about. I don't think there's anything wrong with this build or what you've done that is causing this. I tried removing and repairing my Move controllers and it seemed to fix it (both Moves were stable). But then I had to change the yaw inversion in the script (yeah, mine still doesn't need to be inverted for whatever reason)...and when I restarted it, the left hand Move (ie. psmove[0]) started freaking out again. I couldn't get it to stop after that, and then I just got irritated and turned everything off.

Again, not really anything I expect a clear answer to. Just a frustrating issue that is going to slow down my testing. Feels like I'm fighting just to get them working right now. I might reinstall CL-eye later and see if that problem persists.

I'm sorry to see that you're still having problems. Have you tried the sixense sample program which comes with the SDK? Also could you please confirm which version of betavr/steamvr_driver_hydra that you are currently using (I'm on v1.0.1.7)? How far from the ps eye were you (I'm normally 1m - 2m)?

What were the colours of the orbs when you did that video? I always get psmove[0] as purple and [1] as blue (I assume it's the default). I have had it once where one doesn't light up - it oriented the wand correctly but I couldn't reset the positions (sorry I forgot to mention the buttin change). When something like that happens I just re-run the FreePIE script and that fixes it.


Mon May 23, 2016 3:05 am
Profile
One Eyed Hopeful

Joined: Fri Jul 31, 2015 11:31 am
Posts: 14
Reply with quote
Zelmon tried your instructions and now everything works perfectly, i'm using libusb-win32, also i realized i need to reverse yaw in sixense_simple3d but not in steamvr, still having orientation issues on steamvr but nothing seems wrong on simple3d.


Mon May 23, 2016 10:11 am
Profile
One Eyed Hopeful

Joined: Thu Oct 17, 2013 2:33 am
Posts: 35
Reply with quote
zelmon64 wrote:
I'm sorry to see that you're still having problems. Have you tried the sixense sample program which comes with the SDK? Also could you please confirm which version of betavr/steamvr_driver_hydra that you are currently using (I'm on v1.0.1.7)? How far from the ps eye were you (I'm normally 1m - 2m)?

What were the colours of the orbs when you did that video? I always get psmove[0] as purple and [1] as blue (I assume it's the default). I have had it once where one doesn't light up - it oriented the wand correctly but I couldn't reset the positions (sorry I forgot to mention the buttin change). When something like that happens I just re-run the FreePIE script and that fixes it.


I didn't try the sixense sample program yesterday. I'll give that a shot today. If you notice in the video though, my FreePIE values for psmove[0] Position X and Y are going crazy. So, it seems that SteamVR is accurately portraying the readings it's receiving. That's why I honestly thought the problem was the BT sync with this controller. I'll try repairing again later and see if I can figure anything out.

I did update my SteamVR Hydra driver. I downloaded the latest version, which is v1.0.1.8. My distance from the PS Eye is about the same as yours. I've got it mounted on a shelf looking down (only way I could get a wide enough angle for SteamVR room scale with one camera), so it's about 2m above the floor...and I'm usually between 1-3m away from it.

The orbs are purple and blue just like yours. I tried changing colors with the different lines of code that were posted, but never got them to work. When I start your newest FreePIE script, psmove[0] orb flashes twice, then psmove[1] orb flashes twice, then both orbs stay on. Like I said, I think everything about what you've done is working fine. I think my issue is coming up before it even gets to FreePIE...either BT sync, camera driver, or possibly even Move hardware (probably not since it works with a PS3 just fine).

I'll try to get it figured out. Just wanted to let you know that if I'm quiet about your work, it's not because you did a bad job or I gave up on it, haha. Just computers being computers on my end.


Mon May 23, 2016 10:39 am
Profile
Cross Eyed!
User avatar

Joined: Thu Apr 09, 2015 4:27 am
Posts: 108
Reply with quote
n8rockerasu wrote:
zelmon64 wrote:
I'm sorry to see that you're still having problems. Have you tried the sixense sample program which comes with the SDK? Also could you please confirm which version of betavr/steamvr_driver_hydra that you are currently using (I'm on v1.0.1.7)? How far from the ps eye were you (I'm normally 1m - 2m)?

What were the colours of the orbs when you did that video? I always get psmove[0] as purple and [1] as blue (I assume it's the default). I have had it once where one doesn't light up - it oriented the wand correctly but I couldn't reset the positions (sorry I forgot to mention the buttin change). When something like that happens I just re-run the FreePIE script and that fixes it.


I didn't try the sixense sample program yesterday. I'll give that a shot today. If you notice in the video though, my FreePIE values for psmove[0] Position X and Y are going crazy. So, it seems that SteamVR is accurately portraying the readings it's receiving. That's why I honestly thought the problem was the BT sync with this controller. I'll try repairing again later and see if I can figure anything out.

I did update my SteamVR Hydra driver. I downloaded the latest version, which is v1.0.1.8. My distance from the PS Eye is about the same as yours. I've got it mounted on a shelf looking down (only way I could get a wide enough angle for SteamVR room scale with one camera), so it's about 2m above the floor...and I'm usually between 1-3m away from it.

The orbs are purple and blue just like yours. I tried changing colors with the different lines of code that were posted, but never got them to work. When I start your newest FreePIE script, psmove[0] orb flashes twice, then psmove[1] orb flashes twice, then both orbs stay on. Like I said, I think everything about what you've done is working fine. I think my issue is coming up before it even gets to FreePIE...either BT sync, camera driver, or possibly even Move hardware (probably not since it works with a PS3 just fine).

I'll try to get it figured out. Just wanted to let you know that if I'm quiet about your work, it's not because you did a bad job or I gave up on it, haha. Just computers being computers on my end.

Thanks for the reassurance :). I like most people do have self-confidence issues.

What's the trigger reading like? If that's okay then bt should be fine. Do test_tracker and test_opengl work properly?

@InfinateXtremer I think you may still be using the older SteamVR Hydra driver. It only affects SteamVR and not sixense_simple3d.


Mon May 23, 2016 11:24 am
Profile
One Eyed Hopeful

Joined: Fri Jul 31, 2015 11:31 am
Posts: 14
Reply with quote
I'm using SteamVR Hydra Driver 1.0.1.8 and i still had to disable reverse yaw.

Probably i'm doing something wrong. I tried replacing

*SteamVR Hydra driver\hydra\bin\Win32\sixense.dll
*SteamVR Hydra driver\hydra\bin\x64\sixense_x64.dll

with FreePIE sixense_fake.dll, i also tried replacing x64 one with x64 dll but outcome is still same.

I also uploaded video showing orientation problem i'm having with steamvr https://youtu.be/4xref7GDDNk at 1:00 i resetted orientation by holding both circle buttons on moves


Mon May 23, 2016 12:17 pm
Profile
One Eyed Hopeful

Joined: Mon May 23, 2016 2:05 pm
Posts: 7
Reply with quote
Hello, Recently i bought used Move controllers as VR controllers. I found great gladiusz's guide how to connect and Remlas helped me pair them. Using gladiusz script I emulated Vive controllers. At first they work pretty well. But after few minutes of using drifting started. When I closing SteamVR controllers literally go nuts. I used only this:
Code:
https://github.com/HipsterSloth/psmove-unity5/wiki/PSMove-Setup-(Windows)

and connected it via Esperanza ea101
Also i'm completely n00b in some serious programming but I was thinking about directly using Moves instead emulating Hydra. In my opinion it stands better for that. It is only idea and I don't know is it even possible.


Mon May 23, 2016 3:19 pm
Profile
Cross Eyed!
User avatar

Joined: Thu Apr 09, 2015 4:27 am
Posts: 108
Reply with quote
InfinateXtremer wrote:
I'm using SteamVR Hydra Driver 1.0.1.8 and i still had to disable reverse yaw.

Probably i'm doing something wrong. I tried replacing

*SteamVR Hydra driver\hydra\bin\Win32\sixense.dll
*SteamVR Hydra driver\hydra\bin\x64\sixense_x64.dll

with FreePIE sixense_fake.dll, i also tried replacing x64 one with x64 dll but outcome is still same.

I also uploaded video showing orientation problem i'm having with steamvr https://youtu.be/4xref7GDDNk at 1:00 i resetted orientation by holding both circle buttons on moves


I'm completely dumbfounded. As far as I know the orientation should be more or less the same in SteamVR as it is in sixense_simple3d. Here's a video of what I get. I updated from SteamVR Hydra Driver 1.0.1.7 to 1.0.1.8 just in case.


Mon May 23, 2016 4:23 pm
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 344 posts ]  Go to page Previous  1 ... 4, 5, 6, 7, 8, 9  Next

Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by STSoftware.