Add velocity-based control mode #5

merged 6 commits into from Dec 31, 2015


None yet

2 participants


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

@trishume trishume commented on the diff Aug 16, 2015
+ if(mode == Mickey::Velocity) {
+ float dx = valX - prevValX;
+ float dy = valY - prevValY;
+ prevValX = valX;
+ prevValY = valY;
+ valX = dx*100;
trishume Aug 16, 2015 Collaborator

Arbitrary scaling factor but seems to work well.

@trishume trishume commented on an outdated diff Aug 16, 2015
x = norm(-valX / maxValX);
y = norm(-valY / maxValY);
//std::cout<<"valX: "<<-valX<<"=> "<<x<<" Limit: "<<maxValX<<" CurrentLimit:"<<currMaxValX<<std::endl;
+ }else{
+ axis.step(norm(-valX/maxValX), norm(-valY/maxValY), elapsed, accX, accY);
+ x = accX;
+ y = accY;
+ accX = 0;
trishume Aug 16, 2015 Collaborator

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


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,


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:

  • 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 uglyDwarf merged commit 5b0a27b into master Dec 31, 2015

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

Kind regards,


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