Home Forums Software Development First experiences with REX

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
  • #555


    I received my REX sensor yesterday and spent some time playing around with it. I decided to use the EyeX SDK for the start, set it all up and attached the REX to the screen. All things worked out flawlessly to this point.

    Before starting I checked the firmware of my sensor and discovered my first surprise. My sensor comes with version 1.1.4 preinstalled, on Tobii’s developer website the current version is listed as 1.1.2. Is my sensor up to date? And where can I find the newest version of the firmware as well as a corresponding changelog?

    After playing around with seating positions and recalibrating several individual points for a while I managed to get quite good at tracking in the trace gaze option of the driver. Most of the fixation points are within the white circles, several even spot on. To achieve this accuracy I had to look carefully that my eyes are horizontally and vertically centered in the tracking frame and the distance is as suggested. Minor changes in the position of my eyes cause directly a degradation of the tracking performance.

    Quite satisfied with the results I installed the demo software and worked through the exercises. Unfortunately I had to discover that the tracking is not as accurate as in the trace gaze application. I had to find that there seems to be a systematic error estimating the gaze position by a remarkable factor. All estimated positions are shifted in four o’clock direction. For instance the very first exercise showing the Windows 8 launch menu. When looking at the center of the charms most of them are recognized falsely. When readjusting my gaze to an upper left point above the desired charm I was able to control the selection. The same observation could be made more or less in the other exercises. To give another example, when reopening the Firefox window in the mixed gaze and mouse exercise I have to aim at the upper left corner of the box surrounding the Firefox icon to move the cursor right into the center of the icon. All in all this gives a quite unnatural experience as you have to look at a point in the nirvana and use your peripheral view to judge if you succeeded. I reiterated the calibration and testing several times, even asking some of my friends to try it out, but all testings came to the same conclusion.

    As a developer two questions pop up into my mind. As the gaze tracking is quite on spot there have to be some changes between this testing and the demonstration application. But what reason might cause this difference in performance? Furthermore I am wondering if there is anything I can do as a developer if the tracking is systematically wrong and recalibrating the system does not ameliorate the results.


    Hi Elias,
    thank you for your thorough report!

    To start with, yes, your firmware is up to date. Your REX unit is one of the first shipped from the most recent manufacturing batch, and the difference between firmware versions is that the 1.1.4 works with a small design change in the new batch. (And of course it works with previous batches too.)

    The tracking accuracy and precision that you achieved is better than you’d expect for most people. Nice! But be aware that most people don’t have as good accuracy and precision as you do when designing your app. A less accuracy-demanding user interface would spare you from having to sit still, dead center in the track box, too.

    The experience that you had with the demo software sounds a lot like an offset error to me. I totally agree that it’s awkward to try to compensate for those errors by looking “in nirvana”. The question is why you’d get this kind of error in the demo app, when you don’t see it with the trace gaze function. I’ll have to investigate.


    During the demo I am asked to recalibrate the system. Perhaps this might be the reason for the difference. The precision I described above is achieved with careful recalibration of points with offset. Is there anything I can do to help investigating this strange result?

    I am aware that current eye tracking accuracy is limited. I am currently experimenting to find a compromise between accuracy and reliability. Do you have any measurements what accuracy can be expected from an ordinary user? Is the white circle a good approximation?

    Last question: As you told me I have a new hardware update I am wondering if I can use the TCP/IP firmware provided on your website. Is it correct that the 1.1.2 HID firmware is not compatible with my device?


    Hi Elias,
    I’ll address your questions one at a time:

    Q. What accuracy can be expected from an ordinary user?
    A. The technical specs for the Tobii X2-30, which is similar but not identical to the Tobii REX, state an accuracy (“offset error”) of 0.4 degrees and a precision (“noise”) of 0.32 degrees in an ideal environment.

    If we take those values as a starting point and round up — to cater for hardware differences and perhaps a less-than-ideal environment — then the recommendation would be to design for an error of roughly 1 degree, corresponding to 1 cm at 60 cm distance. Which is in line with my experience.

    Q. Can I use the TCP/IP firmware with my REX?
    A. Since I happen to know that your device is from the very latest batch (it came with the 1.1.4 firmware on it), I wouldn’t recommend a downgrade. But the plan is to make the next firmware version support both USB-HID and TCP/IP, so please just have patience. And no, I don’t know when the next firmware version will be available :-).


    Thanks for the comment. Do you have any specs about the accuracy over the field of view? To be more concrete: The REX is designed to work with screens up to 27 inches. 1cm of error should be acceptable for this size, but on a 10 inch screen this error would be huge…

    Interpreting your statement I suggest the REX is operating in a 60 degree field of view properly. But how is the error rate distribution over this field of view? It is obvious that the error rate is higher at the borders of the screen than in the center. Do you have a guideline for designing the interface in dependence of the screen size in degrees?

    Regarding the firmware I may get into trouble. I bought the REX in advice of one of your colleges who pointed out that the REX has two main advantages over the EyeX. It is available now and it has some basic cross platform functionality. First I had to wait for over a month for the REX to arrive and now I have to learn that the device shipped to me is currently not compatible with other operating systems… I bought this device for developing under Linux and now I got stuck…

    I know that all these products are under development but when deciding to release this product to the public with a given specs sheet you should try as hard as you can to give the customer what you have promised. As I have to plan my further proceedings as well, a statement when I can expect my device to be fully functional would be very welcome.



    “It is obvious that the error rate is higher at the borders of the screen than in the center.”

    I definitely notice that also.

    Masta Lomaster

    Hi Elias and All!
    You’ve mentioned Windows 8 and a 10″ display.
    It sounds like you use something like Windows Surface tablet.
    Then you most probably have a screen scale of 125% (default for this tablet).
    The real resolution is 1920×1080, but the cursor coordinates are in the range of 1536×854.
    (See screen resolution -> Make Text and other items larger or smaller ->
    Medium – 125%, right?)

    You might have been warned when you were starting “Tobii Showcase”: “Tobii Showcase is not compatible with a screen scale larger than 100%. Some demos might not work as expected. Do you want to continue?”

    That is the reason you were missing in the Windows 8 launch menu and in the mixed gaze and mouse exercise. Set the “Make Text and other items larger or smaller” to 100% and try once again. You’ll be surprised how precise the pointing is…

    You need to take this into account when creating your own applications. I do it like this (it works, but not sure it’s the perfect way):

    DEVMODE dm;
    ZeroMemory (&dm, sizeof (dm));
    EnumDisplaySettings (NULL, ENUM_CURRENT_SETTINGS, &dm);

    P.S. Sorry for returning you back from Nirvana…

    Masta Lomaster

    I wonder why Tobii still keeps this “Tobii Showcase is not compatible with a screen scale larger than 100%” incompatibility.

    Almost 100% of the laptop users have this “Make Text and other items larger” parameter set, and all of them are disappointed with the Showcase.

    Scenario looks like this:
    1 The user starts the “Tobii Showcase” and gets the warning.
    2. “Hmm, I still want to try this..” and pushes the button to continue
    3. Calibration runs perfectly. The user forgets about the warning. “Wow, it runs!”
    4. SOME demos are not sensitive to this HighDPI settings, and run OK
    5. Finally the user cannot push the windows8 button, cannot hit the asteroids…. “Hmm, this device is [still] not mature… Will sell it or wait for a new firmware”.

    Hey, Tobii folks! It’s just a few lines of code. You are missing the opportunity to impress people!

    Robert [Tobii]

    Thanks for the advice! Tobii Showcase was originally built for internal usage at customer demos and exhibitions, where the environment could be controlled. Therefore there are some limitations (only runs on primary screen, not 100% screen scale sensitive, etc.) It is also not updated to use the EyeX Engine filtering and high-level interaction behaviors. We hope to have time to give Tobii Showcase some quality time soon, but there are other things coming out the door first.

Viewing 9 posts - 1 through 9 (of 9 total)
  • You must be logged in to reply to this topic.