Print

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

[cameni]

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

Next build, which is due .. soon, after we hide some naked protruding wires of other unfinished stuff

[foobie42]

Any entries in the event log, as in, access violations?

There doesn't seem to be anything fishy in Rift tracker that might cause a crash.

mm0zct, who wrote the Rift tracker, has been using it and sharing the software among Rift users... Never heard of any reports.

Only thing that comes to mind is sharing PDB's in install directory...

Oh, if you could editbin (included with MSVC compilers) /SUBSYSTEM:CONSOLE, you'd get debugging standard output and error, there might be some messages from SDK itself, which *could* in theory be causing an error exit...

This is embarassing, because one of the biggest reasons for the fork was removing sloppy code, fixing bugs, and making the software more maintainable...

Edit: Paging mm0zct.

> Could it be done so that they would be always present, even if there's not enough points to infer the pose data?

I'm sorry but that'd require some architectural changes. In particular, the tracker -> protocol, protocol is agnostic of whether it's an optical tracker, a face tracker, or INS.

Edit 2: The aforementioned fields are kept for compatibility purposes only. As for PT's mode of operation, it short-circuits the tracking function if not enough points are found.

If you're willing to donate a positional 2-point algorithm, I can add branching to PT, allowing for selection of a smaller amount of points. But there's a bit of debugging, testing and hacking involved, and it's perfectly understandable if you wouldn't want to get involved.

Edit 3: If you're using Norton or Avira crapola it might cause the issue. Just saying.

[cameni]

Console doesn't tell anything when the crash happens. Hooked the debugger and got this trace:

Code: [Select]

ntdll.dll!_RtlReportCriticalFailure@8()
  ntdll.dll!_RtlpReportHeapFailure@4()
  ntdll.dll!_RtlpLogHeapFailure@24()
  ntdll.dll!_RtlFreeHeap@12()
  kernel32.dll!_HeapFree@12()
  msvcr100.dll!free(void * pBlock=0x0864a490)  Line 51 C
  opentrack-tracker-pt.dll!522316c3()
  [Frames below may be incorrect and/or missing, no symbols loaded for opentrack-tracker-pt.dll]
  opentrack-tracker-pt.dll!5238ea6d()
  msvcr100.dll!malloc(unsigned int size=138867956)  Line 89 C
  QtGui4.dll!5473db8a()
  QtGui4.dll!547c3b94()
  QtGui4.dll!547c44d7()
  QtGui4.dll!547c44df()
  QtGui4.dll!547c9a8f()
  QtGui4.dll!5476a995()
  QtGui4.dll!54bd8d4b()
  ntdll.dll!_ZwFreeVirtualMemory@16()
  ntdll.dll!_RtlpSecMemFreeVirtualMemory@16()
  ntdll.dll!@RtlpFreeHeap@16()


There doesn't seem to be anything fishy in Rift tracker that might cause a crash.

Not Rift tracker, that one is integrated in OT, but the point tracker.

If you're willing to donate a positional 2-point algorithm, I can add branching to PT, allowing for selection of a smaller amount of points. But there's a bit of debugging, testing and hacking involved, and it's perfectly understandable if you wouldn't want to get involved.

Surely I would, this should be universal, for use in other projects as well.
For our purpose, with the Rift tracking already integrated, we would need just a shortcut from the point tracker after it extracts the raw points, with no additional computation. Together with the data from Rift we can then extract the positional info. Once this runs, it can be pushed back into the Rift tracker in opentrack, so that it provides the full pose data. In theory I could do it directly on the Rift tracker code in opentrack, but it would take much more time that way I think.

So I'm thinking - a special version/branch of the point tracker that puts the raw positions into the main fields (X/Y/Z/angles) for the time being, I'd develop the code for getting the position out of it, and then donate it back to opentrack to support that mode out of the box (or that combined mode too, for games that already integrate Rift and want just the extra option for position). Plus a tutorial for the hardware mod required, of course, when it all works as planned.

[foobie42]

For 2 points to be supported in any case dynamic pose resolution has to be conditionalized. That is, the 'velocity' part, as position alone doesn't describe a rigid body anymore...

Would you rather want a ripped-out version of PT, running as executable? Stuff that doesn't fit a 2-point model can be ripped out and later merged and branching added.

opentrack uses CMake as its build system, which can be configured to produce .sln files, as well as projects for various IDEs. In worst case, Makefiles can be created. Learning curve's pretty small anyway.

In any case you can just run the blob extractor and nothing else for the moment. If you'd rather go with stickers instead of thresholding, HSV detection could be used.

Because so far there's only been one point model configuration, the code isn't generic enough to just fill in a few virtuals. Some refactoring is needed.

So where do we go from here? If you insist on getting position info from the blob extractor through a shared memory mapping it's doable, though bit awkward. With 'compat' library can create a different mapping altogether just for blobs. Alternatively you could build PT on either Windows or Linux, which is pretty seamless provided you have the dependencies.

The crash bug turned out to be stale object files on the build box, or some linker snafu. Rebuilding everything with no code changes helped. Today's build won't have this issue. Also including PDBs. Shoulda done it a long time ago.

