Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Video developer info #251

Open
wants to merge 19 commits into
base: master
Choose a base branch
from
Open

Video developer info #251

wants to merge 19 commits into from

Conversation

russell-taylor
Copy link
Contributor

This allows a config file to specify many more parameters to the algorithm. The most significant for developers will be the ability to specify the patterns and positions of beacons for one or more sensors. Modified the default config file to do this for the OSVR HDK. Made a second config file that has all of the beacons (front and back) on one rigid sensor. Wrote the developer documentation for how to add new sensors.

…k for matches into a double-length repeated string that gets searched to reduce the processor load when looking for flashing pattern matches.
…t speed for accuracy) and maximum reprojection error (adjust report frequency vs. error).
…mbined sensor, assuming a radius for the head that the HDK is on and that the rear sensor ends up right behind the front one.
…ation file. Made a config file for the OSVR HDK with two sensors, and another one for the HDK with all of the beacons acting as a single sensor (with an assumed location on the back of an assumed-sized head). This enable tracking of both the front and the back of the head, but has large angles in between where there is no tracking and will get things wrong for other head sizes and mountings.
@rpavlik
Copy link
Member

rpavlik commented Oct 29, 2015

The device descriptor (specifically, the semantic section) should be dynamically created based on the config passed, if nothing else to allow the user to name their tracked targets and allow the plugin to normalize the coordinate system.

Also, these docs, as well as the other ones recently added, should be linked in from the Doxygen documentation. See the doc directory for examples of how to do this. May have to add the directory to the doxyfile (the common one) for some markdown and image search path.

@@ -202,11 +206,10 @@ namespace vbtracker {
// do okay without using it, so leaving it out.
// @todo Make number of iterations into a parameter.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this can be removed now, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

…have sensor descriptions in the file. Uses the names of the sensors as the semantic names and hooks each to a tracker sensor.

Modify the sample config file to hook /me/head to the correct name.
… sensor name is the semantic name of the device in the video-based tracker.
@russell-taylor
Copy link
Contributor Author

Okay, I think I've either rebutted or fixed everything except for moving the documentation to the right place, which I couldn't figure out how to do. There are some more commits to look over. Repeat a comment if you'd like to override my rebuttal and I'll do what's requested.

@russell-taylor
Copy link
Contributor Author

What's the status of this pull request? Lots of good stuff in here going unused...

@rpavlik
Copy link
Member

rpavlik commented Apr 21, 2016

Well, most of it no longer applies or has been manually merged or cherry
picked, I think basically all except the stuff where the whole beacon data
is in the config file. The plan is to eventually move away from that
particular plugin to the unified one (which shares some innards but is
structured differently primarily to handle IMU in the same filter as the
video data, and multiple targets per tracked body to get better performance
out of the rear target) if/once I get it to stop being so twitchy. (I do,
and should probably more frequently, by having a local checkout, refer to
it when working on unified)

The actual developer info itself should probably end up in OSVR docs.

On Thu, Apr 21, 2016, 7:33 AM Russell Taylor [email protected]
wrote:

What's the status of this pull request? Lots of good stuff in here going
unused...


You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#251 (comment)

Ryan A. Pavlik, Ph.D.
Senior Software Engineer
Sensics, Inc.
www.sensics.com

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants