[ANN] opentrack 2.0 beta 1 released!
-
I’m still not sure what the various parameters actually do, aside from Order #2 and Order #3, which seem to be inverse weighting coefficients applied to the prior two estimates before being summed with the current estimate and then normalized (by dividing the sum by 1 + 1/#2 + 1/#3 I assume) to smooth the result. I’ve played around with the other factors but I still don’t have a good feel for exactly what they do.
It seems that flattening out the response curves for the first 5-10 degrees gives me a bit of a stable point looking through the HUD. How do the 3D Cockpit Movement modes (panning, relative and absolute snap, and glances) effect the performance of the tracker. Does “Dynamic Head Sensitivity” do anything?
I’ve been very happy with your facetracker which seems to run at about 24Hz with an error value around 6 while tracking 273 points (plus I wear glasses). I’ll give the Aruco tracker a try next.
Does anybody else who is using opentrack have suggestions and/or experience with using it in combination with BMS 4.32?
Center key in the shortcuts menu can be used, since no one sits looking straight into the camera.
There are some threads on the facetracknoir forum describing the filter options:
https://sourceforge.net/p/facetracknoir/discussion/1150909/thread/ee378938/
It’s entirely possible to get a stable view using the accela mk4 filter. Yes, there’s few pieces of documentation, and hard to find. But no one volunteered so far to write it. It already took half a year to write the readme file! You know how programmers are… Maybe. Some at least.
Recommend using Aruco tracker instead of face tracking, though. There’s an AR marker generator in clientfiles/aruco. Print it and base it on a flat surface and voila!
Enable 3d cockpit TrackIR, vector Z/FOV according to preference, and use “FreeTrack 2.0” protocol in opentrack. Center/toggle keys get sent to both software at once, actually. As long as it isn’t bound to anything sensitive in BMS (eject, pickle), it should be fine. Bound centering to alt+home personally.
-
“Rotation” and “translation” smoothing values slow down movement, bigger they are.
Alternatively, you can read the braindead-simple filter code at github: https://github.com/opentrack/opentrack/blob/master/ftnoir_filter_accela/ftnoir_filter_accela.cpp#L130
Recommend setting deadband up to 0.75 perhaps, it removes the noise even before it enters the filter proper.
As for third-order filtering, don’t set these two values too low, as they increase the need for filtering. On the other hand, with higher-order values below 5, response gets fast enough to be usable.
Finally: Filter removes jumpiness from frame-to-frame but it won’t help against tracker reporting wrong position. The HT face tracker is stateful, sadly. When the CAD mesh detects a standing clock instead of a face, it doesn’t repair itself the next frame.
Recommend aruco, yeah. It’s almost entirely stateless, i.e. for lower CPU usage, tries to detect each frame the marker close to the previous frame’s detection, still retries on the full image if it isn’t found.
Arriving at proper filter values is a matter of nonlinear optimization. Though software allows for changing them at runtime without restarting the capture.
-
Tried to use Aruco but wasn’t able to print a marker using aruco_create_marker. On Win7 Pro x64 it just flashes and disappears. On Win2K Pro x86 (32 bit) it says “not valid windows program”. Printed the marker used in this post (http://outerra.blogspot.com/) which seems to work. Now trying to understand the units and reference point for measuring the offset of the marker from the center of my head. I’m guessing the distances are in mm, measured from the center of the marker to intersection of the yaw and pitch axis of my head.
I read the filter code (I was a programmer in a prior life) but what are the dimensions of the deadband relative to the full range of the frame delta? Is it normalized to some value in radians?
-
Distance isn’t in mm. It’s necessary to try by dumb luck. This is because to have proper units, both marker size must’ve been known by the software and camera FOV must’ve been known.
But keep in mind that there’s no need for fancy measurements, as the capture needs not be restarted after changing head centroid position. There’s a pink dot pointing to the centroid, which simplifies things a lot.
The marker-jpeg-creator needs to be called with 2 arguments IIRC, for example from Windows console, uh, window.
As for deadband, it’s degrees and tracker’s internal value for translation, which doesn’t correspond to any SI units.
-
Looks like my units worked out to be roughly cm, but tracking the pink dot is easier as you said, at least for x and y. For me a zero z puts the dot on the tip of my nose while positive values put it in front of my face while negative values put it inside my head.
Using the Aruco with the printed marked taped to a sheet of cardboard mounted above the brim of an old hard hat I have. Works well but there appears to be a correct orientation of each marker, as depending on how I orient it, I have to reverse either the pitch or both the pitch and yaw axis to get left to be left and up to be up. Nice way to get dizzy if one or both axis are reversed!
I’ll play with the marker-jpeg-creator arguments. I assume if one is ‘window’, the other is the desired marker number, which the program seems to be able to decode without help, modulo the axis flips, from the embedded hamming code.
Thanks for all the help.
-
For Aruco, here’s my centering procedure:
type in x:0, y:-30, z:-30
Should point just above the nose tip, else adjust Y.
Yaw left/right, holding the mouse cursor on top of the centroid circle.
If it’s following you to the side you yaw, increase z. If it goes to the other side, decrease Z.When it moves no more than a few X’s with your mapping, it’s done!
-
I’d like to announce opentrack-2.0rc1 availability at <http://ts3.cosaofficial.pl/opentrack/>
About the only change from beta3 is fixing FSX/SimConnect support, broken since several betas ago.
I’d like to thank Paweł Legawiec from the COSA ArmA squad for confirming that it works.
-
With thanks to jmmilner72, the software now has at least a stub worth of a wiki.
https://github.com/opentrack/opentrack/wiki/_pages
As writing requires a moderate grasp of English (as evidenced by yours truly’s fumbling) and no programming skill, I’d like to ask you to contribute. Thanks!
-
Everything works here, except when the profile has enabled axis inversion TX (x-invert-axis=true) or disable Z axis compensation (compensate-translation-disable-z-axis=true), next time I run the program CPU usage goes to 100% and tracking becomes slow and glitchy. If they’re turned off in profile and I enable them in the GUI they work fine.
-
Can’t reproduce it here. Does it happen on today’s build? Please give exact steps to reproduce the breakage.
-
Happens on today’s build too.
http://www.filedropper.com/settings_2 I here’s two config files (I hope this forum lets me post links).
When you select falcon_good.ini to load next time you start the program, all is good. when you select falcon_bad.ini, 100% CPU next time you start (but works fine if you load it manually when the program is already running).(using Windows 7 64bit in case it makes a difference)
-
For me, it was enough to open a profile stored in a different directory, but without restarting the software. It seemed to reload the combobox over and over again.
Thanks for the report. Please retest, using the same URL for the build. It’s been ninja edited, due to gravity of the issue.
Edit:
NOT YET FIXED. “save as” causes same issue. Next build should fix it. Try again in 10 minutes.
Edit:
Uploaded by now.
-
Works perfectly now. Thanks.
-
Thanks for the Wiki. It has already cleared up my biggest problem with the Aruco tracker. I somehow convinced myself that the marker should be perfectly vertical when my head was in the neutral position (because the camera could see the largest size image). I saw all sorts of odd axis flipping, so much so that I was looking through my junk drawer for IR LEDs yesterday.
I’d be happy to help edit the Wiki as I have some past experience with technical writing as well as programming.
With thanks to jmmilner72, the software now has at least a stub worth of a wiki.
https://github.com/opentrack/opentrack/wiki/_pages
As writing requires a moderate grasp of English (as evidenced by yours truly’s fumbling) and no programming skill, I’d like to ask you to contribute. Thanks!
-
That’s great news! When you register on github, send your username and you’ll be given access in a jiffy.
I’ve tried to copy coplanar POSIT from the PT tracker to use in aruco, but it wouldn’t work any better, sadly.
Watch out for pitch down being broken when the marker’s centered yaw-wise and you’re looking at the middle translation-wise. It used to work for me for months but now spotted some edge cases after switching to Windows… Hopefuly it’ll all get sorted out in the upcoming days.
-
I think I’ve also seen some glitches in pitch tracking, even with the marker at 45 degrees when in neutral pose, running Windows 7 Pro x64. Also did some digging and can confirm that the markers do have a “up” and “down” so that if you rotate the marker 90 degrees before fixing it to your hat, the pitch and yaw axises as tracked get swapped. The source I found for the marker creation program seems to require 3 arguments; marker number (range 0:1023), jpeg output file name (e.g. “test23.jpg”), marker size (256 seems standard). Still can’t get it to run in Windows 2000 or 7 (64 bit), will try XP next.
I think even the PT will break down if the plane defined by the three points comes too close to being coplanar. At least with the markers it is obvious what that plane is!
I PMed you my github id.
-
Try using .bmp as the extensions instead of .jpg. JPEG support hasn’t been compiled in that particular opencv build. It should work on Windows XP/2003 and above with the file format caveat.
PT’s coplanar too, since it uses 3 points. That amount forms a plane, always. The real issue is perpendicularity toward the camera.
In a yet-unpushed build, settled for iteratively improving the previous frame’s pose, until the pitch sign changes. This has its own caveats, but completed a test flight without a hitch.
Changing the head centroid works too, and yet-unpushed change allows for skewing the 3D coordinates of the marker’s edges on the pitch axis, to account for the marker’s skew. This improves on head centroid position.
Finally, distortion coefficients are necessary to prevent rot/t interconnect. This is an issue given that barely any users care to calibrate the webcam model they’re using.
-
In case there are any outstanding issues with regard to the software, please report them. They’ll be corrected by me when it’s possible.
It’s been a while, after all. Happy head-wiggling!
-sh
-
Still using it and happy with everything.
Question though, any plans to add DX centering/pause commands to it?
-
In case there are any outstanding issues with regard to the software, please report them. They’ll be corrected by me when it’s possible.
It’s been a while, after all. Happy head-wiggling!
-sh
Please take a look at this issue:
https://github.com/opentrack/opentrack/issues/25