sthalik

This could either be a filesystem permission issue, or a memory mapping permission issue where pose data is stored. Check this between-release build, if it works, it's a memory mapping permission issue. If not, using the installer will most likely help. Build: https://db.tt/Nc8dM9Ou sh

It does, now, in the latest unstable release. Despite the name the unstable branch is pretty stable by now.

So who's the one to be sober during the weekend, in order to write sensor fusion and serial reset? Why is it always gonna be me? Damn short straw again.

The workaround's in edtracker actual. The joystick tracker was broken, now it's less broken.

For edtracker, DISABLE the opentrack workaround. The lockup information's very important. Thanks for mentioning that. Is Sebastian here? Maybe we should be posting on IHT FTNOIR sourceforge forum about the lockup thing. The issue's that we can't get the microcontroller available remotely when we're both available. Maybe will make a binary to flash without the Atmel available in real time.

Arduino serial API as per http://arduino.cc/en/Serial/Write lets user know when serial's in bad shape and needs reset. The new build's of opentrack, simulating a joystick works properly now. It didn't even work as it should with several joysticks, not to mention edtracker which had issues. That is, edtracker didn't need fixing for proper operation, it's on my side. Does it perform incorrectly when put on the side, upside down, or moved fast?

"How much to correct" is known as sensor fusion, part of control theory. If talk about drift, there are separate issues here. One is the algorithm itself which uses mag data only for yaw. Second is how spring effect works wonders. Mag, Gyro, Acc are already three data sources. Spring effect does the rest for prolonged game sessions. There's absolutely no need for other data sources than mag/gyro/acc. tl;dr please merely list problems for now

Hey guys, As for the inertial Arduino trackers, please provide the following information: - singularities, i.e. whether there's a glitch if put upside down, on the side, moved violently, or any other pattern - whether it stops working suddenly, requiring reset The reason is the firmware code that computes the data. We're discussing Arduino/hatire development on the usual place, as well as through email. We can act on the info and research the issues further, so state other problems as well. ----- Magnetometer can fix drift but can cause it also. Headphones' electromagnetic emissions are enough to confuse a magnetometer. As for calibration, changing headphones or putting the magnetometer on the other side of the head needs recalibration. ----- Some guy's already working on an android app. No idea about iphone. ----- EDTracker doesn't glitch anymore in today's build. ----- For drift, use mm0zct's code from opentrack Rift tracker, it's already appreciated by Rift users with gyro problems. ----- -sh

See the github wiki for accela filter configuration details.

When running under wine under FreeBSD, the following messages appear in the .rpt file, along with a messagebox relating to the former file: Warning Message: Addon 'A3_Functions_F' requires addon 'A3_BaseConfig_F' Warning Message: Addon 'A3_UI_F' requires addon 'A3_UIFonts_F' The error doesn't seem to be present on Windows-native or Windows-under-VM machines. Additionally, following errors appear: Warning Message: Custom font puristamedium is not present, it was replaced by Arma3 default font. Warning Message: No entry 'config.bin/CfgFontFamilies.PuristaMedium'. Warning Message: No entry '.fonts'. Warning Message: Size: '/' not an array Exe timestamp: 2013/08/29 19:08:20 Current time: 2013/08/29 20:37:06 Type: Public Beta Branch: Development Version: 0.77.109586 However, despite all that, the game starts using default multiplayer missions. Could you please explain which file isn't parsed correctly, or not opened at all? I can run an API tracer where the binary changes .dll boundaries to Wine-implemented ones, as well as a syscall tracer. However, the produced files are humongous. I understand that running different implementations of Win32 API isn't supported, but surely it'd help not just me but also other Linux/FreeBSD server users. Moreover, Wine can be improved by more closely adhering to the elephantine Windows API/ABI. Edit: What's saddening is that this message *also* appears on the stable branch.

It's possible to track a fiducial_marker instead of using a face tracker. This has the dubious advantage over a LED clip of being extremely easy to assemble with household materials [1], also has different lighting conditions where it excels. Your mileage may vary. PS3 Eye is an excellent sensor, recommend getting it from Amazon if only you can. Face tracking doesn't work well with human muscle authority, different expressions [0], had weird effect for me due to the tendency to 'self-censor' mimicry to attune toward its deficiencies. It's also stateful, and as such, may deform, degrade, and so on. Either a LED clip or a fiducial marker require tad less filtering as well resulting in faster response. There's no non-zero barrier to entry anymore, though. [0] Typical face trackers work by projecting a CAD-generic model of a human face on a scene and going from there. It accounts very little for movement. Had one case of a user with Tourette ticks who simply couldn't use it due to interference. [1] That is, with a printer, duct tape and a piece of cardboard.

Hey, I'm an (un)lucky owner of a force-sensing stick. It doesn't move. At all. There's no gimbal. Can a helicopter be controlled with a stick like this? Are any of you using a stick like this (cougar, x65f, etc.)? I bought the sim a long time ago, and would like to get back to it...

Rift support already works in the opentrack fork, but there are some problems with yaw drift which mm0zct hasn't yet fixed due to lack of time :( If you fix your math to the level it passes review, I'd be glad to get it into opentrack :)

