Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[foobie42]

That's related to 3-point perspective-n-points problem. There are 2 equal solutions to the problem, additionally, sometimes software loses track of which point is which.

Patrick put safeguards against both issues when he first submitted the PT tracker, but they only help on continuous frames. If tracking is ever lost, both issues can occur.

There are also some thingies to adjust like minimum point radius, and binary thresholding strength. You can see it in PT tracker options without stopping tracker operation.

[foobie42]

This is the least I can do https://sourceforge.net/p/facetracknoir/codegit/ci/b4bae5a6020c591be6f60d1d51e25ab2de631f91/

cheers

[cameni]

Hmm, I see .. but this seems to be some extra problem atop of that, or it confuses it really badly - because in this case yaw becomes stuck at 180° most of the time, pitch changes only little, roll is usually at 49 ... and in this state it's prone to freezing for a couple of seconds too.

[foobie42]

If your model looks like this:

Code: [Select]

__
\ /

And the down-center point is facing upward when tracking is lost, it'll confuse points with each other.

Is this the case?

Edit: At best can introduce a reprojection error check, if it gets big, switch back to init phase, to minimize breakage. But only for opentrack. If you're only evaluating the software for the purpose of implementing support, there's little point...

[cameni]

My cap is similar to this http://www.nilojr.com.br/DIY-Trackir/adesivo/marcelo/trackir2.jpg except there are 3mm IR leds. When I turn the head sideways so that the camera sees only the top point and one of the bottom points, and then I turn back, then it happens.

[foobie42]

Does the same happen when you have dynamic pose resolution off? Nevermind problems that dynamic pose resolution was supposed to solve.

In point_tracker.cpp -> PointTracker::track I'd change the call from reset_velocities() to reset() completely. Depends if you can compile the software on your own. Sadly opentrack's ABI is incompatible with FTNOIR plugins, due to VPTR changes, different CRT version, and more.

If you can provide a video of this happening, like a webcam feed with points visible, as well as model dimensions, I'm offering to get to the bottom of this and committing changes to opentrack.

[cameni]

With the dynamic pose off it behaves differently, it doesn't get stuck but pitch and roll change with yaw.

Here's what I get:


I can make a video of the input, but as it seems to be a problem between my camera/cap and the tracker, it doesn't affect the general functionality. We'll see how the FT support works for others in OT first.

[cameni]

I'd like to combine this better with the Oculus Rift tracker, to add the positional tracking into it. Since the Rift provides the orientation, the problem of detecting which point is which could be simplified and made more robust, and the position alone could be inferred just from two points. It would be cool to add two IR LEDs directly into the Rift chassis and add support for pure positional tracking into FTNoIR or OpenTrack. Actually, raw positions of two points would be enough I think ...

Or maybe this should be done by putting some stickers on it and use it with normal cameras.

[foobie42]

Actually, in opentrack, as well as ftnoir, there's support for using two trackers at once with selecting axes they provide.

In opentrack there's Rift support, you may want to try using it as a primary tracker, with positional data provided by secondary PT.

But it's understandable you want native Rift support inside the software, without requiring any third-party stuff.

Stickers would hardly work, unless someone trains a Haar classifier for them, which is robust but fast enough to run every frame... Of course there's the matter of solving a 2-point perspective-n-points equation and providing the relevant data.

[cameni]

I can combine Rift and FT already, but I think FT tracking could benefit from the info that Rift already has. If I could get just raw screen positions of detected points, a two-point positional tracking built on top of the Rift can be fast and robust.

With the stickers I meant something that can be easily detected and discerned from the rest, to get the screen positions.

[Jagerbomber]

Stupid question... So this tracking works with just a webcam and the LEDs?
Where would I get the LED cap or clip or whatever?

[cameni]

It's actually both positional & rotational position that is gotten from it, as in the video. And the LEDs are infrared, to avoid interference with normal light. The camera should have an IR filter as well.

[Jagerbomber]

It would be sweet if they added positional LED tracking on the Rift.  Maybe a separate optional kit from them that works well with it.

I really gotta get into this IR tracking stuff..... (or something better, idk).

[zaelu]

Very nice Cameni! When it will be implemented in Outerra?

[cameni]

In opentrack there's Rift support, you may want to try using it as a primary tracker, with positional data provided by secondary PT.

Tested with opentrack-20130716_1, but it always silently quits after a seemingly random number of seconds of normal function, after the tracking is started.

Btw either with FTNoIR or with OpenTrack and with the point tracker, there are no raw point values (X1-X4, Y1-Y4) except for X1. Could it be done so that they would be always present, even if there's not enough points to infer the pose data?