Is it possible to add support for YEI sensors?

[opentrack]

Is it possible to add support for YEI sensors?

[sthalik]

Essentially, yes.

I'm tad busy, Can you send a pull request with working code? :)

Note that testing can't be done by me, as device lackage precludes a working impl.

So either someone volunteeers, or keeps in IM contact with me as I implement the API in spare time.

But this is a great idea, always looking for more trackers!

[baggyg]

I have forked the project and currently working on the code. Its going okay, however may need a little help as C is not my strong suit. I have a YEI device here so can assist with testing. Perhaps if I could get it 90% of the way there then you could with the final push. I will update my fork once I feel it is in a good state to look at.

[sthalik]

👍

[sthalik]

any luck?

[baggyg]

Sorry had no time at all to look at this over the past few weeks. Its definitely at the top of my priority list once I get some free time. I would estimate I am half way there with it so hopefully not too much to do.

[FuraX49]

Try new HATIRE tracker. But you must modify YEI firmware for send compatible frame.

[sthalik]

If you intend to commit a new tracker in-tree, please maintain it. Anyway, any luck with the effort?

[baggyg]

Hi, I presume you mean the fork I created way back. That is now gone. I have the main project and have created a branch just for the YEI stuff. I will publish as soon as possible but still think I'll need you help on a couple of aspects. I was travelling for all of Xmas so just getting back. However hoping for some news to say on this very soon.

[baggyg]

Ahhh that didn't work at all since I cant create a branch on the main project. I re-forked and added the work to a new branch on mine. Could you please have a look?
https://github.com/baggyg/opentrack/tree/YEI-Changes

Having trouble compiling it but that is more because of my inexperience with C. However I hope this is pretty close to working.

I have dumped the YEI header file and the DLL in the new directory (for now)
I know the C make file will need updating to reference the DLL (not done - although added tracker link).

API reference is here: http://forum.yeitechnology.com/viewtopic.php?f=12&t=27

Once I can test this and know it is up and running I can add more things such as asynchronous (streaming) data from the sensor.

Let me know if this is any good. If you have a good easy guide to compiling on Windows that would be appreciated rather than asking you to compile all the time.

[sthalik]

Please rebase before sending a pull request without the header file, and a blob library.

There's no guide for compiling on Windows or any other platform. cmake invocation is actually easy, provided one has a working compiler. For Windows this is GNU or LLVM/clang. MSVC most likely won't work given that they support only a small subset of C++11 functionality. Recommend here drangon's binary builds https://code.google.com/p/mingw-w64-dgn/ instead of trying to fix MSVC.

Async isn't necessary. The tracker can run in its own thread. Depends on the API, which mode of operation results in more clarity.

I know that you spent a fair deal working on the code, AND should've asked these questions at the very start. Nevertheless, here they are - How many users are there? Will you maintain the code once it gets in-tree? This is following the recent experience of 'code dump' of the Arduino tracker. Turns out it was only compile-tested, turned out to be invariably crashing after few frames due to a copy-paste bug, and no users to give it playtesting... However if you can maintain it, ensure that it works following API changes, it can go in-tree even if there are very few users. You can also choose to maintain it outta-tree of course.

[sthalik]

We definitely should use a working arduino tracker...

[baggyg]

Thanks for the reply and advice with the compiler.

Regarding Async I was actually talking about the sensor mode rather than the software itself. YEI runs a streaming mode which is better for retrieving data since it does not wait for the result.

I completely understand not wanting to adopt code that is buggy and / or not maintained. As a bit of background I am just an enthusiast who wants to see opentrack support the YEI as I would like to use it for myself. I don't work for them and am not affiliated in any way. Therefore I don't have an accurate count of users. However the YEI tends to be a popular choice with DIY Rifts and other similar systems that require third party headtracking. Currently only FreePIE supports YEI (as well as their own software suite - but this is limited). They are also bringing out the PrioVR suit (fully body motion capture) this year although I am not sure how similar the API is going to be.

I am happy to work on getting a working bug free version and continuing to maintain it, but there are a couple of considerations:
a) I work full time as a programmer and only have a limited amount of free time that I can devote to other projects. I am happy to give my time to Open Source projects, etc but this will always come second to paying work.
b) I own the USB sensor, but not the wireless or bluetooth versions. The bluetooth / wireless ones connect in a slightly different way. I can therefore debug with the equipment I have available but can't offer support to the other versions.

Reading between the lines I think the best course of action would be for me to continue and get the compile working that I can have something for my it own personal use on a branch (out of tree). Once I am happy it is 100% working and has the features you can decide whether you want to include this in-tree and whether there is a community who can adequately test it.

[sthalik]

Use the "opentrack_library" macro to enable the build in the first place, in addition to the "opentrack_module" macro. Perhaps these shouldn't be split in the first place.

Worst-case scenario - only you use it, but code remains maintained and updated within sane time-frame after API change. Best-case scenario, it's used by many and any committer (including yours truly, the maintainer) can fix it.

Above isn't exhaustive, but those are acceptable scenarios.

It's perfectly understandable that you can't devote too much time to an open-source project. Healthy ethic and not abandoning what you wrote goes a very long way, as-is.

Finally, some technical considerations, enough of this mismanagement drama:

Is there yaw drift? How much? Is mm0zct's spring code applicable?

For wireless sensors, follow API spec practices, but find at least someone who can confirm init works.

If you intend to hack on other pieces of the codebase, let's do so in coordination. I'm happy to grant you a commit bit once there's something to push, anyway.

My biggest conflict so far is that don't want to piss on your work by ignoring it, but it's not known so far how many users are there, and code in-tree requires maintaining. Keep in mind that binary builds for Windows and OSX include all available tracking sources, protocols, and filters.

[sthalik]

Any luck with your project?