@doveman, If unit is 2 times bigger, translation result will be 2 times bigger, but scales linearly no matter the position. @VeryWoolly, 1) Rotation uses trigonometric relationships, not linear as your (Visual Basic?) code. 2) Roll won't work unless you get a third point. 3) Do you account for perspective in the angles? The whole 'math' of it is rather shoddy...

@VeryWooly I'm sorry to say you're doing it wrong :( Correlating image and world coordinates isn't an easy thing to do, especially not a linear mapping like the code. Take a look at OpenCV function solvePnP. It requires a calibration matrix, like most functions of that module. Do not approach the subject without a solid understanding of linear algebra and trigonometry. You just won't achieve any results. To calculate a 6DOF model you need minimum 3 points. Even then it's 2 solutions. If you could find the precise points of some face landmarks, like both eyes and the nose, it becomes trivial to use the P3P (or POSIT) to estimate a rigid transform... Here's one implementation of P3P: http://robotics.ethz.ch/~scaramuzza/Davide_Scaramuzza_files/publications/pdf/CVPR11_kneip.pdf @doveman The unit used doesn't matter, but will affect translation proportionally. Note that "2.42 centimeters" is a perfectly fine unit! I'd be most concerned about points not lying in a single line (infinite solutions for one axis), going out of frame, and blending together. Other than that, Patrick's code is numerically robust with regard to coordinates.

Actually I don't recommend anyone else to get involved with the project. If you join and want to fix what's broken - there are tons of broken things - prepare to work in an implicit hierarchy, "because I say so and I'm the project lead" excuses, practically treated as unpaid labor. Wish I never committed any code to the repo, if someone's unable to see code on its own merit instead of who wrote it or even acknowledge it's broken - why do it? I've tried to fix the stability of the software by fixing all the rookie mistakes committed to date, but Wim Vriend doesn't acknowledge the dodgy state of the code's correctness, doesn't allow his poor judgement to be overruled in any case, commits sloppy code and pretends bugs don't exist. On one occasion my post was deleted because I pointed out a case of broken code being committed in the public forum. So don't make the mistake I did, if you think we're equals, we're not. You won't be treated as one. -sh

That makes little sense. No way to describe a rigid transform using just 2 degrees of freedom. Take a look at Point Cloud Library, it may be what you want. Edit: also take a look at convolution, cross-correlation, template matching if you want to do anything useful with the depth info.

The first point in the settings menu, in the point model, is the rotation axis. Other 2 points are practically offsets of it in world coordinates. You can check the .ini file for the first or zeroth point to find out which one is it. If it's the wrong one, you can use custom model to reorder them. Either of the points is hardly centroids, though - to get no or almost no translation response, one would have to define a centroid (again, in world coordinates) inside their skull :) This is the true center of movement, either angular or positional.

The first point you have on your model is the pivot in the POSIT algorithm. It's not possible to assign a non-light-point pivot. Another option would be to use the P3P algorithm in order to obtain a non-light-point pivot. But! that requires a calibrated camera (intrinsic matrix), unlike 3-point POSIT which works with just a 'focal length' reference value, typically 500-1000. In other words, the upper/middle point is the axis of rotation, not the centroid of your head. Edit: It's possible, but messy/unpractical (?) to do POSIT, reproject the pivot point in world coordinates to 2D, then run POSIT on it instead of the original centroid, with updated coordinates. Just note that it'll cause errors to accumulate. As for roll, I've explained to you previously through email how quaternion zeroing code Patrick wrote works. Note also that when yawing, you still maintain roll authority. So there'll always be a 'way' to yaw around while causing roll to still happen, just how, depends on the rotation axis.

There's no single 'right' profile for PT available. It will always vary on your point model's dimensions, min/max blob size, threshold. Without understanding what each of these does, it won't work properly.

FaceAPI works fine with any framerate... It's just resolution that might be limited to 640x480. It doesn't work for people wearing glasses. For them, I've made the HT tracker, it works with limited success, without glasses as well...

For users of Radeon 6XXX, any luck with Mesa branch sb-r600g-2 by vadimg? There have been many reports of success so far. Not with ArmA though. If not for the GPU driver issues I'd be using Linux as my only operating system :(

Are there any Oculus Rift users here? http://ananke.laggy.pk/ftnoir/ <- latest build works with Rift

Why use LLVM backend at all? Had problems with it all over... Why not use fglrx in the first place? Mesa has long way to go.

Been making binary builds at http://ananke.laggygamerz.com/ftnoir/ ; they are lexicographically sorted and as such, newer builds are near the bottom. If you want to use FaceAPI, just use the stable version, it isn't actively developed. Use PT or HT instead. And yes, for HT you should input the horizontal (not diagonal, what is this Logitech? go die in a fire...) FOV, else it'll have problems with everything. Use the latest build, using old builds is a waste of developers' time. There's a known bug, after saving and loading a new profile you should restart the program or else it could not load/save the new profile properly. IMPORTANT: Please check that the aforementioned bug no longer exists in 20130411_4 And yes, if 'testing' means to you 'assume it works properly and put no effort into it' like some people practice, don't bother. I've had some people who tread pre-alpha builds as some shiny toys, when they break, whine audibly and lose interest. It's nothing personal against you, adzc. The source code resides now in the main FTNOIR repository in the posix branch, awaiting further testing. It's presumed to be merged some time sooner or later before 1.8.