Add velocity-based control mode #5
Conversation
| float dy = valY - prevValY; | ||
| prevValX = valX; | ||
| prevValY = valY; | ||
| valX = dx*100; |
There was a problem hiding this comment.
Arbitrary scaling factor but seems to work well.
|
Hi, I merged the mutex fix - nice catch... I just wander why it didn't pop up when I rested it (maybe newer OS X versions are even more aggressive)... As for the velocity control - I like that... The only thing that doesn't seem right is this: when working with mouse in a confined space, for example when you need to move the cursor to the left, you sometimes have to raise the mouse, move it to the right and put it down again to be able to continue moving left. The velocity mode allows me to do similar thing (moving my head right so I can continue moving left) only at super slow speed... I wander if adding a threshold at the higher velocity might allow a behavior similar to mouse (quick "jerk" would not move cursor)... Kind regards, Michal PS. Some time ago, I was wandering if there is a way to switch seamlessly between absolute mode (good for rough, but quick movement) and the relative/velocity mode (good for precise, but smaller scale movements)... Unfortunately I was not able to devise a reasonable logic to switch between the two modes without the user interaction... |
|
That's a good point, this mode definitely needs some tuning to be nice. Your suggestion made me realize that my other head mouse system actually has this as a cap on the speed it will move. I end up quickly jerking my head to reposition. The other way to reposition is curvature, moving slowly back to the centre will move the mouse less than moving fast. But the idea of a hard threshold might work even better because you wouldn't get any unwanted motion if you exceeded it. Auto-switching is an interesting idea but it would be hard to do right. One possibility is instead of having two modes having two inputs. For example eye tracking is great and fast but not accurate enough. There could be an inaccurate eye tracking system for selecting approximate regions and then relative movement around that point with head tracking. |
|
@uglyDwarf I finally got around to fixing this up and making it usable. It's now a fairly pleasant experience probably close to the real SmartNav software (although I've only seen video of it). I made it send the correct drag events on OSX when used in combination with some other device for clicking (I use a foot pedal). Previously it also jumped the curser to the point top left of the screen whenever you sent an event to move the mouse out of screen bounds, so I added a function that confines the cursor to the screen. Being confined to the screen means you can quickly adjust the centering of the cursor by pushing it on the edge of the screen, where your head moves but the mouse does not, allowing you to adjust the relative calibration. There are still a few minor issues, but I think this is good enough to merge now. The issues I've noticed:
Anyhow, you can review the code and tell me if there's any tweaks you'd like me to make. |
Add velocity-based control mode
|
I'm sorry it took me that long - these Christmas are far more hectic than I hoped for... Kind regards, Michal |
Fixes #4. Adds another radio button for a velocity based control mode. Most of the code in this PR is small changes to refactor the assumption that there are only two modes. The actual velocity control code is in
transform.cpp'supdatemethod.@uglyDwarf for review. Since this is a bigger change feel free to suggest better ways to do things and I can tweak this PR.
This PR is based on #3 because that hasn't been merged yet and I needed it to test this.