|
#1
|
|||
|
|||
cameras get confused by many LEDs
Hello,
I have noticed that the PPT trackers get confused by multiple LEDs (lights) when two lights get too close to each other or one gets right on top of another. I have a total of three lights right now one for the HMD and one for each glove. If I put one hand on top of another there is a high probability that from that point the trackers think that the right hand is left and the left hand is right. I get a similar problem with a glove LED and a HMD LED when for example I try to adjust the HMD with one of my hands while the lights are being tracked. Is it possible to maybe use different colors for the three LEDS (they are all bright blue right now) so that even if two or more cross paths trackers don't get confused? Can you program the trackers to distinguish colors or maybe brightness somehow. Max |
#2
|
|||
|
|||
Hi Max, this is a very good question - thanks for bringing it up. The PPT tracker does not distinguish the identity of the up to 4 LEDs it tracks, just reports their position. Identity switches can occur, but usually they do not occur if the speed of the movement is below a certain threshold (which you can define yourself as one of the parameters in PPT 1.4).
Depending on the application, it is possible to distinguish very robustly which marker is which, just by using simple criteria like height (see for example a movie from a recent setup we had with Stanford University at Wired Magazine's NextFest in San Francisco: http://www.worldviz.com/products/ppt...ps/fighter.wmv ). In this fighting application, the higher marker is always the head, the lower marker the hand. In your case, that would do the job for making sure the hands and the head do not get mixed up (for example after you bring your hand up to the HMD for adjustments). For distinguishing left and right hand, you can implement this in your Vizard script. Please contact me directly at pusch@worldviz.com about this. |
#3
|
|||
|
|||
Thanks for the inquiry. You are right that there are many possible methods to determine the identity of a marker. Intensity and color are not possible with our hardware. In fact, the PPT hardware does not ever inform you of the lights’ absolute identity. What we do provide is tracking of multiple points but whose identity may be swapping in a manner that you’ve experienced. We are finalizing the release of a free PPT upgrade that will greatly reduce the incidence of swapping, but even then it is still up to the application engineer to determine absolute identity. For you particular application, our suggest right now is to apply the constraint that the users hands must always be below the head. This then reduces the problem to identity which of two lights is the left and right hand. If again you apply a constraint that the left handle is always to the left of the right hand, then this determination too becomes almost trivial.
Below I show some code that solves the identification for the scenario described above. I first show a snippet which I expect replicates what I guess to be your current programming method in which you automatically engage automatic head tracking of the first of 3 lights. The problem with method is that you’re always stuck with the light always updating the head even when that light changes identity and becomes the hand. PHP Code:
Now, the next snippet of code shows how to manually update the head position (orientation tracking is still engaged in automatic mode but even this can be done manually if you prefer). You see a big if-then-else statement that checks for which light is highest and then which light is most left and then assigns the light’s accordingly. This should be all it takes to make the light identities 100% robust. PHP Code:
Let me know if this solution makes sense and if you find it acceptable. |
#4
|
|||
|
|||
method works
Hi guys,
I implemented the method you came up with and it worked pretty well. The only minor issue is that if the user violates the constraints, there will be some "weirdness" going on in the virtual environment. For instance, if you DO happen to raise a hand above the head, the view position will temporarily be controlled by the hand. But, it works ok. Thanks, Max |
#5
|
|||
|
|||
Just a thought... (from a not-so-experienced programmer)
couldn't one take care of the "wierd jumps" by seeing if there is a switch in lights and adjusting where your PPT data goes depending on which lights crossed over? That is, once we determined that the left hand went above the head, we store that info somewhere and essentially use the "head" light (highest light in PPT) for the left hand? I think this could be accomplished by storing the last point(s) a light was at, and when the PPT system thinks the lights suddenly "jumped" to different places, you compare the "history" and adjust properly. I'm not sure how one would code this, but it seems like its computationally possible and would not be too cpu expensive. extremely sudo code: # so before any objects are moved/rotated if (hand and head jump farther than threashhold value) compute distance between handL.prev() and head.pos() if distance < jump distance #hand now higher than head swap head and hand inputs the only problem with this is when the hand is close to the head in all coords (x,y,z). then the code might err when the expected distance >= to the jump distance. *i have no idea if this makes sense or is full of mistakes |
#6
|
|||
|
|||
Hi, this is a good concept overall, and in fact this is what we are doing in some Vizard applications, where it can be very easily implemented: just define a threshold for 'position jump' and check for proximity with all LED positions.
We are currently working on an update of the PPT software which is significantly more robust than the old version in this respect. We expect it to be available before the end of this year. Thanks again for your suggestions which make a lot of sense and are highly appreciated. Have fun! Matthias |
#7
|
|||
|
|||
follow up
Hello,
I'm wondering whether the update of the PPT software that mspusch mentioned is available now? And from which version we can deal with identification of multiple LEDs? Thanks a lot. |
#8
|
|||
|
|||
the update mentioned in my post from summer 2004 came out in Oct. 2004. there have been several other updates since. the PPT is now available as a version with 2 cams, one with 4 cams and one with 8 cams.
since March 2007, there is also a new system available called PPT-H which trackes with 175Hz and is even more stable with holding onto individual markers. this system can chain up to 32 cams and track up to 35 markers. the PPT is now reasonably good at following markers around, i.e. holding on to a marker's ID. however, to make sure markers are distinguished reliably, it is necessary to introduce some constraints (i.e. marker configurations). We usually use marker distance for this, as it is the most simple way of doing it. |
#9
|
|||
|
|||
Hi, mspusch
Our PPT is Version 2.17 with 4 cams, but I'm not sure how old it is. Do you think it support multiple markers well? Could you please post an example of how to set marker configurations? And I don't know what do you mean "use marker distance". Thanks for help. |
#10
|
|||
|
|||
version 2.17 is a recent version and you should be able to track up to 8 LEDs. in the interface on the left side, simply change the number of LEDs the PPT searches for from 1 to 8, depending on how many you need.
the positions of the LEDs that the PPT finds will be sent out over serial/VRPN or your own interface if you interface directly over the PPT API. now, in whatever program you use, you can take the x,y,z coordinates that the PPT delivers and do with it whatever you want. if you use Vizard, you can use a logic just like the one that's on top of this thread to extrapolate information. if you work with Vizard and need a code example of how to use a certain distance between markers to extrapolate their identities, please post this request on the Vizard part of this forum. |
Thread Tools | |
Display Modes | Rate This Thread |
|
|