Measuring with Leap Motion

[janiregt]

I am measuring with the Leap the tip point of three tools that are joined in the bottom of them so that I can know the real distance between them and the distance that the Leap measures and compare them.

What it happes is that the when I got the points distances, I realize that sometimes it changes from one point to another and that it doesn´t continue a logic order to count the tools, sometimes it starts from the right, sometimes from the centre...

These are two diagrams of two points that I have got where you can see what I mean.

first point:

second point:

At one point in the time it changes from one to another and then it returns to the same point.

does someone know why this is happening? Could it be because of the symmetry? Should I change the diameter of one os the tools?

Any help will be appreciated. Thank you.

[LM_Kevin]

Hi Janiregt,

This looks to be an ID persistence issue. The order of the returned tools in the list is arbitrary and could change frame to frame. If you always looked at the first item in the list, then it would appear random what is changing, especially on the X axis. Since that is what is most variable between the objects.

Your suggestion of trying different sized tools to help maintain separate identification is a reasonable intuitive step but it may not help much. Tool identification does not specifically have categorization/ID bucketing based on dimension information.

If the lighting conditions are at all tricky (overhead lighting, near skylight or window during the day) the potential for tools being dropped for a frame or two and coming back with different IDs goes up.

The good news is our next generation (V2) tool tracking does take this into account and this issue does not occur. And if for some reason a tool is killed, it will obtain a new ID when it spawns instead of swapping with another tool.

I hope this helps.

[u_cap]

LM_Kevin: The good news is our next generation (V2) tool tracking does take this into account and this issue does not occur.

Kevin, would you mind clarifying if and how this is available?

[u_cap]

Janiregt:

See here

https://developer.leapmotion.com/forums/forums/6/topics/1444

and maybe here:

https://developer.leapmotion.com/forums/forums/6/topics/1743

You could use length instead of width to discriminate tools from each other.

The Leap works (according to the patents filed) by fitting ellipses to stereo scanline slices, essentially a triangulation. Problem is that an ellipse has 5 parameters (baseline position, distance to camera, both axises of the ellipse, angle of rotation) which requires 3 cameras. One big - and completely unutilized - advantage of tool use cases is that a tool can be guaranteed to be cylindrical (constant width, ellipse cross-section of circle) which means the 4 edge samples from a 2 camera scanline actually overdetermine the solution.

See here for references:

https://community.leapmotion.com/t/leap-patent-application-and-other-references/717

In short, width computation might suck, but straight, clean, constant reflectivity tools might provide decent length values. The transition to the hand holding these is likely your biggest source of length variation. Maybe a a "fork" approach - clean juncture, hand further down - might help. The study done at the TU Dortmund - which unfortunately omits a lot of relevant details - used a flat circular plate (think hand guard on a fencing weapon) on which the tool was mounted perpendicular.

The simplest approach might be to try to map whatever the current pointable "ID" is to your own using spatio-temporal continuity - take the three tools and do a least square fit to the last known position/orientation of three line segments. If your sampling rate is high enough relative to the motion of the tools (and if the angles between the tools do not change), you should be OK. If the tools can move relative to each other, then your fit becomes more complicated.