Will positional head tracking be activated in the dev kit?

Very useful, thanks.

So with the base station of the Hydra being what's spitting out the pulses, you could conceivably setup your own sensors to read and calculate completely separately from the whole Hydra system. About this time I'm wishing I knew more electrical engineering.

"Felix12g" wrote:
Very useful, thanks.

So with the base station of the Hydra being what's spitting out the pulses, you could conceivably setup your own sensors to read and calculate completely separately from the whole Hydra system. About this time I'm wishing I knew more electrical engineering.

It seems that way. You might have timing issues with it - I don't know how critical it is for the base station and controllers to be in sync.

The SDK documentation also mentions something about having to 'activate' the controllers, but since it includes functions related to wireless controllers, it may have more to do with this than any actual need to establish communications directly between the base and the controller.

There's a few technical issues though - First being that to detect a 2 ms pulse in any meaningful way would require that the sample rate is at a bare minimum, 1000 samples a second, and you'd probably want 2500-5000 samples realistically.
On top of that, I don't know how much of the calculation is done in software; - I've heard statements which imply the rift base station contains a DSP chip to perform at least part of the required calculations.

If you're using extra custom-built sensors, the base station probably won't know about them, so you'll have to replicate whatever calculations are involved independently.

Given what the sensor consists of, constructing a custom-made replacement shouldn't be that hard. (inductor coils are easy to get hold of), but the support electronics and processing requirements may be non-trivial. (Or not. - I only have a very rough sense of how to calculate orientation and position from the raw data...).
You would need to find a pretty good DAC system... Although it's possible audio grade DAC chips might be good enough. (They have to deal with signals in the range of 48 khz after all).

Sounds like an interesting experiment, if nothing else. XD

"geekmaster" wrote:

You can read more in the PDF links I provided in previous posts in this thread (incorrectly attributed in a recent jwilkins post as from a 320x200 post). Just look at the bottom of my (really long) previous post in this thread for the link...

Wasn't me :)

"KuraIthys" wrote:

"jwilkins" wrote:

"KuraIthys" wrote:
That's all well and good ...

Of course, but ...

"KuraIthys" wrote:
I tried that out once ..

How fast was the accelerometer and what kind of integration algorithm ...

It was the accelerometer from a Wii remote. ...

"KuraIthys" wrote:
Using an accelerometer as a PRIMARY data source ...

Good thing that wasn't the idea. ...

Considering there is decades worth of research ...

"KuraIthys" wrote:
Each integration step, roughly speaking ...

No way it is exponential. ...

... Yes. I'm not the most careful with words sometimes...
HOWEVER, and this is critical: The paper linked to by 320x200 (http://www.cl.cam.ac.uk/research/dtg/www/files/publications/public/abr28/ojw28_thesis.pdf) summarises the implications ...

Ahh, I see... That nest of quotes confused me. The above summary had a number of even more deeply nested quotes removed, and all the intervening paragraphs embedded within and between made backtracking difficult, and even more difficult to backtrace was that it had a nest of quote FOLLOWING the attribution to 320x200. Yours was the first QUOTE, not the post containing the incorrect attribution. It is not only KuraIthys who made the false attribution, but who buried it inside a wicked quote nest...
:shock:

Sorry about incorrectly attributing the claimant of the first incorrect attribution. :mrgreen:

What is most surprising is that I haven't had a chance to review everything in this thread for the last day but I still caught that.

Hmm, to stay on topic. Does anybody have a recommendation for a computer vision library I should use if I want to actually attempt my own version of vision/accelerometer sensor fusion?

I've only heard of OpenCV and ARToolkit. (I'd prefer something with a BSD style license...)

"geekmaster" wrote:

"KuraIthys" wrote:

... Yes. I'm not the most careful with words sometimes...
HOWEVER, and this is critical: The paper linked to by 320x200 (http://www.cl.cam.ac.uk/research/dtg/www/files/publications/public/abr28/ojw28_thesis.pdf) summarises the implications ...

Ahh, I see... That nest of quotes confused me. The above summary had a number of even more deeply nested quotes removed, and all the intervening paragraphs embedded within and between made backtracking difficult, and even more difficult to backtrace was that it had a nest of quote FOLLOWING the attribution to 320x200. Yours was the first QUOTE, not the post containing the incorrect attribution. It is not only KuraIthys who made the false attribution, but who buried it inside a wicked quote nest...
:shock:

Sorry about incorrectly attributing the claimant of the first incorrect attribution. :mrgreen:

Uh... Sorry. XD

How did I do that exactly? I'm fairly sure I tried to find the original post within the thread that contained that link... Not to mention the person I actually attributed it to barely commented in the thread.

I honestly have no idea how I did that. Sorry.

I'll fix it if you want, although I'm not fond of revising errors in something I've already written... (Makes it feel like I'm trying to hide my mistakes. XD)

lol, you are allowed to fix errors, especially if you do not want to mislead people.

That reminds me I still need to add a note about errors being O(t^3) instead of O(t^2) (with a note that it was incorrect before of course).

OK... I changed it.

Hopefully I got it right this time. XD

"jwilkins" wrote:
... Hmm, to stay on topic. Does anybody have a recommendation for a computer vision library I should use if I want to actually attempt my own version of vision/accelerometer sensor fusion?)

This is the first thing Google found for "imu video fusion":
Fusion of IMU and Vision for Absolute Scale Estimation
http://students.asl.ethz.ch/upl_pdf/134-report.pdf

In this paper we look at two sensors on board of an autonomous helicopter. The first is an Inertial Measurement Unit (IMU), which is able to measure the 3D acceleration and rotation of a moving object and the second is a fisheye camera. With each sensor it is possible to obtain the actual position of the moving vehicle. An integration of the acceleration measurements over time from the IMU yields a position in meters whereas an applied SLAM (Simultanious Localisation and Mapping) algorithm on the vision data (video frames) provides a position with unknown scale factor λ. By using two cameras, which is not the case in this study, the scale ambiguity would be solved. Due to the lack of space, we cannot use binocular vision. By fusing these two positions, from vision and IMU, we obtain a better pose estimation of the vehicle, which is essential for stabilization and control of a micro helicopter. An accurate estimation of the scale factor λ is the main key to achieving this.
...
This paper describes 2 different approachs to estimate the absolute scale factor. The first is an online spline fitting method which proved to be not applicable for a robust online use due to the bad results of the least square optimisation. The second approach, the Kalman filter, produces good and accurate estimates within a reasonable converging time of up to 15 seconds. The online implementation works smoothly as shown in the video ??. The Kalman filter thread which has been implemented in the SLAM algorithm of Georg Klein can now be used on an autonomous helicopter equipped with only one camera and a tri-axial accelerometer to estimate the scale factor which is very important for a trajectory reference control which will be implemented in future work.

Hmm, their key finding seems to be that an accelerometer can compensate for only having a single camera because it lets you resolve ambiguity by providing a proper scale for what is seen in the video. (Sorry if I seem to be using the forum instead of Google, but honestly I did not even know to use IMU as a keyword before, since I'm relatively new to this).