Jump to content

imarin18

Verified Members
  • Posts

    50
  • Joined

  • Last visited

Posts posted by imarin18

  1. On 4/7/2022 at 6:56 PM, imarin18 said:

    Dear  @HackPerception

    Have you ever seen the following issue before?

     

    I updated SR Runtime version to SRanipal Runtime (1.3.2.0) and checked this issue. I measured the same parameters as before, thought it seems that the device outputs different pupil data, whereas the time stamp is same. Please refer to the attached my data.

    image.png.4dc631fe521572edf5d8b0dd9f8c2080.png

     

    Could you please share the update regarding this issue?

    Thank you very much for the information you could provide.

    Best regards,

    imarin18

     

     

     

  2. On 12/3/2019 at 5:14 PM, Daniel_Y said:

    Thanks for your feedback. We noticed this issue and will be addressed in the next release.

    Dear @Daniel_Y,

     

    I updated SR Runtime version to SRanipal Runtime (1.3.2.0) and checked this issue. I measured the same parameters as before, thought it seems that the device outputs different pupil data, whereas the time stamp is same. Please refer to the attached my data.

    image.png.4dc631fe521572edf5d8b0dd9f8c2080.png

     

    Could you please share the update regarding this issue?

    Thank you very much for the information you could provide.

    Best regards,

    imarin18

     

     

  3. Dear @maple

    I suppose that you faced the situation possibly due to the following two reasons.

    1: Your computer does not have enough specification to get the data at 120Hz sampling rate. A computer with better specification could enable it to sample at 120Hz.

    2. If you look at only the initial samples (i.e. first 30 seconds after you start sampling), you will see lower sampling rate than 120Hz.

    The following article may be helpful for you to understand these points.

    https://doi.org/10.3389/fpsyt.2020.572938

    Best regards,

    imarin18

  4. Dear @jboss

    Thank you very much for your response.

    I think your understanding is correct. We need to remember that Unity playing does not always work along with eye tracking. In your script posted previously, you wrote the code below. This stops only the playing of Unity, not eye tracking. Thus, if you want to stop the eye tracking in parallel, one of the workarounds would be to use UnixTime (i.e. SaccadeEndTime) as a trigger to stop the eye tracking, as designed in the GitHub page: https://github.com/MotorControlLearning/SaccadeVR-mobile.

     if (Application.isPlaying)
            {
                Application.Quit();
            }

    Best regards,

    imarin18

  5. Dear @jboss

    The reason why you face the frozen Unity is that the eye tracker is still measureing the eye movements, while the process in void Update () is completed. As long as you continue to record the data of eye movements, Unity playing will not end. The GitHub page says as below.

    "Please be noted that you will see Unity seem to be frozen if you click the stop button on Unity for a specific case. Unity seems to be frozen in this situation because the sampling of eye tracking is still working on the background. As explained in the following algorithm flow chart, the sampling of eye tracking works independently from Unity. The playing of Unity is stopped automatically when all the saccade tasks are completed. We set the maximum sampling number of eye tracking to 120 Hz * 1800 seconds in line# 175: private const int maxframe_count = 120 * 1800; of C# script: Saccade_measure_rev1.cs. Therefore, if you click the stop button on Unity within maxframe_count time range, Unity seems frozen (actually not because the system still waits for the sampling of eye tracking to finish). On the other hand, if you click the stop button beyond maxframe_count time range, the playing of Unity stops immediately. The maximum number of maxframe_count can be adjusted accordingly." 

    If you adjust the value of private const int maxframe_count on the script according to your preference, I suppose you can avoid the frozen Unity.

    Best regards,
    imarin18 

  6. Dear @jboss

    What measurement parameter did you check for the interval? As posted in another thread, time_stamp parameter recorded by SRanipal SDK does not provide the value properly (HTC also recognises the issue). Otherwise, it would be better for you to try with another laptop that meets the requirements recommended by HTC (https://developer.vive.com/resources/vive-sense/hardware-guide/vive-pro-eye-specs-user-guide/).

    Best regards,
    imarin18

  7. Dear @jboss

    As the paper reported, the longer sampling interval of 16/17 ms would be due to the clock timing of your laptop. Or if you evaluated the sampling interval for the initial 30 seconds, it would be better to check the data over 30 seconds after you start the recording.

    According to the script provided in the paper, the recording continues in a while loop for a specific number of samples (see the line # 175) regardless of whether you click Play or not. Thus, the editor may have been frozen because the while loop was not completed.

    Best regards,
    imarin18

     

  8. Dear @prajaktakhandve

    As people have mentioned already, Unity FPS and sampling frequency of eye tracking should be handled and considered separtely. The eye callback function that HTC provides enables you to sample eye data at 120Hz, while FPS changes depending on the VR environment you design. It seems the following article will be of a good help for you.

    https://www.frontiersin.org/articles/10.3389/fpsyt.2020.572938/full

    • Like 1
  9. Dear @Asish and @shomik

    As @Corvus mentioned, we need to see Unity FPS and eye sampling seprately. These two parameters: frame rate and sampling frequency of eye tracker are indepedent from each other. For example, while the Unity FPS changes depending on the VR design and the computer specification (e.g. sometimes it is 50FPS and it changes to 100FPS at another time), the sampling frequency of eye tracker is basically consistent at a specific value. If you use the callback fucntion, the sampling frequency should be more or less at around 120Hz, whereas the Unity FPS may fluctuate. Specifically, while Unity Update() is running on one thread, Eye call back funciton is running on another thread.

    However, as I wrote in another thread (

    ), it seems that the current SRanipal SDK does not properly output the time stamp data. Thus, it may be difficult to evaluate the sampling interval or frequency of eye tracker correctly, using the time stamp data. I instead used DateTime.Now.Ticks property on C# and observed that the sampling frequency was more or less at around 120Hz.

    I hope this helps.

    Best regards,

    imarin18

  10. Dear @Daniel_Y

    I think I figured out the calculation of angle in degrees. We simply need to follow the concept of trigonometric functions, don't we? For example, if we want to calculate the angle of our eye movements in X direction, we just need to get the arc tangent from the data in X and Z directions.

    Could you please explain what 0 and 1 mean in the normalised pupil position in terms of angle in degrees?

    Best regards,

    imarin18

  11. Dear @Daniel_Y

     

    Thank you very much for your reply and the information. First of all, I made a wrong description in my previous post. I was supposed to write "Data in degrees assuming that the normalised data are between -pi and pi.", not "Data in degrees assuming that the normalised data are between -pi/2 and pi/2."

     

    Could you please explain how the device normalises the gaze direction data? For example, what is the situation when the gaze direction on x-axis is 1?

    According to the technical specification, the trackable field of view of this headset is 110 degrees. I reckon that -1 of the gaze direction data means -55 degrees and 1 means 55 degrees. Is my understanding correct?

    I check the pupil position as well. Could you please explain the configuration of pupil position as well? Does 0 mean -55 degrees and 1 mean 55 degrees?

     

    Thank you very much for the information you could provide.

     

    Best regards,

    imarin18

  12. Dear @Daniel_Y

    Thank you very much for your reply and the information.

    According to the data from my measurement, the gaze direction data are not in the range between 0 and 1 as shown in the figure below. The data even have negative values. In my measurement, I intentionally moved my eyes at +/-8 degrees from the central point. Assuming that the data were normalised between -pi/2 and pi/2, I calculated the degrees and found the subsequent figure, showing that my eyes moved to +/-8 degrees as expected.

    I'm sorry to ask you again and I may be still wrong, but could you please double confirm the configuration?

     

    Normalised data in my measurement.

    image.png.44c09eac15483f59f1bbefada265aa99.png

     

    Data in degrees assuming that the normalised data are between -pi/2 and pi/2.

    image.png.d9c70e90db5ac327005069e25fe4a9d2.png

     

     

    As for the normalised pupil position, do you mean the position from the direction of the VR headset?

     

    Thank you very much for your support and the information you could provide.

    Best regards,

    imarin18

  13. Dear @alwyuyang

    Just to clarify again, I am not sure if my understanding is correct. According to your result, it looks that the validity value outputs 8 despite that you don't have any values for the measurement parameters. Have you tried to get the data while you are closeing your eyes completely and look at the validity data?

    My personal opinion is that it would be better to use only the data with 31 on the validity data.

    Best regards,

    imarin18

  14. Dear @alwyuyang

    I suppose that the technical support team meant that the huge gap from 62613 to 4205382 in timestamp data would be also a part of improvement.

    I'm not sure exactly about what you meant by "when it failed to measure", but when you get 8 in your validity data, I reckon that you have the valid data only for eye openness (SINGLE_EYE_DATA_EYE_OPENNESS_VALIDITY) having the value of 8 and the other four parameters have the value of 0, meaning that the four are not valid.

    Best regards,

    imarin18

     

  15. Dear @alwyuyang

    As explained in the following post, the timestamp cannot be correctly measured with the current SDK version according to the technical support team.

     

    If I understand correctly, I reckon that the value of validity follows the table below. If you sum all the decimal digits (1+2+4+8+16), you get 31. Though again I am not sure if my understanding is correct.

    Enumerator

    Binary digit if valid

    Decimal digit if valid

    SINGLE_EYE_DATA_GAZE_ORIGIN_VALIDITY

    00001

    1

    SINGLE_EYE_DATA_GAZE_DIRECTION_VALIDITY

    00010

    2

    SINGLE_EYE_DATA_PUPIL_DIAMETER_VALIDITY

    00100

    4

    SINGLE_EYE_DATA_EYE_OPENNESS_VALIDITY

    01000

    8

    SINGLE_EYE_DATA_PUPIL_POSITION_IN_SENSOR_AREA_VALIDITY

    10000

    16

     

    Best regards,

    imarin18

  16. Dear @kbombeke

     

    I observed the similar situation previously. I recommend using the information of eye validity first.

     

    image.png.72efad528c0d1ca7315996383c5f1480.png

     

    image.png.a408ceaf16047e736ba89c2354cf653e.png

     

    If I understand correctly, the following shows how it works, though I am not sure if this is correct.

    Enumerator

    Binary digit if valid

    Decimal digit if valid

    SINGLE_EYE_DATA_GAZE_ORIGIN_VALIDITY

    00001

    1

    SINGLE_EYE_DATA_GAZE_DIRECTION_VALIDITY

    00010

    2

    SINGLE_EYE_DATA_PUPIL_DIAMETER_VALIDITY

    00100

    4

    SINGLE_EYE_DATA_EYE_OPENNESS_VALIDITY

    01000

    8

    SINGLE_EYE_DATA_PUPIL_POSITION_IN_SENSOR_AREA_VALIDITY

    10000

    16

     

     

    I hope this helps.

     

    Best regards,

    imarin18

     

×
×
  • Create New...