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.

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