QBZ wrote: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:
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.
The only complete script I can seem to find posted by gladiusz is an old one that used the MoveFramewrk version. The drift is unavoidable even with calibration with that version. It also looks like your bt adapter is only 2.1 so it may not work as well as a 4.0 one.
A couple of very clever people are already working on a native plugin for SteamVR and they say it will most likely be ready by the end of the month.
I think i diagnosed the problem, it has something to do with the sixense.dll. If i replace sixense.dll with the FreePIE one i have to use yaw without reversed but if i use sixense_simple3d's sixense.dll i have to reverse yaw. The problem is i don't remember where i got sixense_simple3d's sixense.dll file.
I uploaded both .dll's, also can you please upload your sixense dlls from FreePIE folder
Also a question. Right now can we use more than 1 Eye cameras?
You do not have the required permissions to view the files attached to this post.
InfinateXtremer wrote:I think i diagnosed the problem, it has something to do with the sixense.dll. If i replace sixense.dll with the FreePIE one i have to use yaw without reversed but if i use sixense_simple3d's sixense.dll i have to reverse yaw. The problem is i don't remember where i got sixense_simple3d's sixense.dll file.
I uploaded both .dll's, also can you please upload your sixense dlls from FreePIE folder
Also a question. Right now can we use more than 1 Eye cameras?
I'm using the fake sixense DLLs that CyberVillain posted on the first page. Judging from the size (27kB) it looks like sixense_simple3d's sixense.dll is the same one. Sixense_FreePIE.dll is only 16kB. I looked in my fresh install folder and there is a sixense_fake.dll at 16kB. The current release of FreePIE must not contain the latest sixense version. There's also a sixense_fakex64.dll that comes with the install that is only 18kB compared to the 32kB one he posted. I use the 27kB and 32kB versions in the directories you described earlier.
Multi-cam isn't currently supported. I just checked what would happen if I ran FreePIE with two ps moves connected then connected an additional two and another camera and tried to run another FreePIE instance. They didn't play well together.
HispsterSloth's new SteamVR plugin will use multi-cam for better depth measurements and coverage. He's confirmed that it's on track for a release by the end of the month.
I downloaded Release6.7z
and PSAPI_hydra2move_new9
installed on the computer steamvr_hydra_driver_v1.0.1.7
I copied sixense_fake.dll from Release folder
and renamed it sixense.dll
and moved it to the C: \ Program Files (x86) \ SteamVR Hydra driver \ hydra \ bin \ Win32
FreePIE.exe run from Release folder
I run the script PSAPI_hydra2move_new9.py
The Watch tab displays the tracking position and press buttons
But SteamVR sees no movement:
213123123.png
startup "Sixense test":
4324324.png
You do not have the required permissions to view the files attached to this post.
slavian wrote:zelmon64 tell me please. What am I doing wrong?
I downloaded Release6.7z
and PSAPI_hydra2move_new9
installed on the computer steamvr_hydra_driver_v1.0.1.7
I copied sixense_fake.dll from Release folder
and renamed it sixense.dll
and moved it to the C: \ Program Files (x86) \ SteamVR Hydra driver \ hydra \ bin \ Win32
FreePIE.exe run from Release folder
I run the script PSAPI_hydra2move_new9.py
The Watch tab displays the tracking position and press buttons
But SteamVR sees no movement:
startup "Sixense test":
Release6.7z doesn't contain the latest DLLs. Find FreePIE_PSMoveAPI_DLLs-201605211530.7z and replace them.
Next, the sixense DLLs you need are on the first page posted by CyberVllain. Place sixense_fake.dll like you did and use sixense_fakex64.dll in the adjacent x64 folder.
Then to use sixense_simple3d.exe you also need to replace the sixense.dll that is in the same folder.
slavian wrote:zelmon64 tell me please. What am I doing wrong?
Next, the sixense DLLs you need are on the first page posted by CyberVllain. Place sixense_fake.dll like you did and use sixense_fakex64.dll in the adjacent x64 folder.
slavian wrote:zelmon64 tell me please. What am I doing wrong?
Next, the sixense DLLs you need are on the first page posted by CyberVllain. Place sixense_fake.dll like you did and use sixense_fakex64.dll in the adjacent x64 folder.
They are in install folder of FreePIE
Are you sure they're the ones we should be using (the 16kB sixense_fake.dll and 18kB sixense_fakex64.dll that come with FreePIE 1.9.629)? To use these I have to set the rotation.update conjugation back to false. This works for the direction of the orientation but the roll is still not correct (it reverses when the pitch is greater than 90 deg).
I much prefer the ones you posted on the first page of this thread here and here. They're the ones I use in my video. I've had no problems with them.
zelmon64 wrote:Are you sure they're the ones we should be using (the 16kB sixense_fake.dll and 18kB sixense_fakex64.dll that come with FreePIE 1.9.629)? To use these I have to set the rotation.update conjugation back to false. This works for the direction of the orientation but the roll is still not correct (it reverses when the pitch is greater than 90 deg).
I much prefer the ones you posted on the first page of this thread here and here. They're the ones I use in my video. I've had no problems with them.
Yeah, I'd like to know the differences as well. The latest release of FreePIE (1.9.629) is from 2/16/16. The DLL attachments on the first page are from almost 3 years ago. Seems kind of counterintuitive for the newer ones to be not as good.
In other news, I had a development in my Move controller glitching out problem. I tried turning the offending controller off and running the script again (thus turning psmove[1] into psmove[0]), and that controller started having the same glitch. So, I have something going on with my psmove[0] (or the purple orb, maybe) that is causing me problems.
zelmon64 wrote:
Multi-cam isn't currently supported. I just checked what would happen if I ran FreePIE with two ps moves connected then connected an additional two and another camera and tried to run another FreePIE instance. They didn't play well together.
HispsterSloth's new SteamVR plugin will use multi-cam for better depth measurements and coverage. He's confirmed that it's on track for a release by the end of the month.
So, shall I buy another PS Eye? (Found another one at local Pawn shop for a buck.)
This is the experience I had just now. I can't even wrap my head around what could have happened.
Turned on both Move controllers, loaded my "Program Files (x86)/FreePIE" with PSMove API dlls and plugin. Ran "PSAPI_hydra2move_new9" script. Diagnostics showed position x and position y on psmove[0] freaking out like I've been getting.
Closed FreePIE. Remembered that I still had Zelmon's most recent "Release" build on my desktop. Opened that up, tried to run the "PSAPI_hydra2move_new9" script, but got an error due to the plugin not recognizing the attribute for reading the battery level. So, instead, I loaded the older "PSAPI_hydra2move_new6" script. Upon running it, psmove[0] was acting completely normal. Both position x and position y were fully functioning and tracking.
Felt encouraged, so I grabbed the files from Zelmon's "FreePIE_PSMoveAPI_DLLs-201605211530.7z ". I put them in their respective folders inside the "Release" build, overwriting the existing files, loaded up "PSAPI_hydra2move_new9", and upon running it, psmove[0] was behaving correctly again. Hooray! I loaded SteamVR, did the Hydra setup, and sure enough, nothing was glitching. What was happening though was psmove[1]'s yaw was backward.
So, I went back to the script, stopped it, and noticed that I now needed both yaws to be inverted (how I had one inverted but not the other, who knows). I did replace those 16kb and 18kb sixense dll's in SteamVR though. So, maybe that got me on the same page with Zelmon. Back in SteamVR, everything looked good, but for some reason, pressing the PS button wasn't bringing up the SteamVR menu for some reason.
I exited out of SteamVR, went back to FreePIE and checked to make sure everything was working properly. It was, but I noticed that not all of the buttons were being tracked in the diagnostics (mainly, the PS button for psmove[1]). So, I simply added that line of code to the diagnostic section for psmove[1]. No big deal right? Wrong. When I started the script back up, the glitch was back with psmove[0]. Position x and position y were freaking out.
Naturally, I closed FreePIE and restarted it. It's still doing it. The weirdest thing is, the orbs are flashing differently now at start up than they were before I added that simple line of diagnostics.watch(psmove[1].getButtonDown(PSMoveButton.PS)) How in the world could that break everything? It makes no sense.
zelmon64 wrote:Are you sure they're the ones we should be using (the 16kB sixense_fake.dll and 18kB sixense_fakex64.dll that come with FreePIE 1.9.629)? To use these I have to set the rotation.update conjugation back to false. This works for the direction of the orientation but the roll is still not correct (it reverses when the pitch is greater than 90 deg).
I much prefer the ones you posted on the first page of this thread here and here. They're the ones I use in my video. I've had no problems with them.
Yeah, I'd like to know the differences as well. The latest release of FreePIE (1.9.629) is from 2/16/16. The DLL attachments on the first page are from almost 3 years ago. Seems kind of counterintuitive for the newer ones to be not as good.
In other news, I had a development in my Move controller glitching out problem. I tried turning the offending controller off and running the script again (thus turning psmove[1] into psmove[0]), and that controller started having the same glitch. So, I have something going on with my psmove[0] (or the purple orb, maybe) that is causing me problems.
He he, I forgot the start of this thread was so old. That is strange.
if psmove[0].getButtonDown(PSMoveButton.Cross):
psmove[0].autoLedColor = False
#psmove[0].led.SetColor(0, 0, 255)
#psmove[0].led.B = 100
psmove[0].led.B = psmove[0].trigger
if psmove[0].getButtonDown(PSMoveButton.Triangle):
psmove[0].autoLedColor = False
psmove[0].led.R = psmove[0].trigger
if psmove[0].getButtonDown(PSMoveButton.Circle):
psmove[0].autoLedColor = False
psmove[0].led.G = psmove[0].trigger
if psmove[0].getButtonDown(PSMoveButton.Select):
psmove[0].autoLedColor = True
It probably won't solve your problem but it's fun to play with.
I've attached a new libpsmove_tracker.dll which has a different default colour order (blue, red, yellow, cyan. magenta). I tried to use the colormapping.dat file by editing the code so that it doesn't care if it's "too old" but I nothing I did would change the colours (it's a hex file with 7 digits per controller).
Your recent experience reminds me of when the word "joystick" used to brake it. I would have thought I'd have the same problem though if it was a similar issue.
@QBZ I can't think of a reason not to get it if it's only a buck
You do not have the required permissions to view the files attached to this post.
slavian wrote:zelmon64, It still does not work, maybe you write detailed instructions? I will be very grateful.
and another question: need two Move, or only one?
I'm not sure what more I'd put in a guide. Seeing as how you already have FreePIE recognising the PSMoves and StreamVR recognising that it's using the hydra the only part left is the fake sixense DLLs.
I've attached the working ones for clarity.
Rename sixense_fake.dll as sixense.dll then copy it to C:\Program Files (x86)\SteamVR Hydra driver\hydra\bin\Win32 and C:\Program Files (x86)\Steam\steamapps\common\Sixense SDK\SixenseSDK\samples\win32\sixense_simple3d.
Rename sixense_fakex64.dll as sixense_x64.dll then copy it to C:\Program Files (x86)\SteamVR Hydra driver\hydra\bin\x64.
I recall CyberVillain saying something about how DLLs are sometimes blocked if downloaded. To check, right-click on the file and select properties. Near the bottom it may say something about it being blocked and there will be a tick-box to unblock it. Tick that then press apply. Here's what it would look like:
unblock DLL.png
If it works, the sixense_simple3d program will ask you to point the two PSMoves at the camera horizontally and press their triggers. Then it will show you a black sphere (the point of origin) and two red sticks with a lump on the bottom (the PSMoves).
You do not have the required permissions to view the files attached to this post.
slavian wrote:zelmon64! It worked, but the move to twitch SteamVR, and displayed no where necessary... How to fix it?
I'm sorry I'm not quite sure what you mean. Could you please elaborate?
He's probably saying jitter is too much and position is wrong.
Then that would mean increasing the filtering values (1 is max filtering) and swapping some minus signs after the "=" where the positions are defined in the script.
Are you having jitter and position issues then? Did replacing the 16kB sixense.dll with the old 27kB one fix your orientation in SteamVR?
I was actually able to do some testing today. Not sure if the new libpsmove_tracker.dll made any difference or if it's just the random inconsistency I'm getting playing a part, but upon starting the script, the Moves were functioning fine. The piece of coding to change the orb color that you added did not work for me though. They started out blue and red...and when I'd press both Cross buttons to fix my positioning, it would cause psmove[0]'s orb to just turn off entirely and stop tracking.
When I removed that portion of code from the script, and restarted, psmove[0] started glitching again. So, I stopped, closed FreePIE, started it back up...psmove[0] was now fine...but psmove[1] was now glitching. Again, I closed FreePIE, started back up...made sure both Move controllers were in clear view of the PS Eye when I started the script, and this time...they both worked fine.
So, as you can see, I'm getting no rhyme nor reason type of results. It's hard to really draw conclusions from anything, but I'm happy when it works. I will say, in terms of positioning/orientation/centering, having basically three button combos that reset different functions, it can take some fine tuning to get things lined up properly. When you initially load up SteamVR and are instructed to hold the "Hydras" up and press the start button, that doesn't always give you (or me anyway) proper positioning.
But since holding both Cross butons resets positioning, and holding both Circle buttons resets orientation, you can kind of alternate between the three methods until it hones in on how you're holding the controllers and feels closer to your specific movements. I don't know if that's how it's supposed to work by design for us at this point, but that's my best advice for anybody struggling with getting good tracking. Use the different reset functions and adjust your positioning until you get it locked in where you want it.
InfinateXtremer wrote:@Zelmon64 Using old sixense.dll (27kb one) fixed all of my jitter, position and reversed yaw problems. Thank you for that
That's very good to hear ! I was starting to wonder if it had worked or not.
@n8rockerasu That colour changing code is not meant to be used at the same time as SteamVR but separately to see if modifying the colours improves the tracking in FreePIE. The cross does the blue, triangle is red and circle is green (granted, I should have probable matched it to the actual colour of the buttons). When one of those buttons is pressed they use the current trigger value to set the new colour intensity (this is why the blue one turned off). The select button then resets the colour to the automatic one.
I find it strange that you are having such problems with the alignment. When I see this
need_alignment_gesture.png
I place the controllers either side of my head and simultaneously press the hydra start buttons. The vive wands are then either side of me as I lower my arms in more or lass the correct orientation (I use the reset to more easily point to the lower part of the screen). When I reset the position the wands end up quite far in front of me.
You do not have the required permissions to view the files attached to this post.
zelmon64 wrote:
@n8rockerasu That colour changing code is not meant to be used at the same time as SteamVR but separately to see if modifying the colours improves the tracking in FreePIE. The cross does the blue, triangle is red and circle is green (granted, I should have probable matched it to the actual colour of the buttons). When one of those buttons is pressed they use the current trigger value to set the new colour intensity (this is why the blue one turned off). The select button then resets the colour to the automatic one.
I find it strange that you are having such problems with the alignment. When I see this
need_alignment_gesture.png
I place the controllers either side of my head and simultaneously press the hydra start buttons. The vive wands are then either side of me as I lower my arms in more or lass the correct orientation (I use the reset to more easily point to the lower part of the screen). When I reset the position the wands end up quite far in front of me.
Ah, ok. That makes sense. Sorry for not picking up on that myself. I didn't look at the code too closely, so that feels like a "duh" moment for me, haha.
And yeah, my experience with the picture you posted is more or less what you described. Occasionally, the controllers will be turned at like a 45 degree angle though, as if I were facing a different direction. But that could have to do with my camera placement. But I can usually correct it by changing how I'm holding them and then resetting.
My point was just that there are different factors that can have an impact on the accuracy and smoothness of the tracking...just to give people different things to think about if they're having trouble getting things to line up. SteamVR seems to be very particular about camera placement for room scale set up too. With a single camera, you've gotta be decently far back for the viewing angle to be wide enough for what room scale requires. And if anybody runs into the issue of SteamVR assuming you're facing the opposite direction, you can edit your play area and flip (or even rotate), to make sure the arrow is pointing toward your camera.
Other than the weird inconsistencies I've been getting, I think the single camera tracking is the biggest limitation right now. Once hipstersloth gets the multi-cam working, I would imagine the tracking will be much more accurate.
I tested everything to run API version, but with every release I have the same issue. Motion controllers are freckeling and tracking doesn't work at all, so I have to use framework version. It also is good, but it have drift issue. I have suppose, that my drift is smaller then other users issue and it may be fault of bluetooth adapter (I'm usin Asus BT400). Is it possible to make new calibration tool for framework version with API algorithm?
the same here
https://www.youtube.com/watch?v=_DlfJqhVFsg
(when I set psmove[0].autoLedColor = False move stop blinking, but it also stop positional tracking)
gladiusz wrote:I tested everything to run API version, but with every release I have the same issue. Motion controllers are freckeling and tracking doesn't work at all, so I have to use framework version. It also is good, but it have drift issue. I have suppose, that my drift is smaller then other users issue and it may be fault of bluetooth adapter (I'm usin Asus BT400). Is it possible to make new calibration tool for framework version with API algorithm?
I'm sorry to hear that it still isn't working for you. Have you tried the trick of first installing libusbK then libusb-win32 over it? Did you also try the libpsmoveapi_tracker.dll in this post? It has a different default colour order. If it was your usb adapter causing the trouble I'd think you'd have problems no matter what you used.
HipsterSloth and CBoulay are soon going to release a new service which manages any connected PSMoves and PSEyes and also a plugin for SteamVR. If it's SteamVR your using then that should be quite good. I'm contemplating making a FreePIE plugin base on it depending on what it's like (it should have multi-cam support for better positional tracking). I'm not planning on working any more on the MoveFramework version.
@Remlas In your last post you said FreePIE was crashing. Am I correct in thinking that you used the libusbK trick to fix the crashing but now you have the same twinkling as gladiusz?
Just to make things clear so that I can understand the current situation, I believe gladiusz and Remlas have twinkling and n8rockerasu has some other positional gliching. Whereas InfinateXtremer and I have no problems. Did I miss anyone or anything?
The twinkling reminds me of when I used the original MoveFramework version that didn't turn off the camera. If I ran a script twice with out restarting FreePIE the orbs would similarly twinkle. Avast is currently wreaking havoc on my system by analysing some process every time I start a script which causes the tracking to pause and sometimes the orbs to turn off during the first 30s or so. Perhaps something similar is causing simultaneous processes to run and cause the twinkling?
That code solve problem with freckeling and orb lights still, but there is another problem. Gyro seems to working fine, but psmove[0].position.x/y/z shows values about 600 and it isn't changing. However psmove[1].position is working, but it takes values from psmove[0]. I suppose, that it's some magical combination of colors which will work perfect. For example: 0-magenta, 1-yellow, 0 works perfect, 1-values aren't changing.
That code solve problem with freckeling and orb lights still, but there is another problem. Gyro seems to working fine, but psmove[0].position.x/y/z shows values about 600 and it isn't changing. However psmove[1].position is working, but it takes values from psmove[0]. I suppose, that it's some magical combination of colors which will work perfect. For example: 0-magenta, 1-yellow, 0 works perfect, 1-values aren't changing.
If you find a working combination I can set them as the default. I can't test it myself as they all seem to work fine for me. I wonder if there is something different in how our PSEye cameras are generating the images.
gladiusz wrote:I'm using CL Eye. Combination yellow with cyan works but positions are mixed. 0=1 and 1=0
If you swap the colours does it swap the positions?
No, it isn't. It would be too easy
I was hoping that changing the colour wouldn't affect the mask used on the camera so that it would work. Would you mind trying libusb-win32 (with the libusbK trick) again please? I haven't had any trouble since switching from CL-Eye. Make sure there aren't any instances of FreePIE in the task manager when you uninstall the driver otherwise it will ask for a reboot.
Getting more stable results on my side of things. No controller freakout today (I'm starting to wonder if the new libpsmoveapi_tracker.dll changing the orbs to blue and red did actually help somehow). I ran the sixense_simple3d program and tried to see if I could get a bead on my orientation issues. Initially, the orientation wasn't lining up with what I was doing with the Moves. It was kind of interpreting 45 degrees to the right as straight ahead. But I used the double Circle press to reset my orientation a couple times, and eventually got it mirroring my movements very well.
I'm not sure why it's off at first, or if it has anything to do with me having my camera up so high (ie. pointing "straight at the base" is really pointing up quite a bit). But it's very close to 1:1 once I get it tuned in. I'll try taking that into SteamVR later and see if I can fine tune my orientation there as well. I still think the single camera setup is the biggest limitation in being able to play games...but hopefully we'll have a fix for that soon.
I know you've been doing a lot of the legwork on this yourself, Zelmon. Just wanted to say thanks...and hope that whatever hipstersloth comes up with, it's very complementary to the work you've done. Having more minds, hands, and eyes on a project is always a good thing.
First off, Thank you for this as well. You and others working on these types of projects makes me not give up on humanity.
I've been able to get one controller working good no issue paired, and calibrated in seconds. but no luck with a second controller. I've done the instructions to a T. I've tried 2 other ps motion ctrl. 2 different dongles.
-using a ASUS 400 BT which pairs with working ps motion
-Win 10 x64
-it shows up in device manager.
-when running psmovepair. it just says "connected controller: 0" when the working ps motion is connected via BT it saids "connected controller:1 forgetting NON-USB device"
-I have SCP for the nav ctrl =works but I did install (or tried too) to the motion ctrl but have uninstalled it
-is there a debug?
cabmilk wrote:First off, Thank you for this as well. You and others working on these types of projects makes me not give up on humanity.
I've been able to get one controller working good no issue paired, and calibrated in seconds. but no luck with a second controller. I've done the instructions to a T. I've tried 2 other ps motion ctrl. 2 different dongles.
-using a ASUS 400 BT which pairs with working ps motion
-Win 10 x64
-it shows up in device manager.
-when running psmovepair. it just says "connected controller: 0" when the working ps motion is connected via BT it saids "connected controller:1 forgetting NON-USB device"
-I have SCP for the nav ctrl =works but I did install (or tried too) to the motion ctrl but have uninstalled it
-is there a debug?
It's nice to hear we've helped restore some of your faith in humanity
I think you may be skipping psmove-pair-win.exe. psmovepair.exe copies the pc bt mac address onto the PSMove controllers via usb and sometimes manages to pair them. psmove-pair-win.exe will pair all PSMoves via bt once they know the correct mac address. You only need to run psmovepair.exe once per controller then you never need it again unless you pair them to something else in the future. I can confirm that it is possible to have at least four PSMoves connected via bt simultaneously.
Out of curiosity which version of SCP are you using?
@n8rockerasu I appreciate the thanks . If I have any ideas on making it more reliable I'll let you know. I haven't heard anything from HipsterSloth in the last couple of days but the new service should hopefully be available any day now.
zelmon64 wrote:
@n8rockerasu I appreciate the thanks . If I have any ideas on making it more reliable I'll let you know. I haven't heard anything from HipsterSloth in the last couple of days but the new service should hopefully be available any day now.
He posted this on reddit yesterday.
[–]hipstersloth908 2 points 1 day ago
Still working on it. I finished porting over the camera pose setup stuff, wrote the first pass of positional tracking/filtering code (still untested) with the help of /u/bullale, and did the manual color calibration tool last week. You can see a video of the manual color calibration tool here: https://www.youtube.com/watch?v=1eKVqyo52IA. Working on filling in the rest of the steamvr driver today. I'm trying to get a "minimum viable" version of the SteamVR plugin ready by this Wed (June 1). Regardless of the state everything is in on Wed, I'd like to set the depot to public so people who are curious can take a look. I'm going to continue working on the plugin through June, so what becomes available on June 1st, won't be the final word.
So, yeah...hopefully we'll get our first look at it soon.
zelmon64 wrote:
It's nice to hear we've helped restore some of your faith in humanity
I think you may be skipping psmove-pair-win.exe. psmovepair.exe copies the pc bt mac address onto the PSMove controllers via usb and sometimes manages to pair them. psmove-pair-win.exe will pair all PSMoves via bt once they know the correct mac address. You only need to run psmovepair.exe once per controller then you never need it again unless you pair them to something else in the future. I can confirm that it is possible to have at least four PSMoves connected via bt simultaneously.
Out of curiosity which version of SCP are you using?
@n8rockerasu I appreciate the thanks . If I have any ideas on making it more reliable I'll let you know. I haven't heard anything from HipsterSloth in the last couple of days but the new service should hopefully be available any day now.
FIXED, SCP was the issue I assume. The motion controller had LIBUSB drivers installed on it. So i did a driver uninstall(with the "removed drivers from system" box checked). Rebooted and works as it should.
Howdy! I'm largely illiterate when it comes to things of this nature but I managed to scrap along and come out with a somewhat functional setup. I figure at the minimum I could post and add in my experience, possibly get a bit of advice/support. I've been able to get my controllers up and running in SteamVR with a few caveats: first, as far as I can recall every time I start a game my controllers are off to the left by upwards of 45 degrees. A big of finagling with the X/O and PS button calibrations tends to bring them back, although one seems to be always slightly in front of the other (generally the left, red one). Unfortunately on some occasions the mentioned calibrations just... fail, sending the controllers in varying directions and distances. It tends to require dumb luck or a hard reset to bring them back in line when this happens. The tracking also sometimes leaves something to be desired, with drift taking over and eventually switching the position of the controllers on screen. Having said that, when I've been able to get it working properly it's been an greatly enjoyable experience. I'm super excited for things to get better from here. Thanks to everyone here who's contributed in any way, you've gotten my broke ass that much closer to The Future™.
