AndersMalmgren / FreePIE

Programmable Input Emulator
650 stars 144 forks source link

Wiimote[n].ahrs wrong behavior #135

Closed neonflux75 closed 7 years ago

neonflux75 commented 7 years ago

Without moving the Wiimote and letting it lay down on the table the expressions:

wiimote[0].ahrs.yaw wiimote[0].ahrs.pitch wiimote[0].ahrs.roll

are not giving a fixed value (as they have to do), instead they give a number that continuosly increse/decrease by a little causing it loose the calibration of 0 spot

zelmon64 commented 7 years ago

@neonflux75 unfortunately I'm pretty sure this is a hardware limitation. All IMU's drift which is why devices like the wiimote use a combination of techniques (ie. the wiimote's camera). You can use a deadband filter to try to mitigate some of the drift.

neonflux75 commented 7 years ago

I already use a deadband filter to obtain the movement from the pisition 0

yaw = 350*filters.deadband(filters.delta(wiimote[0].ahrs.yaw),0.01)

where 350 is simply a multiplier

This expression works very well, the problem is that the wiimote[0].ahrs.yaw, whitout moving the controller, is not oscillate by for example +0,01/-0,01, instead it ramp up or down for example: 0 (start of the script) 0,0001 0,0034 0,0067 0.0090 0.0130 0.0160 ... ... after two minutes... 3.456

and so on, like i rotate it, but it is absolutly steady! Then, when i finally rotate it for real the car will turn (for ex. left) and when i turn back in central position the car is still turning left by a little (or more) cause the 0 is affected by an offset now. Hope this is clear (not so good at english sorry) :)

zelmon64 commented 7 years ago

@neonflux75 yeah that drift is unavoidable.