It is currently Wed Feb 22, 2017 1:41 pm



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

Joined: Thu Apr 09, 2015 4:27 am
Posts: 102
I managed to build libpsmoveapi.dll :D !

We can now use NoxWings' version of FreePIE. The attached version should contain everything needed. It's working with the CL eye driver. I had some trouble reinstalling libsub so I wasn't able to check it.

Thanks for the suggestion gladiusz but I wanted to use the current version because it is supposed to have a far better orientation code.

[Edit]
It works with libsubK but crashes on stopping a script. I think it's a problem with freepie because the psmoveapi examples don't crash.


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


Tue May 10, 2016 4:03 pm
Profile
One Eyed Hopeful

Joined: Tue May 10, 2016 9:15 pm
Posts: 15
Thanks for the great work guys, I started work on a mouse emulation windows app before I came across this using psmoveapi but have now stopped seeing as you guys are much further along than i was, although I did manage to get the mouse moving. I used noxwings old work to help me get my head around psmoveapi.

zelmon64, based on what I've read I doubt you have one but I'm curious if you know if moveframework supports the ext plug on the move controller to be able to add support for the sharp shooter attachment, I now psmoveapi does but I'm not sure about version 3 which you've managed to build.


Tue May 10, 2016 9:36 pm
Profile
Online
Cross Eyed!
User avatar

Joined: Thu Apr 09, 2015 4:27 am
Posts: 102
troziepoo wrote:
Thanks for the great work guys, I started work on a mouse emulation windows app before I came across this using psmoveapi but have now stopped seeing as you guys are much further along than i was, although I did manage to get the mouse moving. I used noxwings old work to help me get my head around psmoveapi.

zelmon64, based on what I've read I doubt you have one but I'm curious if you know if moveframework supports the ext plug on the move controller to be able to add support for the sharp shooter attachment, I now psmoveapi does but I'm not sure about version 3 which you've managed to build.


I do have a racing wheel (and a sharp shooter on the way - I'm a bit obsesive/compulsive with these things). The MoveFramework FreePIE plugin can currently detect the d-pad on the wheel and all the buttons that are mirrored on the move. NoxWings' version (which uses PSMoveAPI 3.0 I believe) doesn't currently have them but the PSMoveAPI (my build is with the newer code not in the 3.9.1 release with cboulay's hidapi windows tweak) does so I should be able to add them in. I was going to add the missing ones to the MF version and got sidetracked with the drift problem but I'm going to stick with the PSMoveAPI from here on now that it works :D.

My main use case is mouse emulation too :D . The first thing I managed to get to work was MoveFramework with JoyEmu but I didn't like using PPJoy (though I still don't know for sure if there are real safety concerns about running in test mode). Did you ever try out ticoneva/MOVEpoint? It was on my list to try but haven't bothered since getting FreePIE to work.

[Edit]
I was wrong about NoxWings' plugin. It does already have some EXT support but not complete.


Last edited by zelmon64 on Wed May 11, 2016 6:49 am, edited 1 time in total.



Wed May 11, 2016 3:12 am
Profile
One Eyed Hopeful

Joined: Tue May 10, 2016 9:15 pm
Posts: 15
zelmon64 wrote:
troziepoo wrote:
Thanks for the great work guys, I started work on a mouse emulation windows app before I came across this using psmoveapi but have now stopped seeing as you guys are much further along than i was, although I did manage to get the mouse moving. I used noxwings old work to help me get my head around psmoveapi.

zelmon64, based on what I've read I doubt you have one but I'm curious if you know if moveframework supports the ext plug on the move controller to be able to add support for the sharp shooter attachment, I now psmoveapi does but I'm not sure about version 3 which you've managed to build.


I do have a racing wheel (and a sharp shooter on the way - I'm a bit obsesive/compulsive with these things). The MoveFramework FreePIE plugin can currently detect the d-pad on the wheel and all the buttons that are mirrored on the move. NoxWings' version (which uses PSMoveAPI 3.0 I believe) doesn't currently have them but the PSMoveAPI (my build is with the newer code not in the 3.9.1 release with cboulay's hidapi windows tweak) does so I should be able to add them in. I was going to add the missing ones to the MF version and got sidetracked with the drift problem but I'm going to stick with the PSMoveAPI from here on now that it works :D.

My main use case is mouse emulation too :D . The first thing I managed to get to work was MoveFramework with JoyEmu but I didn't like using PPJoy (though I still don't know for sure if there are real safety concerns about running in test mode). Did you ever try out ticoneva/MOVEpoint? It was on my list to try but haven't bothered since getting FreePIE to work.



Awesome, my sharp shooters should be here this week so I'll start testing as soon as they arrive ;)

Haha me too, I have 4 moves, 2 navigation controlelrs, 2 sharp shooters on the way and 2 PS3 Eyes hopefully for the eventual full 360 tracking later down the track.

