New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add velocity-based control mode #5

Merged
merged 6 commits into from Dec 31, 2015

Conversation

Projects
None yet
2 participants
@trishume
Collaborator

trishume commented Aug 16, 2015

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's update method.

@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.

screen shot 2015-08-16 at 5 19 29 pm

float dy = valY - prevValY;
prevValX = valX;
prevValY = valY;
valX = dx*100;

This comment has been minimized.

@trishume

trishume Aug 16, 2015

Collaborator

Arbitrary scaling factor but seems to work well.

@trishume

trishume Aug 16, 2015

Collaborator

Arbitrary scaling factor but seems to work well.

Show outdated Hide outdated transform.cpp
axis.step(norm(-valX/maxValX), norm(-valY/maxValY), elapsed, accX, accY);
x = accX;
y = accY;
accX = 0;

This comment has been minimized.

@trishume

trishume Aug 16, 2015

Collaborator

I just moved this around so it was easier to read.

@trishume

trishume Aug 16, 2015

Collaborator

I just moved this around so it was easier to read.

@uglyDwarf

This comment has been minimized.

Show comment
Hide comment
@uglyDwarf

uglyDwarf Aug 18, 2015

Owner

Hi,
I'm sorry I'm responding only now - there are just too many things happening around here these days...

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...

Owner

uglyDwarf commented Aug 18, 2015

Hi,
I'm sorry I'm responding only now - there are just too many things happening around here these days...

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...

@trishume

This comment has been minimized.

Show comment
Hide comment
@trishume

trishume Aug 18, 2015

Collaborator

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.

Collaborator

trishume commented Aug 18, 2015

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.

@trishume

This comment has been minimized.

Show comment
Hide comment
@trishume

trishume Dec 10, 2015

Collaborator

@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:

  • The default settings don't work well for velocity, but they are easy to tune to be nice.
  • I was too lazy to do thresholding properly for multi-screen so it works well for the primary display and you can move your cursor onto secondary displays but it won't threshold.
  • Dragging to select text in Google Chrome is broken, I think this is a fundamental issue with absolute mouse movement. I'm not sure this is easy to fix.

Anyhow, you can review the code and tell me if there's any tweaks you'd like me to make.

Collaborator

trishume commented Dec 10, 2015

@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:

  • The default settings don't work well for velocity, but they are easy to tune to be nice.
  • I was too lazy to do thresholding properly for multi-screen so it works well for the primary display and you can move your cursor onto secondary displays but it won't threshold.
  • Dragging to select text in Google Chrome is broken, I think this is a fundamental issue with absolute mouse movement. I'm not sure this is easy to fix.

Anyhow, you can review the code and tell me if there's any tweaks you'd like me to make.

uglyDwarf added a commit that referenced this pull request Dec 31, 2015

Merge pull request #5 from uglyDwarf/velocity-control
Add velocity-based control mode

@uglyDwarf uglyDwarf merged commit 5b0a27b into master Dec 31, 2015

@uglyDwarf

This comment has been minimized.

Show comment
Hide comment
@uglyDwarf

uglyDwarf Dec 31, 2015

Owner

I'm sorry it took me that long - these Christmas are far more hectic than I hoped for...

Kind regards,

Michal

Owner

uglyDwarf commented Dec 31, 2015

I'm sorry it took me that long - these Christmas are far more hectic than I hoped for...

Kind regards,

Michal

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment