fossephate / JoyCon-Driver

A vJoy feeder for the Nintendo Switch JoyCons and Pro Controller
https://fosse.co/latest.zip
MIT License
1.07k stars 195 forks source link

ACC/Gyro, coeff, cal and raw values converting #76

Open CTCaer opened 6 years ago

CTCaer commented 6 years ago

I disagree with subtracting the acc cals here. It should only be used in the coeff. https://github.com/mfosse/JoyCon-Driver/blob/6886a86d27ff5303079304c904629fc24e8deac6/joycon-driver/src/main.cpp#L276

It produces wrong values. The cal here is not exactly the origin position. It's actually the position the controller has when you level it on a flat surface and the trigger protrudes the surface. you can test it by raising the trigger opposite end of the controller. It should produce values of around [0.0, 0.0, -9.8 or -10.0]m/s^2. (Z axis is -9.8 or -10 depending on the accuracy of math calculations.) or (If you don't convert to SI) [0.0, 0.0, -1.0]G


The following though, as stated by @JibbSmart seems correct: https://github.com/mfosse/JoyCon-Driver/blob/6886a86d27ff5303079304c904629fc24e8deac6/joycon-driver/src/main.cpp#L292 The gyro cal here is indeed what the IMU produces when still. And it must be used to both the coeff and the raw value calculations. I tested it and the values are closer to 0.0 when resting. Sorry for writing wrong documentation.


But i want to state something else also. I see at your code that you state (variable naming) that the math you do is for degrees.

If that's the case, then you should not use 0.01745329251994 degrees to radians converter constant.

For Degrees/s - dps: gyro_cal_coeff[0] = (float)(936.0 / (float)(13371 - uint16_to_int16(sensor_cal[1][0])));

For Radians/s - rad/s: gyro_cal_coeff[0] = (float)(936.0 / (float)(13371 - uint16_to_int16(sensor_cal[1][0])) * 0.01745329251994);

For Revolutions/s - rps - rev/s: gyro_cal_coeff[0] = (float)(936.0 / (float)(13371 - uint16_to_int16(sensor_cal[1][0])) * 0.0027777778);

Unfortunately, I don't have time to review the math involved to understand what units you use, so if you use rad/s math it's ok. But please check, because using the wrong values can have 6x, 57x or 360x times difference.

JibbSmart commented 6 years ago

That makes sense to me. I guess that the accel calibration info is instead mostly useful for sensor fusion -- determining confidence in the accel vector as a gravity vector for correcting absolute orientation calculated by integrating gyro data, and also for cancelling out the gravity vector from accel input so we can detect linear movements by the user (shaking the controller, for example).

CTCaer commented 6 years ago

Yeah, internally in switch, it is mostly used as a fusion sensor. But it also has functions to use them separately.