Madgwick/sensor fusion is not required
Croquetx opened this issue · comments
I am pretty sure that the angle/axis vector you are getting from the controller is already properly computed on the controller. It is encoded as a unit vector multiplied by the angle. Further integration using Madgwick may actually destabilize the tracker orientation, and it isn't a cheap computation anyway. Works for me anyway.
Hmm... Would you like to do a PR removing it?
I was playing around with latest firmware update of daydream controller to check it was still working and also tried to play more heavily to see how it was tracking.
Noticed the madgwick/sensor integration is really erratic when given orientation close to identity (all zeroes).
Also noticed that some manoeuvres involving rolls would cause it to stay flipped to one side.
In theory, if the daydream controller is already computing a orientation, it might be one those newer chips that do sensor-fusion onboard in the chip already or the daydream has some firmware to compute/track it anyway.
I didn't check, but what's the rate of data coming in? Usually sensor fusion and such is done at a rate of 1000Hz or greater (e.g. like the VR headsets). If the rate of data is nowhere near this rate, then it's likely inferior to what is being done on board.
Indeed, it is running at 60 Hz.
I posted a fix. Also added a reset by holding the home key for one second.
I posted a fix. Also added a reset by holding the home key for one second.
Oh? Where?
Sorry- forgot pull request. Need approval.
Ah, I think you directly cloned this repo. You need to fork it on github first, then clone yours localy, push the new commits and then you'll be able to do a PR from github.
I think you should be able to do all this from github directly by going to this link:
https://github.com/mrdoob/daydream-controller.js/edit/master/DaydreamController.js
Thanks! Still learning Git. Hope this worked.
Thanks for making this available! It is a huge help for me. And Three.js is very elegant. I love using it.