OS (e.g. Win10): Win10
PsychoPy version (e.g. 1.84.x): 2021.2.3
Standard Standalone? (y/n) yes
I am trying to run an experiment using the new build in eyetracker feature. It seems to work just fine, apart from the fact that adding “Eyetracker record” and “Region of interest” components to my experiment drastically slows down responsiveness of Psychopy while running the experiment. I am using a keyboard input to force end of routine, which normally is instantaneous in its response, but with eyetracking components added has an added delay after pressing keyboard input to force end routine, and sometimes doesn’t register the keyboard input at all and requires a second press, something that never happens without the eyetracking components added.
Running the experiment with eyetracker configured and with calibration and validation, but with “Eyetracker record” and “Region of interest” both disabled does not have this issue and behaves as normally expected.
I am using a desttop Eyelink 1000 with default setup.
Does anyone know what my issue is, and if it is fixable?
OS (e.g. Win10): Win10
Thank you for posting the issue. These issues with the Builder integration and EyeLink were brought to our attention last week by another user. Basically the issue is that EyeLink start / stop record calls can take up to 0.5 seconds to run and we did not factor this into the design of the ETRecord functionality. Other supported trackers do not have this issue.
There is no immediate fix for the problem, so currently you can use the Builder interface to configure and calibrate the EyeLink, but can not use the ETRecord or ROI features.
Instead you will need to add custom code to the project where you want to start or stop recording by adding custom code components. To start recording add a new routine and then add the following to the begin routine tab of a custom code component in the routine:
To stop recording add a new routine and then add the following to the end routine tab of a custom code component:
Starting and stopping of recording should be done when no keyboard events are expected so if one occurs during that 0.5 second time period it is not dropped.
A proper fix for this will be available in the a future release. Sorry for any inconvience.
Thanks a lot for the response! I will try out your advise. any chance that there is any ressources available for how to set up ROI without the builder interface?
If you have the time, have a look at my other post I put up just a minute ago:
In it I describe what I think is a perhaps somewhat overlapping bug/behavior but this one seems to be timing irrelevant
Thanks again for the help! Is it possible to set up and use ROI using custom code compenent similar to what you described above with Eye Link 1000? or does the ROI component specifically need the etRecord component, and does not function with the method you described?
No, unfortunately not. As you suggested, the ROI component needs an ETRecord component, which for the EyeLink really needs to support starting and stopping recording outside the ‘trial’ routine logic so that the time it takes does not impact presentation timing.
Until the root issues are resolved, you could implement your own region of interest type functionality using some extra custom code that calls something like the following on each frame when you want to monitor eye position:
# Note: eyetracker should already be recording... # Get last eye position gpos = eyetracker.getLastGazePosition() if isinstance(gpos, (tuple, list)): # There was an eye position available # Check if it is within a visual stim called 'gaze_region_stim' if gaze_region_stim.contains(gpos): # Add logic for when eye is within the gaze_region_stim # ... pass else: # Add logic for when eye is outside the gaze_region_stim # ... pass
Again, thanks a lot!
I will attempt that approach.
Hi @sol ,
Do you think it would be a good idea to add a blank text component that lasts .5 sec in the start recording routine to wait for eyelink to actually start recording? My trial loop comes right after the start recording routine.
Another option is to add a .5 sec ISI static component to the routine where you start recording, that seems to have worked for me
@skjoldan, thanks for thinking of using the ISI as a work around for this particular issue.
Did you end up getting it to work as expected?
I initially thought I had it working without dropped keys, but now the issue has shown up again, and I am now unsure if I ever actually got it working in the first place.
@skjoldan, until the fix for this issue is pulled into a release, when using eyelink, you should start / stop recording when the user is not likely to make a key press / release during the 0.5 seconds it takes to start / stop recording, for example by starting recording right after calibration and stopping recording at the end of the experiment.
Another short term work around might be to wait for the key release before starting / stopping recording so that it will not occur during this 0.5 sec period and gets lost, causing the next press of that key to be ignored because it is being considered an auto-repeat.
A final (last resort) option would be to edit the generated python script from your Builder project and move around some lines of code so that you force psychopy to use a different keyboard event handling backend when you are using the eyelink. I can provide more details on this option if the others just won’t work for your paradigm.
Thanks again for your assistance, it has been invaluable!
Incasing both start and stop recording in 0.5 sec ISI both prior and after running the code has again solved the issue, I think the problem was as you described an auto repeat issue. This work around has solved it for now.