[open] Error with Tobii eye tracker

neon

Hi guys,

I've started to have a play with our Tobii eye tracker (X2-60) with Opensesame, using the PyGaze plugin. I've copied the relevant files from the SDK to the Opensesame directory. I then had to edit libtobii.py (which I downloaded from Github) to allow import of Image and ImageDraw fromPIL as this wasn't importing properly.
With it seemingly working, I tried running the pyGaze template, which works fine until just after calibration, when I encounter a division by zero error. Error message thus:

Unexpected error

item-stack: experiment[run].pygaze_init[run]
exception message: integer division or modulo by zero
time: Wed Jun 01 15:49:14 2016
exception type: ZeroDivisionError

Traceback:
<snip>
  File "C:\Program Files (x86)\OpenSesame\plugins\pygaze_init\pygaze_init.py", line 212, in run
  File "C:\Program Files (x86)\OpenSesame\pygaze\_eyetracker\libtobii.py", line 323, in calibrate
ZeroDivisionError: integer division or modulo by zero

Looking at line 323 in libtobii.py, I am guessing len(Xvar) is zero. Does anyone have any idea why this might be occurring, or what Xvar represents? This is using Opensesame 3.0.7, on a Windows7 laptop. Any advice or suggestions gratefully appreciated.

Thanks a million in advance!

Neon

neon

Hi folks,

Further to my above post, this seemed to stem from a mismatch in resolution between the screen and the experiment. However, with that solved, there still appear to be severe problems; this seems to stem from the 'drift correction' plugin. Things seem to halt at this point. Has anyone else encountered such problems? I appreciate I am giving little detail here, but before I give a more verbose description, I wonder whether anyone else has experienced this?
Many thanks,
N

Edwin

Hi Neon,

Just wanted to comment to let you know we're not ignoring you! Unfortunately, none of the developers have access to a Tobii anymore. That makes debugging this tough. My guess is that the issue is with the fixation-triggered drift check. Did you activate that?

If it's the regular drift check (non fixation-triggered, but triggered with a Space press), then the issue is likely to be with the sampling. Can you use the sample method within an inline_script, and does it produce regular values?

Cheers,

Edwin

neon

Hi Edwin,

Thank you very much for your reply. Yes - I would imagine trying to debug without access to the Tobii hardware must be pretty hard! I hope to be working quite extensively with Opensesame/pyGaze/Tobii over the coming months, so I'll try to post my experiences and help anyone else experiencing difficulties where possible.

Back to the problem at hand; it would appear that the problems do appear to come from the drift correction plugin. I have tried both the fixation triggered and space press, with the same consequences. The sample method seems to work fine when called from an inline, but when the drift correction plugin comes to be used, the fixation target does not appear at all, then it just seems to hang for a long time and not respond to anything. At some point I might see if I can have a play with the plugin code and see whats going wrong.

So, on a related note, do you think it is problematic to run an experiment without drift correction - given that calibration is acceptable?

Thanks for any advice, and again thanks for taking the time to reply,

Neon

Edwin

Hi Neon,

On Tobii, the drift correction actually is merely a check whether the calibration is still ok. You can then correct it by re-doing the calibration (by pressing 'Q' during the drift check).

The same functionality can be implemented in an inline_script. This might be a good place to debug any problems. Essentially, all the drift_correction is supposed to do, is to draw a fixation dot and to check whether gaze samples are within a pre-defined range within that fixation dot. (Process: Draw dot at (x,y), continuously sample, continue once a sample is within N pixels of (x,y). )

If your experiment isn't that long, and your participants behave nicely (i.e. don't move around too much), there might not be a need for drift checks. But check whether you might or might not need them, by checking how good your data quality is at the start of your experiment vs. at the end. (If there is a difference, for example due to drift, then calibration checks are a good idea.)

Cheers,

Edwin

neon

Thanks, Edwin. I'm going to have a look first whether I actually need the drift check, I think. It shouldn't be a long experiment, and the participants can be expected to stay relatively still hopefully.

If the data looks poor, I'll take another look at scripting a simple drift check as you outline above.

Thanks again for the advice though.

Neon