Ticket #5 (closed task: fixed)

Opened 6 years ago

Last modified 3 years ago

Improve acc and ir plugins

Reported by: dsmith Owned by: dsmith
Priority: major Milestone: Version 1.0
Component: wminput Version:
Keywords: plugins acc ir pointer Cc:

Description

Acc and IR plugins are close to usable, but still need work. Take a closer look at the algorithms and improve them.

Attachments

cwiid-wminput-plugin-enhancements.diff Download (2.8 KB) - added by amp 6 years ago.
A crude implementation of some enhancements to these algorithms
cwiid-acc_move.diff Download (10.1 KB) - added by wic <martin.wickman@…> 6 years ago.
Adds integration plugin (see comment in ticket:5

Change History

  Changed 6 years ago by dsmith

  • priority changed from critical to major

Changed 6 years ago by amp

A crude implementation of some enhancements to these algorithms

follow-up: ↓ 3   Changed 6 years ago by amp

I have done some work in this area. I attached (cwiid-wminput-plugin-enhancements.diff) a patch that includes crude implementations of the following:

  • Low-pass filters on acc (not nunchuk_acc but it could easily be ported). It really helps with playing neverball because it removes the random jurks.
  • Higher multiplier on acc that makes the values go through the entire range of values that neverball expects. I have no idea if this is correct. Someone who knows linux joystick and uinput better would be able to fix it.
  • Low-pass filters on the output of the ir_ptr plugin.
  • Debouncer on input of ir_ptr to avoid switching out of estimated 1 dot mode, where it assumes that the sole dot is at a fixed offset from the pointer not the actual location of the pointer. This was caused by the dot disappearing momentarily. The code I wrote ignores those momentary disappearances.

The code is not very clean, but it would be a good starting point for any work along these lines.

Also I noticed an algorithm used in the GlovePIE ir pointer code: They have a "dead zone". They only report changes when they are greater than a threshold. This makes clicking without dragging much easier. The low-pass partly solves this problem, but I think these 2 approaches might work well together.

in reply to: ↑ 2   Changed 6 years ago by dsmith

amp, I applied your patch, everything but the 2x multiplier. Also copied it to the nunchuk_acc. I thought 2x multiplier was too high for cursor, but I plan to implement configurable parameters for configurations soon, and a scale parameter would give you the functionality you need. Thanks!

  Changed 6 years ago by dsmith

Wow - that turned out to be pretty easy. Plugin parameters are done (r76), the neverball config now has 2x scale. For any plugin algorithms work, especially during the experimental phase, I'd like to use parameters liberally.

amp, also realized that your patch didn't affect cursor...don't know what I was thinking there.

  Changed 6 years ago by wic <martin.wickman@…>

Instead of hacking the existing acc plugin I've created a new one called 'acc_move' (for whatever reason...). It tries to integrate position from acceleration and should in theory be used as a mouse replacement. The plugin contains two different methods of integration which can be selected in the config file as well as other settings:

#acc_move

include buttons

Plugin.acc_move.X       = REL_X
Plugin.acc_move.Y       = REL_Y
Plugin.acc_move.XScale  = 10
Plugin.acc_move.YScale  = 10
Plugin.acc_move.IntegrationType = 1  # 1 for rect, 2 for trapezium
Plugin.acc_move.ZeroCountLimit = 25
Plugin.acc_move.ZeroWindow = 5

There are two major problems with this approach which, in practice, makes it pretty useless:

  1. The first is that calibration is really important and the manufacturer supplied calibration values are sometimes wrong. It just needs to be off by one to give artifacts in the integration. For instance, the cursor tends to go backwards after a movement has occured. This is because the sum of acceleration is NOT zero and this in turn is because the calibration values are biased towards positive or negative g. The best way is to manually calibrate the wiimote.
  2. Rotation. It works pretty well if rotation can be eliminated. There is no way to do that using only the accelerometer afaik. I had to duct tape the wiimote to a plate to ensure planar (translational movement only.

So, consider this as a way to show how it can be done. If someone figures out a way to fix the two issues above, I'll give you the nobel prize :-)

The patch is against revision 90 in the trunk. Also, the thing works somewhat better in continuous mode. Finally, I haven't thought through the time handling stuff, but it is not really that important.

Changed 6 years ago by wic <martin.wickman@…>

Adds integration plugin (see comment in ticket:5

  Changed 6 years ago by wic <martin.wickman@…>

Clarification: You absolutely need to keep the wiimote flat without any rotation, or it wont work.

  Changed 6 years ago by dsmith

Nice idea, but needs to be more robust for general use.

  Changed 6 years ago by dsmith

  • status changed from new to closed
  • resolution set to fixed
Note: See TracTickets for help on using tickets.