Print

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

[cameni]

Testing opentrack-20130731 with aruco - values shown in the tracker differ from what is sent via the FreeTrack protocol. The main problem is that Z/RawZ saturates at 999, while the tracker can go much farther than that (anything >60.0 shows as 999 in RawZ).

Two questions:
- how do I convert FT translation units to the values shown by the tracker?
- why are the filtered and raw values different even when no filter is used?

I've been using the filtered values from ftnoir and opentrack, and found that those are quite unstable, often sticking/saturating at odd angles and losing track, while the raw values seem to be much more usable.

[foobie42]

1) Divide values by ten.
2) There's a spline applied mapping real-life values to game output. Check the 'curves' tab, you can drag the control point to upper-right corner if you wish.
3) Make a proper gain for the filter, Accela -> Preset -> rotation:2, translation:1 for starters. Reduction factor should be at 1k, max value, since this is polling interval. Accela splines are extrapolated linearly into infinity, unlike game mappings, which are bounded at last control point.

Alternatively you can take the BSD-licensed Aruco library and integrate it with your software. You might have to use sthalik/aruco if it fails to build, e.g. under the GNU compiler, or with OpenCV from git.

I don't know the dimensions of the VR headset, but if it's bulky to the sides, you can splat more markers. Each has an id, it works as long as they're unique. That can solve the ~70 deg yaw limit.

Thresholding is a pain, if any user has asymmetric lighting e.g. due to a window to the side, problems are bound to occur. That's why Otsu thresholding fails for me badly and have to use a less elaborate method of detecting marker's edges.

[cameni]

I don't think the filter section does anything there (with aruco and FT). Changing the gain did nothing to the translation values, nor making the curve linear y=x. I can see the raw value of Z going fine, but filtered Z always saturates at ~40cm from the camera, and that's what I'm getting with FT protocol.

Even setting the filter to none behaves as if there was the default Accela filter bound, and I'm definitely not receiving the raw translation values in FreeTrack protocol, they are the same as the filtered ones.

[foobie42]

Do you have a profile selected in the upper-center box? If you have none whatsoever it might fail to work. Just saying.

Only the filter spline extrapolates. The game output spline needs to be dragged as much as you want output to the game. If max y = 40, it'll be bounded to that value.

Additionally, unless camera FOV is correct-ish and marker is exactly 7 cm in size starting from the black border, translation values won't be in real-life units Can add a marker size option again, didn't think anyone would care about that.

As for raw values, that's correct. And it's the same way as in FTNOIR, no one until you cared about that :-)

[cameni]

Yes I have saved it in a custom profile, restarted.
Output spline in the filter is set like this:


Attached the file with my settings.

[foobie42]

Set a linear spline in the curves window, activated by the bottom-right button. Right now it seems to use some nonsensical default-profile value, outside the window's bounds. Will provide access to raw FT data in the next binary build.

[cameni]

Ok, it's better, allows me to get further from the camera, like ~65cm instead of 40. However, the raw values continue beyond 100.0, the filtered ones saturate. Would it be possible to let them go beyond that? Or I might just use the raw ones once they are in in the next build.

With camera fov ~45° and a 10cm marker it's much more comfortable if I could be >1m away, especially with the Rift, it provides much larger operational area. I guess that eventually I'll integrate aruco directly, to save people the trouble, but I'd like to get it working with opentrack first.

[foobie42]

http://ananke.laggy.pk/opentrack/opentrack-20130803_1.7z

Do tell if there are any new problems with detecting the marker. I've removed gaussian blur prior to 'adaptive' thresholding, and increased the box size. You can easily check if it's detected by a red border around the black frame.

Lots of grain in the image will dramatically increase CPU usage though, due to contour finding being a mess

[cameni]

Perfect. The marker is detected without problems, now it also uses less CPU, but that may also be because it got dark outside

It works pretty nicely in combination with the Rift, with absolute positioning it's less dizzy, as the picture reacts to the full motion and brain doesn't get confused.

[cameni]

I've posted a blog about ArUco+opentrack+outerra: http://outerra.blogspot.sk/2013/08/absolute-positioning-with-oculus-rift.html

The thresholding is indeed a problem there, when there's a brightly lit spot somewhere on the image it will fail. I had to add extra light source to to boost the marker brightness.

[foobie42]

You may want to run 'aruco_test.exe live' to see how thresholding works in the first place.

For the first slider, the setting is 11 (box filter neighborhood), for the second one, it's 5 (thresholding sensitivity).

You may want to reduce camera gain to avoid overbright marker when rotated toward the light. It's unfortunately not totally light-invariant, as light on high gain totally blinds the marker, making it all white... Hard for the detector to see markings if there aren't any in the first place.

Brightly-lit spots ANYWHERE in the image won't break thresholding, as it works in a 11x11 neighborhood, provided the marker isn't nearly close to that spot. If you have like me natural light from the side however, it can cause problems with yaw.

[cameni]

Could the filtered positional values not be clamped at 100 in opentrack? I switched to raw values because only those are unclamped with aruco, but now it's shaky in FT.

[foobie42]

You can press the 'center' key defined in shortcuts window. That's how regular users do it.

In any case just make sure you configure the filter using the preset tab, valies rot:2 and trans:1 are fine for marker tracking.

Or you can rip out the Accela filter's guts, or make an direct elliptical filter or something. I wrote Accela so copyright isn't a problem.

The request is pretty singular, it'd be better to help you implement filtering in your own software, together with Aruco instead of making far-ranging changes in opentrack.

[cameni]

Okay, I didn't know about the centering so I've implemented it in OT. Rift is centered there on a key, so it only made sense to sync the resets in the Rift+opentrack mode.

But basically I just wanted to test opentrack and Aruco without too much extra work first, to see how it works. For now, I find it quite sensitive to the lighting conditions and noise, and given that with Rift I only need the positional info, it's an overkill. Adding 2 LEDs to the Rift and using it with the point extractor would be more robust, but it's unlikely to find a widespread use given that consumer Rift will likely come with a built-in magnetic position tracking. So I guess it will remain only for my tinkering, when I get some time for it again.

[Jagerbomber]

Cameni, how well do you think overall tracking (especially positional) could work with a Rift and a single Playstation Move controller? (or maybe multiple idk) and a webcam (maybe the PS Eye or the new one coming with the PS4... or... something else.)