Stabilized Palm Position Gamma Value

[dtex]

Using the JS library I'm seeing unexpected values on the gamma axis for stabilizedPalmPosition.

Alpha and beta seem to track very closely to palmPosition, but gamma does not. Is this expected behavior?

Take a look at these charts. palmPosition is blue, stabilizedPalmPosition is green. You can barely see the latter peeking out on the alpha and beta charts be it is way off on gamma:

Bigger Here:
https://plus.google.com/+DonovanBuckDtex/posts/fzt3bMAoQC2

I made these by waving my hand around over the leap on each axis while tracking both positions.

Just in case, here's the code I used to capture the data:

<script src="http://js.leapmotion.com/0.3.0-beta2/leap.min.js"></script>

<script type="text/javascript">

var timer = Date.now(), values = [];
var controller = new Leap.Controller();
controller.on('frame', function(f){
  if (f.hands.length > 0) {
    var vals = {
      t: Date.now(), 
      pP: f.hands[0].palmPosition, 
      sPP: f.hands[0].stabilizedPalmPosition 
    };
    values.push(vals);
  }
});
controller.connect();

</script>

Thanks

[dtex]

I chose poorly when using the terms "alpha", "beta" and "gamma". Please substitute "x", "y" and "z" respectively.

[Joe_Ward]

The stabilization is velocity dependent. If you move your hand slower, you should see a larger difference between the normal and the stabilized positions. My hunch is that your results above are because it is easier to your hand faster on the x and y axis than it is on the z axis. It is also possible the filtering and stabilization is different for the z axis (I don't know all the details here).

[dtex]

Thanks for the reply.

I'm inclined to agree with your latter suggestion that filtering and stabilization is different for the z-axis. I found a more complete description of stabilizedPalmPosition in the Java docs:

Stabilized Palm Position

It mentions that it is being optimized for 2-D content. I'm just curious what those optimizations are.

[tylerz]

Actually, just doing some depth axis stuff myself here, and with stabilized palm values the Z component is hugely different in its behaviour. Where X and Y are precise for faster movements and lag behind for small motions, Z does the opposite. Moving my hand from front to back (for example) fast causes the palm position Z component to barely change at first, while sphere center immediately changes to the appropriate values, and then it takes a second or so before the palm position Z component catches up to the correct position. Without specific arguments for this behavior and it specified in the documentation, I would say this is a bug. And being that it is almost the exact opposite behavior to X and Y, I think it is likely it is unintentionally a missed update of the code.

[AndersAnd]

+1
I am having the exact same problem. Please fix!

[mariorptorres]

According to the LeapC documentation the Stabilized Palm Position is generated to be more suited for 2D applications.
I'm looking at the last version so they might have changed it since this question was asked, but it makes sense to more stable in 2 directions if that was the original purpose.