TL;DR version - don't you want just the blobs in another mapping to hack on it?

[foobie42]

https://github.com/opentrack/opentrack/commit/2634e7faa57c53434a8677c88e0e6dbd8134d4e0

Good enough? Do you want premade DLL and/or instructions on how to build the damn thing?

Note that presently the point list is unsorted. Will you be able to deal with it? This is because find_correspondences() side-effects the tracker object, as well as making assumptions about point count. What next?

[cameni]

Thanks. I guess a premade dll would save me some time initially, but I can also build it myself - might be more useful in the long term.
Unsorted is fine.

[zaelu]

Next build, which is due .. soon, after we hide some naked protruding wires of other unfinished stuff

Thanks, looking forward to it!

[foobie42]

Thanks. I guess a premade dll would save me some time initially, but I can also build it myself - might be more useful in the long term.
Unsorted is fine.

http://www.mediafire.com/download/548mfp45l8xfzmb/opentrack-tracker-pt.dll

Can use this with 20130716 or later builds. While -16 PT crashes, this one is ABI-compatible and works. It's based on the github branch, and as such, passes extracted points without computing or exposing headpose data.

If you plan on building yourself, which is recommended, make sure you use cmake-gui on Windows or Linux, and not cmake, as there are quite a few options to fill out for the build! In any case if you run into problems, send a message anywhere instead of blindly drudging along with unfamiliar codebase/build system.

Sorry about mediafire host but ananke.laggy.pk is in the process of being transferred to a different box.

[foobie42]

Sup cameni

How do you feel about using an aruco-readable marker for 6DOF tracking? All it requires is a printer. User already suggested it as an alternative to face tracking and it does indeed sound interesting. Can be splatted to the back of the VR headset of course.

[cameni]

I still have problems with that crashing. I have the build 20130716.

How do you feel about using an aruco-readable marker for 6DOF tracking? All it requires is a printer. User already suggested it as an alternative to face tracking and it does indeed sound interesting. Can be splatted to the back of the VR headset of course.

That's what I meant by the markers to stick on the Rift, instead of using IR cam and LEDs. No exps what's the performance though.

[foobie42]

Should do 120 Hz in 640x480, if that was even possible by today's consumer-quality webcams, actually 6ms per frame on my i7. It's completely stateless, too.

http://ananke.laggy.pk/opentrack/opentrack-20130727_1.7z - build with PT changes by Patrick and aruco!

Note that this build contains unmodified PT which doesn't export raw point data... But please do tell if it crashes for you! Because if it does, there's something seriously amiss here. Just gave you the 'install' directory that I'm running from myself!

Excuse the messy appearance, it's hot here and I haven't slept at night as usual

I believe that due to how reliable it is, there's no need to develop/port-from-Delphi the 2-point algorithm at all... Don't you agree?

Both aruco and opencv are liberally licensed. Are you mad enough to link them into Outerra's address space?

IMPORTANT: Singularity on the Y axis is solved by extrinsic guess from previous pose.

[cameni]

LOL, nice video
This version seems to be stable, no crashes so far.

The problem with augmenting the Rift with extra positional sensing is twofold

• with Rift the angles are 1:1, no magnification, you can turn aside when the front face is not visible at all (in MiG looking back)
  this should be complemented with a 1:1 positional tracking too
• extra latency

I think ideally we would use the accelerometer in Rift to integrate the position, correcting it with the positional information from opentrack, obtained from one of the trackers. So I was just thinking how to get that positional info, the two-point (or more) algorithm should be easy to implement when it has auxiliary orientation info from the Rift, and also more robust as currently the detection is pretty unstable on my setup. With the raw values I should be able to get the position more reliably, and just 2 points are enough.

The simplest way would be to have the accelerometer integrating only when there's a good position info from the tracker, but just combining the positional info from the tracker would be enough for a start.

I'm going to test it with aruco, that would be a pretty simple way. However, since the orientation isn't needed, I guess something simpler could be done with opencv alone ... like again, getting raw values of some markers. But I need to check what opencv provides.

[foobie42]

You can write a rather simple complementary filter to avoid jumpiness when updating positions. Unless you want to go full EKF which is... unadvisable for sanity's sake.

Obtaining position only seems like a special case since it doesn't fully describe a rigid body in some space...

I'm having a rather big problem with the LevMarq solver for the PNP problem, on some marker-on-head alignments it treats both pitch signs as one... There are many more people with the same issue. Only other option is to use EPNP solver which has abysmal accuracy. Other than that, I've tried initializing LevMarq with EPNP extrinsic guess, but it 'optimized' it away...

Why all that? It delivers vastly superior performance to a face tracker, requiring little filtering, and being entirely stateless which is a great boon! Better than that, unlike an IR tracker, there's no need to distinguish individual points, since aruco markers have orientation built in...

If not for degenerate pitch case, I'd be seriously recommending this to everyone...

[zaelu]

http://www.outerra.com/forum/index.php?topic=70.msg22148#msg22148

[foobie42]

All works fine, but marker has to be tilted backwards, due to aforementioned pitch issue.