# Difference between revisions of "Wiimote/Motion analysis"

Hallowizer (talk | contribs) m (Hardware) |
Hallowizer (talk | contribs) m (Peripherals) |
||

Line 23: | Line 23: | ||

Following a 3-step calibration procedure that requires a table might be a hassle for the user, so a less rigorous procedure may be preferable. Based upon the above example, we might conjecture (possibly incorrectly) that the gain of the sensor (size of ''g'', basically) is more uniform between remotes than the zero offset. In that case, we would only need the remote to be at rest briefly in order to determine the zero offsets for all 3 axes at once. Such a procedure might in fact be the only way to calibrate the Nunchuk sensor, as that controller does not have the flat surfaces needed to perform the 3-step calibration. | Following a 3-step calibration procedure that requires a table might be a hassle for the user, so a less rigorous procedure may be preferable. Based upon the above example, we might conjecture (possibly incorrectly) that the gain of the sensor (size of ''g'', basically) is more uniform between remotes than the zero offset. In that case, we would only need the remote to be at rest briefly in order to determine the zero offsets for all 3 axes at once. Such a procedure might in fact be the only way to calibrate the Nunchuk sensor, as that controller does not have the flat surfaces needed to perform the 3-step calibration. | ||

− | [[Category: | + | [[Category:Peripherals]] |

## Latest revision as of 01:28, 2 April 2021

## Calibration

If we can assume the sensor response to acceleration is roughly linear and the chip is precisely oriented on the circuit board, then calibrating the Wiimote sensor is a three step procedure. We only need the raw integer force sensor readings for these three positions on a flat, level table:

- Horizontal with the A button facing up: (
*x*_{1},*y*_{1},*z*_{1}) - IR sensor down on the table so the expansion port is facing up: (
*x*_{2},*y*_{2},*z*_{2}) - Laying on its side, so the left side is facing up: (
*x*_{3},*y*_{3},*z*_{3})

In each of these cases, we are measuring g on one axis, and the zero point on the other two axes. We can estimate the zero points of each axis to be:

x_{0}= (x_{1}+x_{2})/2y_{0}= (y_{1}+y_{3})/2z_{0}= (z_{2}+z_{3})/2

Starting with any integer reading from the sensor (*x*_{raw}, *y*_{raw}, *z*_{raw}), the calibrated force readings are:

<math>x = \frac{x_{raw} - x_0}{x_3 - x_0}</math> <math>y = \frac{y_{raw} - y_0}{y_2 - y_0}</math> <math>z = \frac{z_{raw} - z_0}{z_1 - z_0}</math>

The calibrated force is now in units where *g* = 1.0.

Following a 3-step calibration procedure that requires a table might be a hassle for the user, so a less rigorous procedure may be preferable. Based upon the above example, we might conjecture (possibly incorrectly) that the gain of the sensor (size of *g*, basically) is more uniform between remotes than the zero offset. In that case, we would only need the remote to be at rest briefly in order to determine the zero offsets for all 3 axes at once. Such a procedure might in fact be the only way to calibrate the Nunchuk sensor, as that controller does not have the flat surfaces needed to perform the 3-step calibration.