Rotation and Direciton drifts

[mariofvelez]

the rotation and direction values seem to change over time without moving the joycon

[Tetsujinfr]

I would be surprised there is no drift. Joycon likely does no have space grade gyros.
All gyros have some drift over time no?
What is the size of the drift you observe?

[Tetsujinfr]

Did you manage to make sens of the accelerometer and gyro values returned by the library?
I got some pretty high accel values even at rest, accel does not look like accel values. Not sure I read those properties properly, they might be already transformed and not raw sensor values.
Do you know any documentation on this?

[mariofvelez]

Hello, Sorry i have not looked into it in a while. I'll get back to it in a bit, but when I measured it, the gyro values seemed to change at a constant rate, like every 4 times I printed the value, it changed by the same amount. Maybe the readings are off for a lot of the values, but might need a class that handles reading transformations for joy-cons. I haven't looked at any other documentation on this

…

On Thu, Sep 17, 2020 at 6:28 PM Tetsujinfr ***@***.***> wrote: Did you manage to make sens of the accelerometer and gyro values returned by the library? I got some pretty high accel values even at rest, accel does not look like accel values. Not sure I read those properties properly, they might be already transformed and not raw sensor values. Do you know any documentation on this? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#13 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHXLPDUCVSQNS4EEDS6GVQ3SGKZTVANCNFSM4N7JEYGA> .

[Tetsujinfr]

Thanks for your reply. I think I am good with gyro values, my main difficulty is with accelerometer values.
I had a more detailed look at the repo contant yesterday, and at the reverse engineering repo from dekunukem, and it looks like everything in the repo is done properly, e.g. the little endian 2bytes sensor values conversion in the python code.
Now one thing I could have missed: the accelerometer values are returned as a 2bytes long integer, while I would expect a signed float for accelereometer values, or at least a signed integer. So do you think I should tweak the returned values, like remove a constant offset?
Looking at the pyjoycon/joycon.py file, there is a set_accel_calibration(self, offset_xyz=None, coeff_xyz=None) function, so I wonder if I should not have a calibration procedure in place, like put the joycon on the floor, read the accelerometer x,y,z values and pass those to the calibration function as offsets?

What do you think ? Did you use those calibration functions with offsetcall for accelerometer or even gyro, from the library?

[Heath123]

I got some pretty high accel values even at rest, accel does not look like accel values

I think it includes gravity

[Tetsujinfr]

Thanks, that is super helpful, I will give a try at removing gravity from the accel vector. Do you know if there is a function to do that? Usually it is useful to have the orientation to do it better.

[Tetsujinfr]

So I am looking at this again and I cannot figure out how to interpret the accel and gyro values from the joycon api, here are some examples:

scenario 1, left joycon is standing still on a table, pointing to the front wall

Accel x,y,z = {'x': 356, 'y': -1, 'z': 4075}
Gyro x,y,z = {'x': -13.07890446690577, 'y': 0.8719269644603848, 'z': -5.231561786762309}

scenario 2: from case 1, the joycon is rotated -90° on the yaw so now standing still on the edge without buttons (so the one opposite of the edge with sr and sl buttons):

Accel x,y,z = {'x': 2, 'y': -4103, 'z': 220}
Gyro x,y,z = {'x': -37.49285947179654, 'y': 1.7438539289207695, 'z': -5.231561786762309}

scenario 3, from case 2, rotating 90° so that ZL points up at the ceiling:

Accel x,y,z = {'x': 4089, 'y': -151, 'z': 7}
Gyro x,y,z = {'x': 0.0, 'y': -10.463123573524618, 'z': -7.847342680143463}

Anyone who can help who has been using the accel and gyro values to do something meaningful?
thanks

[Tetsujinfr]

ok so not sure how but I did not see the gyro helper class section in the readme... which does quite well what I was looking for.
But to @mariofvelez 's point there is some drift occurring on the direction vector.

in the code of the helper class GyroTrackingJoyCon, it is mentioned that a calibration is necessary

Comes with the need to be calibrated

that may be a cause for the drift, i.e. the need to calibrate a drift offset and feed it to the class.
Not sure how to do it though. is tere some example somewhere on how to do that?

[Tetsujinfr]

ok so by calling the .calibrate(calibration_duration) method of the GyroTrackingJoyCon, with calibration_duration=5.0, and leaving the joycon untouched during that duration, this reduce the drift by 10 times as per my measurements, but it does not remove it fully.
On my joycon, the drift is much more important in one direction than the other two of the orientation. Not sure why, when I look at the calibration code it seems to me that the offset vector should accumulate as a vec3 properly.

[pbsds]

While the IMU in the Joy Cons are way better than in the one in the Wiimote+, it still has its shortcomings. Both in terms of noise and sample rate. It could be possible to play around with different sensitivities and filtering techniques to combat this noise, but finding other sources to combat the drift (like gravity ;) ) is still neccesary.

I believe the Oculus Quest controllers use a IMU to measure the faster micro scale changes, and use its camera tracking to combat drift on the macro scale.

The callibration code i wrote is naive and it does not account for factors such as the rotation of the earth, or different sensitivities for the 3 rotational axes. The sensor may also be non-linear, which is not accounted for.

[Heath123]

It would be nice if it could work like it does in Super Mario 3D All Stars

[pbsds]

I have yet to try that game, but if a pointer is all you need then I'm guessing it works much like how the LG smart TVs do it:

It disallows the pointer to move outside of the edges of the screen, effectively turning the corners into calibration spots. Finally it could use direction of gravity to keep the roll from drifting.

Implementing this should be relatively simple and a fun exercise. I'm busy writing a masters thesis, but perhaps my outlined description inspires someone. ;)

[Heath123]

From what I remember you can move the pointer off the edge, but I'll have to play it again to see