Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Supported by

Include recalibration in the middle of the experiment? Drift correction is prone to crash or stuck?

Hi all,

First, want to salute you for the amazing work you guys are doing with opensesame and pygaze!

I am having a little issue with drift correction using the pygaze plugin in OS. I am using Tobii tx300, and the experiment is running fine in general, but, the drift correction is giving me some problems.

1 - When I include it in the trial sequence, the drift correction appears to be 'not so sensitive', and it often results in the experiment getting stuck, or crashing, in both fixation or space bar triggered modes.

If I delete the drift correction, the experiment runs smoothly, but I am worried that the quality of the gaze data will decrease as the task progresses.

So, I want to know if there's a way to include a recalibration in the middle of the experiment? I tried to do this by duplicating the pygaze_init, but this doesn't work.

On another note, I noticed that when using the Expryment backend, the calibration doesn't show the results and it skips the validation phase, is this behavior to be expected? the Psycho backend doesn't read my videos for whatever reason, so I skipped that altogether.

Best wishes
Helio

Comments

  • Hi Helio,

    I'm not sure whether it also works with Tobii, but you can try to press q during the drift correct phase to get back to the calibration menu (that works in Eyelink) and start the calibration there. Just make sure that the experiment pauses and participants don't accidentally continue with the drift correct. But again, I have never worked with Tobii, so maybe the solution doesn't really apply here.

    Eduard

  • Hi Eduard,

    thanks for your comment. Unfortunately, I tried pressing q and it doesn't call the recalibration.

    Helio

  • Did you set the drift check to "fixation triggered"? Pressing Q during a drift check should start a calibration. (Handled in this line.) What output does the Debug Window show?

  • @Edwin thanks, I had the "fixation triggered" already, I just didn't realize that the Q for recalibration had to be pressed "during" the drift check. It is working now. thanks. However, is there a way to call recalibration between blocks instead off between trials? I worry that if the "drift check" crashes in the middle of the experiment (it happen to me a few times) I may have to restart the task.

    Cheers!
    Helio

  • Hi Helio,

    Yes, there is! You could add an inline_script item, and use the following code to its Run Phase:

    eyetracker.calibrate()
    

    You can make this inline_script item part of your trial sequence item, and use the "Run if" statement to only make it run every few trials.

    If your blocks are organised in different sequences, you can simply place the inline_script in between those sequences.

    Cheers,
    Edwin

    Thanked by 1heliocuve
  • edited January 9

    Hi @Edwin,

    When using this in an inline_script, the recalibration seems to be going fine, but then after the validation is complete, I get this error below (sorry to paste it like this, I am sending this on a different computer and only copied the error to an text file)

    Error while executing inline script
    item-stack: experiment[run].recalibration[run]
    exception type: TypeError
    exception message: unsupported operand type(s) for ** or pow(): 'NoneType' and 'float'
    item: recalibration
    time: Wed Jan 09 17:56:21 2019
    phase: run
    Traceback:
    File "C:\Program Files (x86)\OpenSesame\lib\site-packages\libopensesame\inline_script.py", line 96, in run
    self.experiment.python_workspace._exec(self.crun)
    File "C:\Program Files (x86)\OpenSesame\lib\site-packages\libopensesame\base_python_workspace.py", line 124, in _exec
    exec(bytecode, self._globals)
    Inline script, line 1, in
    File "C:\Program Files (x86)\OpenSesame\lib\site-packages\pygaze_eyetracker\libtobii.py", line 569, in calibrate
    XRMS = (self._mean(Xvar))**0.5
    TypeError: unsupported operand type(s) for ** or pow(): 'NoneType' and 'float'

    I also started randomly getting this error on the py_gaze_init after the calibration and validation. Any ideas what might be triggering this error?

    Thanks in advance.

    Cheers,
    Helio

  • Hi @Edwin

    really sorry to bug you with this, but I spent the day trying to solve this, so that I can start testing. While everything seems to be working fine and the eye-tracker sensitivity in my new setup is pretty good, this last problem persists. Sometimes, I am able to get the experiment running but most of the time I get this unexpected TypeError in the initial calibration for py_gaze_init or when after re-calibrating following a drift correction, or between experiment blocks, after I call the re-calibration from the in-line script. In other words every-time after running a calibration, I have to hope that it doesn't crash.
    I am hoping that this is a minor problem and easy to solve. Do you have any ideas of what might be going on?

    Really appreciate it.

    cheers,
    Helio

  • Hi Helio,

    It seems that the horizontal variability couldn't be calculated due to a lack of incoming samples. In other words: while attempting to compute the precision of your calibration, no samples were available to do so (maybe due to a sub-optimal calibration or validation, or maybe because the participant looked away during the noise calibration?), and thus what was executed was None**2, which of course caused a crash.

    The assumption behind the code is that at least one sample would come in, which evidently isn't happening in some cases. The piece of offending code can be found here: https://github.com/esdalmaijer/PyGaze/blob/master/pygaze/_eyetracker/libtobii.py#L561 (lines 561-569 collect the samples, lines 572-578 compute the precision).

    Because the precision is only used for event detection (the algorithm takes into account the current level of noise, to prevent false positive saccade detection), it would seems sensible to fall back on defaults when the computations go awry.

    Now, I am not going to edit the file on GitHub, as I can't test whether my fix would work or not. However, if you would like to amend your local copy, here's how to change lines 572-578:

                Xvar, Yvar = [], []
                for i in range(2, len(sl)):
                    Xvar.append((sl[i][0] - sl[i - 1][0])**2)
                    Yvar.append((sl[i][1] - sl[i - 1][1])**2)
                if len(Xvar) == 0:
                    XRMS = 60.0
                else:
                    XRMS = (self._mean(Xvar))**0.5
                if len(Yvar) == 0:
                    YRMS = 90.0
                else:
                    YRMS = (self._mean(Yvar))**0.5
    self.pxdsttresh = (XRMS, YRMS)
    

    This would set the defaults to 60 pixels for the horizontal precision and 90 for the vertical precision. Again, this matters only if you're using any online event detection.

    Would you be able to try the suggested fix, and report back? It would be a great help to other Tobii users if we could confirm whether this solves your issue!

    Cheers,
    Edwin

    Thanked by 1heliocuve
  • Hi @Edwin,

    Thanks a lot for the detailed explanation. I will test this in a few hours and report back.

    Cheers,
    Hélio
  • hi @Edwin

    Just tested the fix and it does indeed work perfectly, thanks so much! I can now call the calibration at any point with no issue. One thing I have noticed tho (I have actually noticed this before, but never gave it much thought) is that on the calibration report, the distance between the participant and the screen is always equal to 57cm, doesn't matter the actual distance. I have actually tested different distances from the screen and the output report is always 57. Perhaps this is not a big deal, as long as it is calibrating at the correct distance, which I think it is, based on the initial screen to position the eyes, where the real time distance output seems to be sensitive to the object/subject.

    Cheers!

    Helio

  • Hi Helio,

    Thanks for confirming that! Glad it works :)

    Yes, the distance is a default. Unfortunately, most trackers don't estimate such a thing, and thus the algorithm has to fall back on a default. It doesn't actually impact its behaviour a lot, especially in the context of tracker noise.

    Cheers,
    Edwin

    Thanked by 1heliocuve
Sign In or Register to comment.