cancel
Showing results for 
Search instead for 
Did you mean: 

Hydra Calibration

Blueshock
Honored Guest
Hi all,

Just interested in you guys' experience with implementing the Hydra to work alongside your Rift and how you are currently handling the calibration when you can only see the virtual world.

Currently I have an initial calibration of arms stretched straight forward and then to the sides to get the length of the player's arms and the position of the player in relation to the base station (which I then map to the avatar's dimensions). However, I haven't seen anyone do this on any videos so thought maybe I was missing a trick?

Another thought was to mount the base station to underneath the player's seat, kind of like the Holodeck guys, but without the need to wear a helmet..!

Anyway, if anyone is playing with the Rift and Hydra, would be good to talk (I'm currently using Unity).

Cheers
17 REPLIES 17

jjoudrey
Honored Guest
I know this solution won't work for everyone, but here's how I "calibrate" my hydra input.

I also have a Kinect Unit. When the app launches the calibration routine waits for the users hands to be more than 20cm apart (which they almost always are). It then calculates the midpoint between the kinect hands and the Hydra hands and uses this to determine how far away (and at what level) the hydra base station is compared to the kinect. Then it uses the vector from the right hand to the left in both the kinect and hydra to determine their relative orientations.

This allows me to place a virtual hydra base station in my game world where all the outputs of this base station line up with the real player position.

This is probably a bit much for just calibrating a hydra, but for those of us building our ultimate VR experience, it does allow for a quick & painless calibration routine.

This method will quickly highlight the difference in hydra hand position and kinect hand position as you move around. There are four things I'm considering now and I haven't made up my mind which to persue.
1. Recalibrate every frame, it's computationally cheap after all, but the animation could jump if it recalibrates too much in a single frame.
2. Keep the initial calibration perminently, it shouldn't degrade over time and the animation would be consistent but inaccurate in some positions.
3. Continue recalibrating but blend the new values in, causing a smooth "lag" to the calibration as you move but at least it'd be smooth and accurate after it settles.
4. I know this is the right option, but I don't know if I have time now. Move the kinect hand and the hydra thoughout the potential play space and sample it's error at many positions and many orientations to calculate a calibration field that might give accurate results in all cases (depending on the nature of the hydra's inaccuracy).

KuraIthys
Honored Guest
I considered doing something similar, but my tech is a bit clunkier, so I can't leave it on as a standard thing. (I would be using a Wii or PS Move + their relevant tracking tech to do it. Similar idea in principle though.)

But as to the options, 4 is correct in principle. (It's how the expensive tracking systems based on similar tech to the hydra expect users to calibrate the system.

The thing about the hydra is that although the position and orientation it reports are not always what they should be, as long as you haven't moved the base, they're always consistent.

That means, with a controller at the exact same physical location, the value you get back will also be exactly the same.
Of course, compared to the physical location and orientation, this value could be wrong, but if so it will be wrong it a very consistent manner.

So... If you build up a map of actual location & orientation compared to reported location and orientation, you simply need to keep track of the relevant offsets, and it will remain correct.

Now, ideally you'd be able to do this once, and then reload the same data each time. But I fear the calibration depends on background magnetic fields too, so you'd have to redo it every time something changed substantially.
(I notice for instance that there's a considerable angle deflection of the orientation reported by my hydra controllers if I hold them near my CRT monitors - CRT monitors use magnetic coils to deflect the electron beam across the display, so they would have a relatively strong, and continuously varying magnetic field...)

In any event, it's possible to calculate offsets, but you'd probably have to redo it every time you move the base station.

Also worth noting in terms of calibration, is that although the SDK might be hiding this fact, it's incredibly obvious that the Hydra determines position using polar coordinates, rather than cartesian ones.

The basic tech behind it lends itself to reporting distance + orientation relative to the base station, and that's clearly a polar coordinate system.

(if you look closely at the base station you can even see that there are 3 coils in it at 90 degree angles.) -

what the system measures, basically, is the orientation of the controller relative to each of the 3 coils in the base station. (they turn on and off in sequence.)

The controller also has 3 coils at 90 degree angles. The signal for each coil relates to the distance between it and the base station, and the angle. (something akin to a vector dot product calculation.) - since the distance is roughly the same for all 3 coils in the controller, the 3 values will be about equal in relation to distance, but given that only 1 coil in the base station is powered at once, you get 3 values which relate to the angle between the 3 coils in the sensor, and the currently powered coil in the base station.)

A complete measurement consists of 12 readings taken from 3 coils in the controller; Giving the relative angle between the controller and each of 3 perpendicular coils in the base station, plus a set of 3 readings with nothing in the base station active at all. (essentially giving you the background magnetic field.) -
Obviously, any given measurement relates to both the magnetic field strength of the base station's coil (and thus also the distance), and not just the angle, but still...

OK... Not sure how helpful it is for calibration purposes, but it is quite interesting to see how it works. I suspect it might be helpful for the calibration to be in polar coordinates, given how the device works, but I'm not sure how much difference it would actually make.

It's worth noting though that if it's sufficiently well-made, the response to magnetic fields for each coil in a controller should be pretty close together. - This means that if you rotate the controller itself without it moving from that spot, the magnetic field readings should remain very similar as a whole.
Or, in a more practical sense, the orientation shouldn't really drift at all if you aren't also translating the device. Thus, as long as you calibrate the position offset, and an offset for rotation relative to a reference direction, you shouldn't also have to specifically calibrate for the different orientations of the device in a single point.

For example, let's say you have the controller physically 50 cm left, 40 cm up, and 60 cm behind the base station, and for simplicity, with the buttons facing up, and the controller pointing directly away from the base station.

Now, lets say the readings you're getting suggest the controller is 40 cm left, 60 cm up, and 80 cm behind the base station, and pointing about 30 degrees 'up' from where it should be.

If you move it somewhere else, then back to this position (without having turned the system off, or having moved the base station), the readings should show exactly the same error.
So, an offset of -10 cm, -20 cm, and -20 cm, will then always give you the correct position.
However, if you compensate for the 30 degree error in angle, this should compensate for the angle no matter how you rotate the controller, as long as you aren't also moving it.

(My point being, you only need to compensate for angular errors once per position, and not for every possible angle in every possible position.)

Now, You can verify this easily enough using the Sixsense test program. Find a spot where the angular error seems particularly large, then see what happens when you rotate the controller.
Even though the error could be huge, the relative rotation of the controller is always correct. (Well, within the realms of knowing where the center of rotation for the controller is.)

Even if the angle is something completely different from what it should be in an absolute sense, if you rotate the controller 90 degrees, it rotates 90 degrees relative to the error in that position.
So, you only need a single offset, not every possible angle.

Some other things to note:
The error for both controllers is pretty much the same. (Eg, it depends only on physical location, and doesn't really vary seperately for each controller), also, error is quite smooth.

You might find that from one location to the next the angular error goes from 10 degees to 20, but at the midpoint it's probably 15. Thus, interpolation of error map values is a fairly safe thing to do.
(Keep in mind though that I've seen angular changes which look almost spherical. - At one location it's pointing to the left, a bit further along in a straight line it's pointing up, and a bit further still it's pointing right.)
- Not a huge surprise when you think about what a magnetic field eminating from a fixed point would look like, but worth noting if it helps out with calibration at all.

So, calibration data therefore will ideally look like a 3d field of calibration points, each of which contains an x,y and z offset, and an angular offset.
(Or alteratively, given the way the hardware works, the same basic values, but using a polar coordinate system for the position data).

All in all it looks like a system that's pretty good to work with for accuracy purposes, as long as you can get over the hurdle of figuring out how to easily get calibration data for it without burdening users of the device unreasonably.

It's precise, it's consistent. It's just not accurate. XD

jjoudrey
Honored Guest
Do you happen to know where in the physical controller design the magnetic coils are?

I don't have much background magnetic interference, so I don't get much orientation error at different positions (other magnetic fields are far enough away to appear "flat"). However I do get position error at different orientations. Part of this could be using an inaccurate origin and part of it could be base station error.

I wish I had a good 3d model of one of these controllers to help with visualization.

Jesse

dbuck
Honored Guest
Interesting info, Thanks for taking the time to share!

JJ, Jan has a teardown of the hydra on mtbs3d: http://janoc.rd-h.com/archives/212 you may be able to infer where the coils were at in the case from some of the board shots

http://www.mtbs3d.com/phpBB/viewtopic.php?f=120&t=14036 for the actual teardown process, the coils are very close to the wire

KuraIthys
Honored Guest
"dbuck" wrote:
Interesting info, Thanks for taking the time to share!

JJ, Jan has a teardown of the hydra on mtbs3d: http://janoc.rd-h.com/archives/212 you may be able to infer where the coils were at in the case from some of the board shots

http://www.mtbs3d.com/phpBB/viewtopic.php?f=120&t=14036 for the actual teardown process, the coils are very close to the wire


unfortunately, I can't view any of the images. I'm sure they'd make it quite clear where the coils are in relation to the controller, but without being able to see any of the images it's not very helpful.

(Do you have to be a forum member to see the images? - it makes life a little difficult. XD)

Anyway, maybe the images show otherwise, but the behaviour of the controller data itself makes me think the coils are closer to the 'head' of the device, near the buttons.

But it's pretty difficult to determine with any accuracy where the center of rotation of the device actually is.

KuraIthys
Honored Guest
"KuraIthys" wrote:
"dbuck" wrote:
Interesting info, Thanks for taking the time to share!

JJ, Jan has a teardown of the hydra on mtbs3d: http://janoc.rd-h.com/archives/212 you may be able to infer where the coils were at in the case from some of the board shots

http://www.mtbs3d.com/phpBB/viewtopic.php?f=120&t=14036 for the actual teardown process, the coils are very close to the wire


unfortunately, I can't view any of the images. I'm sure they'd make it quite clear where the coils are in relation to the controller, but without being able to see any of the images it's not very helpful.

(Do you have to be a forum member to see the images? - it makes life a little difficult. XD)

Anyway, maybe the images show otherwise, but the behaviour of the controller data itself makes me think the coils are closer to the 'head' of the device, near the buttons.

But it's pretty difficult to determine with any accuracy where the center of rotation of the device actually is.


Edit: Upon closer inspection, by finding the lines at which the controllers read '0' in each axis, I infer that the origin as far as the SDK is concerned is the actual physical center of the controller.

That's perhaps a little awkward, considering the shape it has, but it would make sense when trying to use the device.
(It would also imply the origin is more or less in the middle of your palm.)

"drash" wrote:
(EDIT: Apparently the new official Sixense Hydra plugin in the Unity Asset Store does detect which hand is which),


Be careful with that. From what I've experienced of unity demos, it does have it's own system, but it relies on the same calibration process which you would otherwise use.
(Eg, if they're on the base station when the hydra is turned on, it knows which is which based on how they're placed. - but if someone is holding them, it's still based off which trigger is pulled.)
I've had several unity based hydra demos ask me to pull the left trigger, and then the right while pointing the controllers at the base station, so fundamentally the system still doesn't actually know which is which. They've just integrated their calibration procedures into the unity plugin. (so you shouldn't need to also figure it out for yourself...).

jerrydeanrsmith
Honored Guest
"edzieba" wrote:
A bonus for the first to implement "heads, shoulders, knees and toes" as a calibration method!


Head, Shoulders, Knees and Toes. Knees and Toes

KrisRedbeard
Explorer
"edzieba" wrote:
A bonus for the first to implement "heads, shoulders, knees and toes" as a calibration method!

"Head, shoulders, knees and ... " *THUMP*
Wake up on floor 5 minutes later, with a large bruise and a new dent on the edge of the desk.


Deciding how best to calibrate and how often will vary depending on what the target use of the Hydras is.

For a seated position, I was thinking of a similar pose to Kinect, thumbs in.
Then rotate right/left in to touch elbows and basically karate chop the air, hopefully without smashing anything.
Gives a basic range of motion.

For standing up, head, shoulders, knees and toes isn't really that silly.