No I haven't tried MOVEpoint yet, I'll download it and give it a test after I grab some dinner ;).


Wed May 11, 2016 3:32 am
Profile
One Eyed Hopeful

Joined: Thu Oct 17, 2013 2:33 am
Posts: 35
Just to make sure I'm understanding this correctly, what's the benefit of switching to the PSMoveAPI version as opposed to MoveFramework? I know you mentioned correcting drift, but does it offer more accurate tracking overall? Just trying to figure out what we're gaining by switching.

Also, with the idea of using multiple PS Eyes for improved tracking, how easily could that be implemented? I know I'd love to see it as a means of having a 2nd "base station" for SteamVR. Just not sure how it would all come together. Thanks in advancing for educating me, haha. :)


Wed May 11, 2016 2:11 pm
Profile
Online
Cross Eyed!
User avatar

Joined: Thu Apr 09, 2015 4:27 am
Posts: 102
n8rockerasu wrote:
Just to make sure I'm understanding this correctly, what's the benefit of switching to the PSMoveAPI version as opposed to MoveFramework? I know you mentioned correcting drift, but does it offer more accurate tracking overall? Just trying to figure out what we're gaining by switching.

Also, with the idea of using multiple PS Eyes for improved tracking, how easily could that be implemented? I know I'd love to see it as a means of having a 2nd "base station" for SteamVR. Just not sure how it would all come together. Thanks in advancing for educating me, haha. :)


The main benefit is that there are some rather clever people supporting the PSMoveAPI whereas the developer of the MoveFramework has stopped supporting it a while ago. It will take some rather clever people to figure out things like multi-camera support so it would be good to stick with them :) . They are also currently considering an improved tracking code.

The only reason I was able to get the bt mac addresses to be read correctly with MoveFramework was because they had already fixed it in PSMoveAPI and I was able to transfer their fix across. Other improvements like reworking the orientation code are much too involved to simply apply them to MoveFramework.

The PSMoveAPI also has PS3EyeDriver support so we're not limited to the paid for CL-eye driver.

This is of course all assuming that this version is an improvement over MoveFramework. No one has yet said whether it performs better in their applications. I only have some very basic FreePIE scripts to test that it is functioning. If you see anything that MoveFramework does better please point it out :).

I hope this answers your question :).


Wed May 11, 2016 3:30 pm
Profile
One Eyed Hopeful

Joined: Thu Oct 17, 2013 2:33 am
Posts: 35
zelmon64 wrote:
n8rockerasu wrote:
Just to make sure I'm understanding this correctly, what's the benefit of switching to the PSMoveAPI version as opposed to MoveFramework? I know you mentioned correcting drift, but does it offer more accurate tracking overall? Just trying to figure out what we're gaining by switching.

Also, with the idea of using multiple PS Eyes for improved tracking, how easily could that be implemented? I know I'd love to see it as a means of having a 2nd "base station" for SteamVR. Just not sure how it would all come together. Thanks in advancing for educating me, haha. :)


The main benefit is that there are some rather clever people supporting the PSMoveAPI whereas the developer of the MoveFramework has stopped supporting it a while ago. It will take some rather clever people to figure out things like multi-camera support so it would be good to stick with them :) . They are also currently considering an improved tracking code.

The only reason I was able to get the bt mac addresses to be read correctly with MoveFramework was because they had already fixed it in PSMoveAPI and I was able to transfer their fix across. Other improvements like reworking the orientation code are much too involved to simply apply them to MoveFramework.

The PSMoveAPI also has PS3EyeDriver support so we're not limited to the paid for CL-eye driver.

This is of course all assuming that this version is an improvement over MoveFramework. No one has yet said whether it performs better in their applications. I only have some very basic FreePIE scripts to test that it is functioning. If you see anything that MoveFramework does better please point it out :).

I hope this answers your question :).


Yes, very much so. Thank you for elaborating on that! I'm hoping I'll have a chance to test out your PSMoveAPI FreePIE build tonight and see if I notice any difference in performance.

