If I use the EyeTribe own calibration procedure, even if I get a “perfect” result, it’s practically unusable in GazeSpeaker, as the cursor “tremble” so much that it makes impossible to focus a button or object.

Any idea why? Install and reinstall both programs (GazeSpeaker and EyeTribe GUI/Server) didn’t helped.

Thanks

Simply go to the calibration screen of Gazespeaker, click on the 0 button (reset calibration) and then calibrate directly with the Eye Tribe (with the EyeTribe UI).

NB: the calibration within Gazespeaker is designed for specific use cases when an adult or caregiver calibrates the eye tracker first and the child or patient calibrates with Gazespeaker in a simplified way.

I already tried this, and while running the EyeTribe UI with the “Mouse cursor control” activated, I can perfectly move and focus the cursor on any part of the screen.

The problem start when I run GazeSpeaker. It seems like the right columns of the grid are impossible to focus.
If I use the “StartUp” grid for example, I can only reach the exit button, emails and books (first right column).
All other buttons are very difficult or impossible to focus.

I pressed “0” as you requested, but how do I know if I’ve really reset the GazeSpeaker calibration?

Thanks again for your help.

Best

Any clue why?

Thanks

Best

You need to calibrate the Eye Tribe tracker with the Eye Tribe UI. The new version of the Eye Tribe driver (0.9.56) records the last calibration so you don’t need to recalibrate before each session.

1st test : You can check the accuracy of the calibration in the training screen of Gazespeaker: you will see 3 circles representing your left eye gaze, right eye gaze and the average of both eyes directly on the screen. The 3 circles should be displayed at the position where you look. There can be a slight difference between the left and right eye.

2nd test: you can change in the settings screen / user tab / eye tracking block the value of auto-centering: set it to NO (default if Yes) -> this way, in the grids within Gazespeaker the cursor will be exactly where you look

best regards
Pierre

I am having the same issue on a fresh installation (just got delivery of the eye tribe) of eyetribe SDK and gazespeaker.

There appeared to be an offset between the eyetracked coordinates and the gazespeakers pointer coordinates.

given this, i tried with a regular mouse. with the same issue as above. I first chose click mouse as the input method (no eyetracking, or eyetracking mouse control) to gazespeaker. Next when trying to navigate gazespeaker i noticed that even though the mouse pointer was pointing to a particular location, when i clicked on the left mouse button, the click was registered at another coordinate, which subsequently activates what ever button underneath those coordinates.

Please Help.

What is your configuration (windows version, screen resolution) ? when you launch Gazespeaker, does it fill the whole screen ? We are trying to replicate your problem.

Could you please try this in the settings screen : input mode = Mouse movement
-> does the cursor move along to the mouse pointer ?
-> is the cell activated this way the right one ?

I am on Windows 8.1, 1920×1080 resolution, Core i5, 4GB Ram. The machine is a Samsung ATIV XE700T1C-A01US Smart PC Pro.

It does fill the whole Screen. The problem does not appear on the “GazeSpeaker – home page”, but occurs after going to the main operational page by Pressing the Start button on the homepage.

Furthermore, the mouse coordinates and click coordinates seem to be normal on the pop up navigation buttons (Back, Home, Power). whilst the rest of the screen seems to be having an offset between actual pointer location and what the program registers on click.

when in “input mode = Mouse movement”, the problem became obvious. as one can see on screen the real mouse pointer as well as what the program registers as the pointer. there is a non constant offset between the actual and registered mouse pointers. at 0,0 which i will consider top left hand corner, the offset disappears , but the offset gradually increases by the time the mouse reaches the bottom right hand corner.

I have attached a few screenshots with the actual mouse pointer drawn in (since its not captured using print screen) to demonstrate the problem. (link1: link2: )

i would assume a scaling constant.