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

Comments

• eduard

  December 2018

  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

  
• heliocuve

  December 2018

  Hi Eduard,

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

  Helio
• Edwin

  December 2018

  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?
• heliocuve

  December 2018

  @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
• Edwin

  December 2018

  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
• heliocuve

  January 2019 edited January 2019

  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
• heliocuve

  January 2019

  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
• Edwin

  January 2019

  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
• heliocuve

  January 2019

  Hi @Edwin,
  
  Thanks a lot for the detailed explanation. I will test this in a few hours and report back.
  
  Cheers,
  Hélio
• heliocuve

  January 2019

  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
• Edwin

  January 2019

  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