PyGaze, PsychoPy, and EyeLink 1000

[arnohakk]

Hey, having worked with PyGaze and a Tobii Tracker for the past years, we now tried to test our stuff using an EyeLink 1000. We tried the shooting_game.py somewhat successful when using pygame (although I did not score any points when looking at the circles.) When trying to use psychopy (which works fine with the Tobii Tracker) and the first selection screen appears I cannot really do something: When I press any button on the display PC, Windows 10 tells me that python might have crashed and I can either stop it or wait to response. But when I click on like calibrate on the host PC, I can somewhat do a calibration and also send the tracker image to the display PC and somehow I can also make the experiment start. So it looks like, I cannot manage the EyeLink via the display PC when using PsychoPy.

I have never worked with an EyeLink before, is there anything to consider in the EyeLink settings? It tells me that I am using PyGaze version 0.6.0a24 and pylink 100119.

[esdalmaijer]

That sounds problematic! Let me try a few boring additional questions to perhaps pinpoint the problem.

What are the versions of the following Python packages?

• pywin32
• pypiwin32
• configobj
• future
• json_tricks
• pyglet
• pygame
• psychopy

What environment are you running the scripts from? Directly from a code editor, e.g. via Anaconda? Or by running the scripts through a command prompt? (E.g.by running python shooting_game.py)

Is that a no-SDL version of PyLink you're using?

What is the game doing? Do you see a crosshair following your gaze?

What do you mean by "somewhat do a calibration"?

What resolution is your display, and what resolution have you defined in constants.py?

Further troubleshooting

One issue I've been running into with PsychoPy and Win10 is that a newer version of pyglet doesn't work. This seems to be down to an updated reference in pyglet that isn't reflected in PsychoPy yet; it might well be coincidence that we ran into it here when switching to Win10 stimulus machines. Try downgrading pyglet to version 1.3.2: pip install pyglet==1.3.2

Another issue is with SDL within PyLink and PsychoPy. This was a long time ago, but required a no-SDL version of PyLink to be installed to prevent weird interactions with PsychoPy/pyglet. (This merely resulted in visual artifacts, though, not full-on segfaults.)

A very common issue is a mismatch between resolutions. I'm sure you checked this, but a mismatch between actual resolution, tracker-expected resolution, and the resolution set in the experiment can cause weird calibration results. (Usually just setting a single DISPSIZE in constants.py fixes this issue.)

[arnohakk]

Thanks for the tips! We will test these thing this week and will come back to you.
Just a reminder: Everything is working fine with the Tobii Tracker, even with PsychoPy.

[arnohakk]

So the versions of the packages are:

• pywin32: 224
• pypiwin32: No module found
• configobj: No module found
• future: 0.17.1
• json_tricks: 3.13.1
• pyglet: 1.3.2
• pygame: 1.9.1release
• psychopy: 3.1.0

The script is running trough a command promt.

Concerning the no-SDL question, it seems to be a SDL version (version number 1.0.0.119). However I am not entirely sure how to check wether it is the case or not.

The crosshair is following my gaze.

The calibration works so far, however seems to be very imprecise.

The resolution is (1920, 1080), which has also been changed in the constants.py

[arnohakk]

The problem seems to be that key presses via the PyGaze keyboard that should control the eyetracker seem not to work correctly. When using the Host PC, it seems to be working (e.g. we can see the tracker image on the Display PC when clicking on the corresponding button on the Host PC)

[esdalmaijer]

Thanks for narrowing it down!

Just a hunch, but could you test what happens when you change line 77 in pygaze/_eyetracker/eyelinkgraphics to the following:

		self.kb = Keyboard(keylist=None, timeout=1)

EDIT for context: The current timeout is set to 0 milliseconds, which used to return any calls to get_key straight away (for any keypress that occurred before calling the function). It's a lot safer to choose a small positive number to achieve this behaviour, though, given how the Keyboard.get_key method works.