Help verifying code error in Wiimote plugin

Official forum for open source FreePIE discussion and development.
Post Reply
MeteorFalling2
One Eyed Hopeful
Posts: 42
Joined: Thu Dec 08, 2016 10:23 pm

Help verifying code error in Wiimote plugin

Post by MeteorFalling2 »

Many months ago I found an error in the Wiimote plugin for Freepie. Specifically it was in regards to how Freepie corrects voltage change in gyros by the DolphiimoteDll.cs file on lines 143-145. The correction is defined as 'slow_modes' and is meant to compensate for sensitivity changes when the voltage would increase. https://github.com/AndersMalmgren/FreeP ... ta.cs#L143 I discovered that the gyro.Value inputs are incorrectly mapped, causing undesirable gyro readings when the Wiimote gyros would enter into a voltage change caused by swinging the Wiimote. Instead of Yaw(x), Roll(z), Pitch(y) being 0x1 , 0x2, 0x4 respectively, the values should be Yaw = 0X4, Pitch = 0x2, and Roll = 0x1. The comment in this file should also be updated to reflect the correct mappings: https://github.com/AndersMalmgren/FreeP ... DLL.cs#L30

To clarify what is going on: When one swings the Wiimote on the Yaw axis, the gyro enters into a voltage change. This increased voltage causes the gyro sensitivity to increase. In order to correct for the sensitivity so the reading are more or less constant regardless of force, the program applies a slow mode to the gyro readings. Without the correction, there would be an obvious acceleration in the data, that if used for a mouse script for example, would cause the cursor speed to suddenly increase, similar to having mouse acceleration applied.

What the incorrect mappings are doing is that when one swings the Wiimote in something like the Yaw axis, it applies the Yaw sensitivity corrections to the Pitch axis, causing either a jump or dive depending on left or right movement. And since there is no correction to the sensitivity on the axis under force, there is a sudden acceleration that compounds the problem. This behavior is happening on all axis.

I only tested my findings on 3 Wiimotes, but I had both the TR and non-TR versions with motion plus attachment to test with, so I am fairly confident this is a problem for all official Wiimotes.

Would anyone verify my finding by running the simple gyro-mouse script below? You have to hold A to cause movement. Start off by holding the Wiimote still, pointing at the screen. Slowly move it left. Pause. Move slowly right. Pause. Each time you Pause let go of the A button and position it back to the default position. Now do the same, but this time move quickly for each direction.

Does the mouse cursor dive and rise when moving it slowly left or right? What about when you move it quickly? If you want, you can test Roll by making it control mouse.deltaX instead which will allow you to test the spikes from vertical movements.

Code: Select all

import thread, time

def update():
	yaw = filters.deadband((wiimote[0].motionplus.yaw_down), 0.15) 
	pitch = filters.deadband((wiimote[0].motionplus.pitch_left), 0.15)
	#roll = filters.deadband((wiimote[0].motionplus.roll_left), 0.15) 
	
	#Hold A for mouse movements
	if wiimote[0].buttons.button_down(WiimoteButtons.A): 
	
		mouse.deltaX = yaw/16 ## add a negative to the 16 if using non-TR version. Replace 'yaw' with roll to test vertical spikes.
		mouse.deltaY = pitch/-16 ## remove the negative if using non-TR version.

if starting:

	system.setThreadTiming(TimingTypes.HighresSystemTimer)
	system.threadExecutionInterval = 2
	wiimote[0].motionplus.update += update
	wiimote[0].enable(WiimoteCapabilities.MotionPlus)
Post Reply

Return to “FreePIE”