Errors accruing with Joycon rotation
-
So I'm currently working on a project which utilises the Joycon's motion sensors - in particular, rotation when the Joycon is lying on a flat surface.
I have the core rotation logic sorted, but I'm noticing that it's accruing a rather significant amount of error. In particular, if I start with the Joycon in one position, then rotate through 360 degrees clockwise, it says I've gone a further 32 degrees clockwise. If I then rotate 360 degrees anticlockwise, the errors cancel out, so it overshoots by around 32 degrees in both directions (and pro-rata amounts if I make a quarter turn/etc.)
The main theory I'm working with so far is that the little ergonomic bump on the Joycon means the Joycon isn't parallel to the surface, so my rotation logic needs to account for this. I also have a similar issue (with a slightly different overshoot amount) with the right and left Joycons, so I don't think it's a hardware issue.
But, before I dive into the nitty-gritty of hardware design, I figured I might as well post the skeleton code here and see if there's a bug I'm missing...Thanks for any help you can provide!
c = controls(0) co = c.orientation[0] // get orientation of left joycon north = co // angle relative to initial orientation loop clear() c = controls(0) co = c.orientation[0] orient = {co.x, co.y, co.z} // We want the angle in the x-z plane dotProd = orient.x * north.x + orient.z * north.z det = orient.x\*north.z - orient.z\*north.x angle = atan2(det, dotProduct) if angle < 0 then angle += 360 // values between 0 and 360 rather than -180 to 180 endif print(angle) -
Just a quick update on this - after a little bit of experimentation, I've developed what seems to be a solution!
At the start of the program, the user needs to undergo calibration - here, all they have to do is line up the left Joycon against some "wall" (the right joycon works nicely) turn it 360 degrees, and line it up against the "wall" again. This calculates the error rate - and, when calculating the angle of rotation, this error is taken into account.
There's also a few other improvements under the hood, including being able to consider angles over 360 degrees (for instance, winding up a dial or advancing a clock),
I've still got some cleaning up to do, but when that's done I'll make a new post showcasing the system and sharing the project for others to rework/improve/build upon.
-
I think the calibration seems like a great solution. Well done!
-
Yeqh, motion controls are quite prone to drift and errors over time or problems with accuracy.
The Wii was rife with games that required 'calibration'. - especially games that used the motionplus add-on (gyroscope)
Since what you're doing depends on the gyroscopes, it looks like you've hit a similar problem.A calibration step is a sensible solution.
Though sometimes you can be a bit more clever and hide the calibration behind the scenes,Since FUZE returns a normalised vector, converting it to an angle measure does carry a few additional issues.
But it seems you've found a workable solution for now.I've yet to really experiment with this stuff on the Switch, so I'm not sure yet what the accuracy issues look like.
I know the 'velocity' readings (which are actually 'acceleration' data as far as I can tell) are reporting gravity in newtons or m/s^2 but the error for the magnitude is off by as much as +-0.5 units...
I dread to think about what trying to do dead reckoning from this would be like.
But then I already know it's basically impossible on the Wii, so I wouldn't really expect a massive improvement from the switch in that regard. -
Have you already done a recent calibration in the OS itself? - https://en-americas-support.nintendo.com/app/answers/detail/a_id/22340/~/how-to-calibrate-the-controllers
