Resolution

Manufacturer specifications:

10 bit (1024 position per finger)

Our results:

The goal of our tests here was to ensure that the electrical circuits as well as the software were working with full 10 bits of resolution. In order to validate this we wrote a simple test application that logs the raw data for each finger over time. We then analysed the data to find the smallest value increment that can be found over the sample period. Our test revealed a few specific value ranges were the minimal separation was 1/1023. This being said, in most case, the smallest increment was 2/1023 or 4/1023 which tend to say that the system was either using a 9 or 8 bits resolution instead of the quoted 10 bits (1024 different levels).

The graph below shows the data samples that we used. The vertical axis represents the flexion value we measured of one finger while the horizontal axis represents the sample number, in our case, about 8000 data samples.

What immediately attract our attention are the gaps between the sample points vertically. We can clearly see that many value ranges are never used. While this would be the sign of an 8 bits A/D converter resolution being scaled up to a 10 bits resolution, we indeed found values that have a separation of only 1, thus supporting the stated manufacturer claim of 10 bits resolution. What can be the cause of these gaps? It is hard to tell at this point. The consequence of this is that while the hardware may be running a 10 bits resolution A/D converter, something comes along the path and reduce the effective precision of the measured values.

The second thing we note is the apparent absence of sample points in the 600 - 1024 range. This can be caused by two factors: 1) the relation between the length of the finger and bend sensor and 2) a non-linear behaviour of the resistive-based bend sensors.

Will these observations have an impact on the glove performance? Well, not as much as it seems. You have to take into account that most low-end / low-cost VR gloves use resistive bend sensors. Thus, they all potentially exhibit the non-linear behaviour we noted above. Depending on how the glove hardware / software driver is engineered, some manufacturer may incorporate built-in compensation for these types of undesirable behaviours while other will not. In the current case, it seems like there is no built-in compensation. The software developer is thus responsible of adding some compensation methods in between what he reads from the glove SDK calls and what he uses in his own application.

We tested the glove in a typical VR application to see how it would actually behave. In our application, the finger flexion values were directly related to rotations of finger joints on a virtual hand model in the scene. While the finger rotation where not totally on scale with the real hand movements, the technical concerns we noted in the above paragraphs did not create much visual artefacts or anomalies. Secondly, even thought resolution may not be 10 bits over the full finger flexion range, the actual resolution was quite sufficient for the task in our typical VR test case.

Update rates

Manufacturer specifications:

Update rate: 85 Hz

Our results:

To measure the update rate, we recorded the time elapsed between the two closest finger flexion values where the actual value changed. In other words, if the glove API returned us the same flexion value for 10 consecutive samples, we considered that has a single finger reading regarding the update rate. Thus, measuring the time between two different values of finger flexion tells us how many actual samples the glove can process per second. We repeated that measurement 1000 times in order to get sufficient samples to be able to do valid analysis on the data recorded. The following graph shows the fluctuation of the fastest times between two consecutive different samples, repeated for 1000 samples that we read from the glove.

As it can be seen, the variation of the update rate is quite large, from 100 Hz, down to 12.5 Hz. There were about 140 negative values which were rejected from the analysis and considered reading anomalies. Considering the current results, the average update rate achievable with the glove is somewhere around 22 Hz, which is far from the 85 Hz advertised in the manufacturer specifications.

Our first series of tests were done using the built-in data filter. We repeated the same measurements but this time without filtering. We obtained the following results:

This is much better in term of stability, while the performance remains centered around 29 Hz. Thus, from our observations, it seems that the glove raw throughput is somewhere near 30 Hz.

Static accuracy

Manufacturer specifications:

No specific information available besides the graphs below.

Our results:

For that test, we put the VHand on a flat surface so that it rests totally immobile. We then read 1000 data samples per finger and observed the static behaviour of the returned data. We basically evaluated the data noise produced by the glove electronic circuits.

The next graph shows the variations of finger flexion values returned on 1000 consecutive samples.

We can see that the values returned while the glove is in a steady state are quite stable. The thumb and index did show some instability but on a scale of 0 to 1024, the fluctuations represent 0.78% of the full scale in the worst case. The table that follows gives the statistics for each finger.

The content of this review is copyrighted by VResources and its authors. No reproduction, in part or in its totality, of the present article is allowed. Please contact the authors for any inquiry or comments about this article. Copyright 2005 - VResources, All Rights Reserved.