I will say, I would definitely prefer to not use the CL-eye driver, as when I tried setting up the camera using the PSEye driver (libusb-win32), I noticed the same thing they did on github...PSEye gives a strong 60fps, while CL-eye fluctuates a lot...sometimes dropping as low as 24fps. Wouldn't that play a big role in the smoothness and accuracy of the tracking as well? It definitely seems like we'd be best served if the PSEye driver could work with FreePIE (which I couldn't get it to...orbs never lit up after script was started).


Wed May 11, 2016 4:55 pm
Profile
Online
Cross Eyed!
User avatar

Joined: Thu Apr 09, 2015 4:27 am
Posts: 102
n8rockerasu wrote:
Yes, very much so. Thank you for elaborating on that! I'm hoping I'll have a chance to test out your PSMoveAPI FreePIE build tonight and see if I notice any difference in performance.

I will say, I would definitely prefer to not use the CL-eye driver, as when I tried setting up the camera using the PSEye driver (libusb-win32), I noticed the same thing they did on github...PSEye gives a strong 60fps, while CL-eye fluctuates a lot...sometimes dropping as low as 24fps. Wouldn't that play a big role in the smoothness and accuracy of the tracking as well? It definitely seems like we'd be best served if the PSEye driver could work with FreePIE (which I couldn't get it to...orbs never lit up after script was started).


Oh good. I'm glad that cleared things up :).

I just wanted to say that I could only get libusbK working. I don't know what the difference between that and libusb-win32 is though. Also when using this driver FreePIE crashes when stopping scripts. I haven't looked into it yet. Have fun! :)

[Edit]
I've retried it with libsub-win32 and it worked fine. Not even crashing :). Last time I tried it the computer had been on for a while so something I'd done must have interfered.


Last edited by zelmon64 on Thu May 12, 2016 2:46 am, edited 1 time in total.



Wed May 11, 2016 5:20 pm
Profile
One Eyed Hopeful

Joined: Tue May 10, 2016 9:15 pm
Posts: 15
@zelmon64 I didn't get a chance to check out MOVEpoint last night nor test your attached psmoveapi version but I did stumble across something quite interesting.

a comment here https://www.reddit.com/r/SteamVR/comments/4imxdt/psmove_oculus/ by hipstersloth908, he built the psmove plugin for unity-5, said he's working on a multi-eye SteamVR plugin and showed some demo videos here https://www.youtube.com/channel/UC9hnlsCtN0oBOgEAr4WgmTA. Could be something to keep an eye on or collaborate with.

n8rockerasu wrote:
Also, with the idea of using multiple PS Eyes for improved tracking, how easily could that be implemented? I know I'd love to see it as a means of having a 2nd "base station" for SteamVR. Just not sure how it would all come together.


A camera sitting in front of you is not going to see the controller if it moves behind you, having a second will pretty much eliminate the chance that you will lose tracking due to orb visibility, also if you watch this https://www.youtube.com/watch?v=HT5moG_qRpM you can see that he's is able to somewhat emulate room scale.


Wed May 11, 2016 5:21 pm
Profile
One Eyed Hopeful

Joined: Thu Oct 17, 2013 2:33 am
Posts: 35
zelmon64 wrote:
n8rockerasu wrote:
Yes, very much so. Thank you for elaborating on that! I'm hoping I'll have a chance to test out your PSMoveAPI FreePIE build tonight and see if I notice any difference in performance.

I will say, I would definitely prefer to not use the CL-eye driver, as when I tried setting up the camera using the PSEye driver (libusb-win32), I noticed the same thing they did on github...PSEye gives a strong 60fps, while CL-eye fluctuates a lot...sometimes dropping as low as 24fps. Wouldn't that play a big role in the smoothness and accuracy of the tracking as well? It definitely seems like we'd be best served if the PSEye driver could work with FreePIE (which I couldn't get it to...orbs never lit up after script was started).


Oh good. I'm glad that cleared things up :).

I just wanted to say that I could only get libusbK working. I don't know what the difference between that and libusb-win32 is though. Also when using this driver FreePIE crashes when stopping scripts. I haven't looked into it yet. Have fun! :)


Ah, ok. Yeah, these are the instructions I followed for it: https://github.com/HipsterSloth/psmove- ... Windows%29

Everything seemed to go fine, but there was just no response in FreePIE. I don't know enough of what I'm doing to understand how different the implementation is. But at least from what I could see, the camera seemed to run smoother on that driver.


Wed May 11, 2016 5:25 pm
Profile
One Eyed Hopeful

Joined: Thu Oct 17, 2013 2:33 am
Posts: 35
Well, I tested what I could. It appears the PSMoveAPI system uses totally different properties and attributes, so my script was completely incompatible. As I've said before, I'm no programmer/coder by any means, and basically just tinker as a hobby. But from what I ran into, and my understanding of the way the different coding works, I'm not getting any response from any buttons in FreePIE. I have something like this:
Code:
hydra[0].trigger = psmove[0].getButtonPressed (PSMoveButton.Trigger)
hydra[0].start = psmove[0].getButtonDown (PSMoveButton.Move)


With the MoveFramework version of FreePIE that CyberVillain/gladiusz put together, upon running the script, all of the tracked info would be displayed in the "Console" tab. It would show both positioning/orientation info and when a button was pressed. Using this version, I see none of that. Console is just completely blank and empty.

However, when I throw this code into the script:
Code:
diagnostics.watch(psmove[0].yaw)
diagnostics.watch(psmove[0].pitch)
diagnostics.watch(psmove[0].roll)


It does show in the "Watch" tab that it's reading the movement

The other thing I ran into for positioning/orientation (and I'm sure this is just my ignorance and amateur understanding here) is there are no x, y, or z attributes for psmove in this version. So, the psmove[0].z*10 sections and the like do not work anymore.

Kind of feels like I'm back to the drawing board with this version. Relearning the coding and trying to figure out why things aren't functioning properly. It's entirely possible I'm just script stupid, but if anybody could shed some light and/or write up a script in terms of PSMove attributes, I'd appreciate it. As is, I'm missing the old version.


Thu May 12, 2016 12:52 pm
Profile
Online
Cross Eyed!
User avatar

Joined: Thu Apr 09, 2015 4:27 am
Posts: 102
n8rockerasu wrote:
Well, I tested what I could. It appears the PSMoveAPI system uses totally different properties and attributes, so my script was completely incompatible. As I've said before, I'm no programmer/coder by any means, and basically just tinker as a hobby. But from what I ran into, and my understanding of the way the different coding works, I'm not getting any response from any buttons in FreePIE. I have something like this:
Code:
hydra[0].trigger = psmove[0].getButtonPressed (PSMoveButton.Trigger)
hydra[0].start = psmove[0].getButtonDown (PSMoveButton.Move)


With the MoveFramework version of FreePIE that CyberVillain/gladiusz put together, upon running the script, all of the tracked info would be displayed in the "Console" tab. It would show both positioning/orientation info and when a button was pressed. Using this version, I see none of that. Console is just completely blank and empty.

However, when I throw this code into the script:
Code:
diagnostics.watch(psmove[0].yaw)
diagnostics.watch(psmove[0].pitch)
diagnostics.watch(psmove[0].roll)


It does show in the "Watch" tab that it's reading the movement

The other thing I ran into for positioning/orientation (and I'm sure this is just my ignorance and amateur understanding here) is there are no x, y, or z attributes for psmove in this version. So, the psmove[0].z*10 sections and the like do not work anymore.

Kind of feels like I'm back to the drawing board with this version. Relearning the coding and trying to figure out why things aren't functioning properly. It's entirely possible I'm just script stupid, but if anybody could shed some light and/or write up a script in terms of PSMove attributes, I'd appreciate it. As is, I'm missing the old version.

Sorry I forgot to mention the different naming NoxWings used.


Code:
hydra[0].trigger = psmove[0].getButtonPressed (PSMoveButton.Trigger)
hydra[0].start = psmove[0].getButtonDown (PSMoveButton.Move)
#should be
hydra[0].trigger = psmove[0].trigger
hydra[0].start = psmove[0].getButtonDown(PSMoveButton.Move)

# the positions psmove[0].z*10  should be
psmove[0].position.z*10


For all other options they will come up in the auto-complete options in FreePIE (after you type the "." after "psmove[0]").

There are more options than with the MoveFramework version so the differences like the extra "position." allow for them all. If you find it too confusing I could alter you script for you if you'd like.


Thu May 12, 2016 2:49 pm
Profile
One Eyed Hopeful

Joined: Wed Mar 23, 2016 7:22 am
Posts: 47
Sorry, but I have a problem with orientation tracking in new API version. Gyro works perfect, but when I run the script, one of two orbs is purple and it even isn't lit. Second orb don't shine at all. Hovever, all apps like test_opengl and test_tracker works. I'm using Cl drivers and I calibrated #0 controller with API calibration. I can't calibrate the second one, beacuse when only #1 is connected magnetometer_calibration.exe crash at startup. With both controllers connected, it allows me to calibrate only the first one. Can all it be caused by CL drivers?


Thu May 12, 2016 3:44 pm
Profile
Online
Cross Eyed!
User avatar

Joined: Thu Apr 09, 2015 4:27 am
Posts: 102
gladiusz wrote:
Sorry, but I have a problem with orientation tracking in new API version. Gyro works perfect, but when I run the script, one of two orbs is purple and it even isn't lit. Second orb don't shine at all. Hovever, all apps like test_opengl and test_tracker works. I'm using Cl drivers and I calibrated #0 controller with API calibration. I can't calibrate the second one, beacuse when only #1 is connected magnetometer_calibration.exe crash at startup. With both controllers connected, it allows me to calibrate only the first one. Can all it be caused by CL drivers?

I just tested it with the CL driver using four. During the initial calibration at the start of a script the moves flash consecutively purple, blue, yellow then red. If any move can't be seen by the camera during this phase it will remain dark. I had some trouble with the tracking of the yellow one but using libusb-win32 it is fine. Similarly with test_tracker and test_opengl the CL driver sometimes had difficulty distinguishing between the yellow and red but when using libusb-win32 it was fine.


Thu May 12, 2016 4:19 pm
Profile
One Eyed Hopeful

Joined: Wed Mar 23, 2016 7:22 am
Posts: 47
I solved the problem with calibration, but I have no idea how make tracking to work. I tested it with Cl and libusb-win32 drivers and the result is still the same. Both controllers flickers and tracking don't work in FreePie in a correct way.


Thu May 12, 2016 5:02 pm
Profile
Online
Cross Eyed!
User avatar

Joined: Thu Apr 09, 2015 4:27 am
Posts: 102
gladiusz wrote:
I solved the problem with calibration, but I have no idea how make tracking to work. I tested it with Cl and libusb-win32 drivers and the result is still the same. Both controllers flickers and tracking don't work in FreePie in a correct way.

I can't seem to recreate your problem. Could you please describe the colours and duration of the flickering? Also have you updated you script to use psmove[0].position.x like n8rockerasu was having trouble with?


Thu May 12, 2016 5:34 pm
Profile
One Eyed Hopeful

Joined: Wed Mar 23, 2016 7:22 am
Posts: 47

I have a correct script. Maybe is fault of Windows 10?


Thu May 12, 2016 5:52 pm
Profile
Online
Cross Eyed!
User avatar

Joined: Thu Apr 09, 2015 4:27 am
Posts: 102
gladiusz wrote:
I have a correct script. Maybe is fault of Windows 10?

I'm also on Windows 10 but all mine aren't flickering at all :?: . Here's a build I'm currently testing out and a script I've been using.
[edit]
sorry that was broken. try this release


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


Last edited by zelmon64 on Thu May 12, 2016 6:29 pm, edited 1 time in total.



Thu May 12, 2016 6:20 pm
Profile
One Eyed Hopeful

Joined: Wed Mar 23, 2016 7:22 am
Posts: 47
zelmon64 wrote:
gladiusz wrote:
I have a correct script. Maybe is fault of Windows 10?

I'm also on Windows 10 but all mine aren't flickering at all :?: . Here's a build I'm currently testing out and a script I've been using.

With your version is the same problem. I don't know whats going on. MF version works perfect. Can I change orbs collor manually in any way?
Edit: Nope.


Thu May 12, 2016 6:25 pm
Profile
Online
Cross Eyed!
User avatar

Joined: Thu Apr 09, 2015 4:27 am
Posts: 102
gladiusz wrote:
zelmon64 wrote:
gladiusz wrote:
I have a correct script. Maybe is fault of Windows 10?

I'm also on Windows 10 but all mine aren't flickering at all :?: . Here's a build I'm currently testing out and a script I've been using.

With your version is the same problem. I don't know whats going on. MF version works perfect. Can I change orbs collor manually in any way?

Code:

   if psmove[0].getButtonDown(PSMoveButton.Cross):
      psmove[0].autoLedColor = False
      psmove[0].led.SetColor(0, 0, 255)
   f psmove[0].getButtonUp(PSMoveButton.Cross):
      psmove[0].autoLedColor = True

This will change the colour but it stops tracking for me.
[edit]
Are you using Windows native bt stack or MiJ? (sorry to leave you hanging but I'm going to sleep - it's past 1am here)


Thu May 12, 2016 6:32 pm
Profile
One Eyed Hopeful

Joined: Wed Mar 23, 2016 7:22 am
Posts: 47
Changing colors doesn't work for me. Maybe it's a problem with a file named "colormapping.dat". When I start test_tracker, I get info that this file is too old and it doesn't contain colors. I'm using native bt stack.


Thu May 12, 2016 6:41 pm
Profile
One Eyed Hopeful

Joined: Thu Oct 17, 2013 2:33 am
Posts: 35
Ok, I think I've made some progress in understanding and rewriting my script.

I'm attaching both the original script I was using with the MoveFramework FreePIE (that I was able to get working in SteamVR) and then the new script as best as I understood things for PSMoveAPI. You mentioning the "position" attribute actually helped me get through that part a bit. I still have no clue what to do with all the other attributes (accel, gyro, etc) or how to implement everything into the most accurate tracking possible. But maybe people more knowledgable than me can help with that. Any help/improvement in getting it to run/look better is greatly appreciated and welcome. I'm just a dummy trying to use cheap PS Move controllers as Vive wands, haha. :)

I did see now that when I run diagnostics, it does show all buttons working. I was just thrown off by this new build of FreePIE because like I said, it doesn't show a constant readout of orientation and button presses like the old one did under the "Console" tab. I haven't had a chance to test any of this in a game yet. I'm having a charging issue with my other Move controller. So, hopefully I can give it a go soon.

Attachment:
n8s_scripts.7z


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


Thu May 12, 2016 6:57 pm
Profile
Online
Cross Eyed!
User avatar

Joined: Thu Apr 09, 2015 4:27 am
Posts: 102
gladiusz wrote:
Changing colors doesn't work for me. Maybe it's a problem with a file named "colormapping.dat". When I start test_tracker, I get info that this file is too old and it doesn't contain colors. I'm using native bt stack.

I get the same message :
Code:
### Found 2 controllers.
Trying to init PSMoveTracker...libusb: error [init_device] program assertion failed: device address collision with root hub
libusb: error [init_device] device '\\.\USB#VID_046D&PID_082D&MI_02#7&26030705&0&0002' is no longer connected!
Warning: No lens calibration files found.
C:\Users\William\AppData\Roaming\.psmoveapi\colormapping.dat is too old - not restoring colors.
OK
Opening controller 0
Calibrating controller 0...ERROR - retrying
Calibrating controller 0...ERROR - retrying
Calibrating controller 0...ERROR - retrying


Have you tried deleting the flies:
    colormapping.dat
    PSEye_backup.ini
    PSEye_backup_win.ini
as suggested at the bottom of HipsterSloth's psmove-unity5 PSMove Setup (Windows) wiki page?


Fri May 13, 2016 3:19 am
Profile
One Eyed Hopeful

Joined: Wed Mar 23, 2016 7:22 am
Posts: 47
I deleted colormapping.dat and key from registry , but I don't have backup files. Hovewer, it didn't help. Tracking in test_tracker also isn't stable as it should be, but orbs shine in a lit color.
https://onedrive.live.com/redir?resid=1B6016647434F932!15967&authkey=!AFoyN_OkWQ8aAj8&v=3&ithint=photo%2cpng


Fri May 13, 2016 4:36 am
Profile
Online
Cross Eyed!
User avatar

Joined: Thu Apr 09, 2015 4:27 am
Posts: 102
n8rockerasu wrote:
Ok, I think I've made some progress in understanding and rewriting my script.

I'm attaching both the original script I was using with the MoveFramework FreePIE (that I was able to get working in SteamVR) and then the new script as best as I understood things for PSMoveAPI. You mentioning the "position" attribute actually helped me get through that part a bit. I still have no clue what to do with all the other attributes (accel, gyro, etc) or how to implement everything into the most accurate tracking possible. But maybe people more knowledgable than me can help with that. Any help/improvement in getting it to run/look better is greatly appreciated and welcome. I'm just a dummy trying to use cheap PS Move controllers as Vive wands, haha. :)

I did see now that when I run diagnostics, it does show all buttons working. I was just thrown off by this new build of FreePIE because like I said, it doesn't show a constant readout of orientation and button presses like the old one did under the "Console" tab. I haven't had a chance to test any of this in a game yet. I'm having a charging issue with my other Move controller. So, hopefully I can give it a go soon.

Attachment:
n8s_scripts.7z

I've had a look at you script an tested it out in SteamVR :). You did a fine job :). I think the only things that need tweaking are the multiplying factors for the possitions (I think 10 seemed too small). I've attached a modified version with all the diagnostics added.

@gladiusz I can't think what to try next. Are you using a bluetooth 4.0 usb adapter?


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


Fri May 13, 2016 7:41 am
Profile
One Eyed Hopeful

Joined: Wed Mar 23, 2016 7:22 am
Posts: 47
Quote:
I can't think what to try next. Are you using a bluetooth 4.0 usb adapter?

Yes, I am. I'm using recomended Asus BT400


Fri May 13, 2016 9:56 am
Profile
One Eyed Hopeful

Joined: Fri Jul 31, 2015 11:31 am
Posts: 14
I modified move to hydra emulation script a little bit (moved bumper to move button, made trigger an axis, not button) but i'm having another problem on moveframework version axis and location is correct but in psmoveapi one they are reversed also when i move ps move to right or left corner hydra's locations and axis are no longer alligned to ps move one (i'm gonna upload video today showing the problem).


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


Fri May 13, 2016 10:21 am
Profile
Online
Cross Eyed!
User avatar

Joined: Thu Apr 09, 2015 4:27 am
Posts: 102
I managed to get the hydra position and rotation emulation in steamVR to work nicely with the attached script and PSMoveAPI plugin. It uses
Code:

   hydra[0].yaw = -psmove[0].yaw
   hydra[0].pitch = -psmove[0].pitch
   hydra[0].roll = psmove[0].roll
   hydra[0].z = -psmove[0].position.z*200
   hydra[0].x = -psmove[0].position.x*100
   hydra[0].y = psmove[0].position.y*100

and I changed the plugin to conjugate the rotation quaternion when converting it to the Euler angles.

[edit]
I added a part to the script whereby simultaneously pressing the circle buttons resets the positions and simultaneously pressing the cross buttons resets the orientations of the two moves.


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


Fri May 13, 2016 5:28 pm
Profile
One Eyed Hopeful

Joined: Thu Oct 17, 2013 2:33 am
Posts: 35
zelmon64 wrote:
I managed to get the hydra position and rotation emulation in steamVR to work nicely with the attached script and PSMoveAPI plugin. It uses
Code:

   hydra[0].yaw = -psmove[0].yaw
   hydra[0].pitch = -psmove[0].pitch
   hydra[0].roll = psmove[0].roll
   hydra[0].z = -psmove[0].position.z*200
   hydra[0].x = -psmove[0].position.x*100
   hydra[0].y = psmove[0].position.y*100

and I changed the plugin to conjugate the rotation quaternion when converting it to the Euler angles.

[edit]
I added a part to the script whereby simultaneously pressing the circle buttons resets the positions and simultaneously pressing the cross buttons resets the orientations of the two moves.


Wow, I am very excited about this. I'll check it out here in a couple minutes. I tested the previous script earlier, with the multiplying factors at 100...and I was getting some weird glitches. Not sure what was causing it, but I've downloaded so many plugins and builds the past couple weeks, it wouldn't surprise me if I've got something mixed up, haha. I probably need to clean that up and get rid of the old stuff.

Also, which driver are you presently using for the PS Eye with this? Does libusb-win32 work with this?

EDIT - Hmm...every time I run your new script, Zelmon, it crashes FreePIE. Just had it happen four times in a row. I downloaded your new plugin and everything. Not sure what's going wrong.

EDIT 2 - Ok...well, it seems all of my scripts are crashing. Not sure what happened. They were working earlier. I left to have dinner, came back, and now FreePIE crashes the second I start a script. I guess maybe I'll restart my PC...


Fri May 13, 2016 6:04 pm
Profile
Online
Cross Eyed!
User avatar

Joined: Thu Apr 09, 2015 4:27 am
Posts: 102
n8rockerasu wrote:
Wow, I am very excited about this. I'll check it out here in a couple minutes. I tested the previous script earlier, with the multiplying factors at 100...and I was getting some weird glitches. Not sure what was causing it, but I've downloaded so many plugins and builds the past couple weeks, it wouldn't surprise me if I've got something mixed up, haha. I probably need to clean that up and get rid of the old stuff.

Also, which driver are you presently using for the PS Eye with this? Does libusb-win32 work with this?

EDIT - Hmm...every time I run your new script, Zelmon, it crashes FreePIE. Just had it happen four times in a row. I downloaded your new plugin and everything. Not sure what's going wrong.

EDIT 2 - Ok...well, it seems all of my scripts are crashing. Not sure what happened. They were working earlier. I left to have dinner, came back, and now FreePIE crashes the second I start a script. I guess maybe I'll restart my PC...


Well here's yet another build to download. Hopefully this one won't crash. Both the libusb-win32 and Cl-eye drivers should work wih it. I was using the CL-eye driver previously but just retessted it with libusb-win32 and it was still okay (in fact it seemed better).


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


Sat May 14, 2016 12:38 am
Profile
One Eyed Hopeful

Joined: Tue May 10, 2016 9:15 pm
Posts: 15
Tested latest release and it's working awesomely in Tuscany but I haven't been able to test in SteamVR as I haven't been able to get them recognized by steam, how did you guys do it? I've installed the latest SteamVR Hydra drivers.

I also received my Sharp Shooters in the mail yesterday, and can confirm they are recognized by the Windows BT stack in the game controllers panel but I will give them a test in freepie shortly to see if I can map the buttons.


Sat May 14, 2016 1:41 am
Profile
One Eyed Hopeful

Joined: Tue May 10, 2016 9:15 pm
Posts: 15
No mapping required, but there are 2 issues with it that we can't solve, first is the pump action is Z axis so it's the exact same button as the trigger and the RL button at the bottom of the handle grip isn't recognized by windows so the 2 buttons/actions you would normally use as say a reload don't work and the sharp shooter only has triangle and square so you lose circle and x that you would have if just using the controller.


Sat May 14, 2016 1:57 am
Profile
One Eyed Hopeful

Joined: Fri Jul 31, 2015 11:31 am
Posts: 14
troziepoo wrote:
Tested latest release and it's working awesomely in Tuscany but I haven't been able to test in SteamVR as I haven't been able to get them recognized by steam, how did you guys do it? I've installed the latest SteamVR Hydra drivers.

I also received my Sharp Shooters in the mail yesterday, and can confirm they are recognized by the Windows BT stack in the game controllers panel but I will give them a test in freepie shortly to see if I can map the buttons.


Did you replaced sixense.dll's with the FreePIE ones(sixense_fake) in Hydra drivers folder?

zelmon64 wrote:
n8rockerasu wrote:
Wow, I am very excited about this. I'll check it out here in a couple minutes. I tested the previous script earlier, with the multiplying factors at 100...and I was getting some weird glitches. Not sure what was causing it, but I've downloaded so many plugins and builds the past couple weeks, it wouldn't surprise me if I've got something mixed up, haha. I probably need to clean that up and get rid of the old stuff.

Also, which driver are you presently using for the PS Eye with this? Does libusb-win32 work with this?

EDIT - Hmm...every time I run your new script, Zelmon, it crashes FreePIE. Just had it happen four times in a row. I downloaded your new plugin and everything. Not sure what's going wrong.

EDIT 2 - Ok...well, it seems all of my scripts are crashing. Not sure what happened. They were working earlier. I left to have dinner, came back, and now FreePIE crashes the second I start a script. I guess maybe I'll restart my PC...


Well here's yet another build to download. Hopefully this one won't crash. Both the libusb-win32 and Cl-eye drivers should work wih it. I was using the CL-eye driver previously but just retessted it with libusb-win32 and it was still okay (in fact it seemed better).


I can run moveframework scripts fine but when i try one of psmoveapi script FreePIE instantly crashes. It was working fine yesterday. If it helps i'm using Windows 10.


Sat May 14, 2016 2:20 am
Profile
One Eyed Hopeful

Joined: Tue May 10, 2016 9:15 pm
Posts: 15
InfinateXtremer wrote:
troziepoo wrote:
Tested latest release and it's working awesomely in Tuscany but I haven't been able to test in SteamVR as I haven't been able to get them recognized by steam, how did you guys do it? I've installed the latest SteamVR Hydra drivers.

I also received my Sharp Shooters in the mail yesterday, and can confirm they are recognized by the Windows BT stack in the game controllers panel but I will give them a test in freepie shortly to see if I can map the buttons.


Did you replaced sixense.dll's with the FreePIE ones(sixense_fake) in Hydra drivers folder?


Yeah I've done that with that dll in "C:\Program Files (x86)\Steam\steamapps\common\SteamVR\drivers\hydra\bin\Win32". Do we need to install the OpenVR runtime also?


Sat May 14, 2016 2:49 am
Profile
One Eyed Hopeful

Joined: Fri Jul 31, 2015 11:31 am
Posts: 14
You should also replace x64 one.
Also are you starting SteamVR runtime before you run the script or after?

Make sure drivers install fine(you can check steamvr.vrsettings, it should have "hydra" tab), I never installed steam on this computer(copy pasted it from backup folder) because of that i needed to define SteamPath in register_driver.cmd


Sat May 14, 2016 3:02 am
Profile
One Eyed Hopeful

Joined: Tue May 10, 2016 9:15 pm
Posts: 15
InfinateXtremer wrote:
You should also replace x64 one.
Also are you starting SteamVR runtime before you run the script or after?

Make sure drivers install fine(you can check steamvr.vrsettings, it should have "hydra" tab), I never installed steam on this computer(copy pasted it from backup folder) because of that i needed to define SteamPath in register_driver.cmd


Hmmmm, I don't have an x64 folder in there. Is "Steam\steamapps\common\SteamVR\drivers\hydra\bin\" the correct location?

Starting script first then SteamVR and yeah have hydra listed in steamvr.vrsettings.


Sat May 14, 2016 3:42 am
Profile
One Eyed Hopeful

Joined: Tue May 10, 2016 9:15 pm
Posts: 15
troziepoo wrote:
InfinateXtremer wrote:
You should also replace x64 one.
Also are you starting SteamVR runtime before you run the script or after?

Make sure drivers install fine(you can check steamvr.vrsettings, it should have "hydra" tab), I never installed steam on this computer(copy pasted it from backup folder) because of that i needed to define SteamPath in register_driver.cmd


Hmmmm, I don't have an x64 folder in there. Is "Steam\steamapps\common\SteamVR\drivers\hydra\bin\" the correct location?

Starting script first then SteamVR and yeah have hydra listed in steamvr.vrsettings.



Ahhh I got it, I was replacing the wrong one. Thanks dude ;).


Sat May 14, 2016 3:55 am
Profile
One Eyed Hopeful

Joined: Fri Jul 31, 2015 11:31 am
Posts: 14
troziepoo wrote:
troziepoo wrote:
InfinateXtremer wrote:
You should also replace x64 one.
Also are you starting SteamVR runtime before you run the script or after?

Make sure drivers install fine(you can check steamvr.vrsettings, it should have "hydra" tab), I never installed steam on this computer(copy pasted it from backup folder) because of that i needed to define SteamPath in register_driver.cmd


Hmmmm, I don't have an x64 folder in there. Is "Steam\steamapps\common\SteamVR\drivers\hydra\bin\" the correct location?

Starting script first then SteamVR and yeah have hydra listed in steamvr.vrsettings.



Ahhh I got it, I was replacing the wrong one. Thanks dude ;).



Happy to help, also are you having any problems with steamvr? when i rotate ps move to back my whole tracking is reversed.


Sat May 14, 2016 10:51 am
Profile
One Eyed Hopeful

Joined: Thu Oct 17, 2013 2:33 am
Posts: 35
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.


Sat May 14, 2016 2:42 pm
Profile
One Eyed Hopeful

Joined: Fri Jul 31, 2015 11:31 am
Posts: 14
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.


Sat May 14, 2016 4:17 pm
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 339 posts ]  Go to page Previous  1 ... 3, 4, 5, 6, 7, 8, 9  Next

Who is online

Users browsing this forum: zelmon64 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.