By aquirk - 4/27/2017
I'm using the existing pursuit rotor task script and I want to keep the original parameters but increase the number of rotations, so the ball spins around the circle 10 times (so, increase num_rev from 1 to 10). I've noticed that each time I do this, the program gets worse and worse at identifying where my mouse is relative to the ball. By the 4th or 5th rotation, the color begins changing when my mouse isn't on the circle, and the more rotations that pass, the worse this discrepancy gets.
Any ideas why this is happening, or how I can ensure multiple revolutions without this weird bug? I've tried playing with the "variables that interact" values, but regardless of speed/movingtimeadjust/anything, this pattern keeps happening.
|
By Dave - 4/27/2017
+xI'm using the existing pursuit rotor task script and I want to keep the original parameters but increase the number of rotations, so the ball spins around the circle 10 times (so, increase num_rev from 1 to 10). I've noticed that each time I do this, the program gets worse and worse at identifying where my mouse is relative to the ball. By the 4th or 5th rotation, the color begins changing when my mouse isn't on the circle, and the more rotations that pass, the worse this discrepancy gets. Any ideas why this is happening, or how I can ensure multiple revolutions without this weird bug? I've tried playing with the "variables that interact" values, but regardless of speed/movingtimeadjust/anything, this pattern keeps happening.
This essentially means the parameters aren't tuned finely enough for your particular system. The inaccuracies will add up with each rotation until you get a noticeable "drift" as the calculations accumulate error and are significantly "off".
Have you gone through the steps outlined in the script, i.e.
Fine-tune for your computer:
(1) Run the script with speed = 40; num_pos = 360; and movingtimeadjust = 0
(2) Then check values.mean_truetrialduration for your computer (summary data file). This is roughly
the minimum duration trial.movingtarget needs on YOUR computer.
Now compare it to expressions.requiredmovingtargetspeed (summary data file).
IMPORTANT: Your combined settings of speed and Num_pos should NOT produce a a required movingtargetspeed
that is faster than your values.mean_truetrialduration.
(3) Find a combination of your desired speed and Num_pos for your computer that produces a required targetspeed
that is as close as possible to your determined values.mean_truetrialduration
(4) If you have a combination of speed and Num_pos that produces a required targetspeed that is
as slow or slower than your values.mean_truetrialduration, then fine-tune
values.movingtimeadjust until values.accept = 'yes'.
If so, which values have you determined based on that?
|
By aquirk - 4/27/2017
+x+xI'm using the existing pursuit rotor task script and I want to keep the original parameters but increase the number of rotations, so the ball spins around the circle 10 times (so, increase num_rev from 1 to 10). I've noticed that each time I do this, the program gets worse and worse at identifying where my mouse is relative to the ball. By the 4th or 5th rotation, the color begins changing when my mouse isn't on the circle, and the more rotations that pass, the worse this discrepancy gets. Any ideas why this is happening, or how I can ensure multiple revolutions without this weird bug? I've tried playing with the "variables that interact" values, but regardless of speed/movingtimeadjust/anything, this pattern keeps happening. This essentially means the parameters aren't tuned finely enough for your particular system. The inaccuracies will add up with each rotation until you get a noticeable "drift" as the calculations accumulate error and are significantly "off". Have you gone through the steps outlined in the script, i.e. Fine-tune for your computer: (1) Run the script with speed = 40; num_pos = 360; and movingtimeadjust = 0 (2) Then check values.mean_truetrialduration for your computer (summary data file). This is roughly the minimum duration trial.movingtarget needs on YOUR computer. Now compare it to expressions.requiredmovingtargetspeed (summary data file). IMPORTANT: Your combined settings of speed and Num_pos should NOT produce a a required movingtargetspeed that is faster than your values.mean_truetrialduration. (3) Find a combination of your desired speed and Num_pos for your computer that produces a required targetspeed that is as close as possible to your determined values.mean_truetrialduration (4) If you have a combination of speed and Num_pos that produces a required targetspeed that is as slow or slower than your values.mean_truetrialduration, then fine-tune values.movingtimeadjust until values.accept = 'yes'. If so, which values have you determined based on that?
Yes, I played around with that a lot, and the best I could get was speed=10 and num_pos=300. This gave a value for expressions.requiredmovingtargetspeed of 20, and for values.mean_truetrialduration of 20.28859 (values.accept=yes).
The color changing works perfectly with these settings for the first 3-4 rotations, as I said, but then gets more and more off with the subsequent rotations, until you actually cannot get the circle to change color unless your mouse is fully in front of it, not actually touching the circle at all.
|
By Dave - 4/27/2017
+x+x+xI'm using the existing pursuit rotor task script and I want to keep the original parameters but increase the number of rotations, so the ball spins around the circle 10 times (so, increase num_rev from 1 to 10). I've noticed that each time I do this, the program gets worse and worse at identifying where my mouse is relative to the ball. By the 4th or 5th rotation, the color begins changing when my mouse isn't on the circle, and the more rotations that pass, the worse this discrepancy gets. Any ideas why this is happening, or how I can ensure multiple revolutions without this weird bug? I've tried playing with the "variables that interact" values, but regardless of speed/movingtimeadjust/anything, this pattern keeps happening. This essentially means the parameters aren't tuned finely enough for your particular system. The inaccuracies will add up with each rotation until you get a noticeable "drift" as the calculations accumulate error and are significantly "off". Have you gone through the steps outlined in the script, i.e. Fine-tune for your computer: (1) Run the script with speed = 40; num_pos = 360; and movingtimeadjust = 0 (2) Then check values.mean_truetrialduration for your computer (summary data file). This is roughly the minimum duration trial.movingtarget needs on YOUR computer. Now compare it to expressions.requiredmovingtargetspeed (summary data file). IMPORTANT: Your combined settings of speed and Num_pos should NOT produce a a required movingtargetspeed that is faster than your values.mean_truetrialduration. (3) Find a combination of your desired speed and Num_pos for your computer that produces a required targetspeed that is as close as possible to your determined values.mean_truetrialduration (4) If you have a combination of speed and Num_pos that produces a required targetspeed that is as slow or slower than your values.mean_truetrialduration, then fine-tune values.movingtimeadjust until values.accept = 'yes'. If so, which values have you determined based on that? Yes, I played around with that a lot, and the best I could get was speed=10 and num_pos=300. This gave a value for expressions.requiredmovingtargetspeed of 20, and for values.mean_truetrialduration of 20.28859 (values.accept=yes). The color changing works perfectly with these settings for the first 3-4 rotations, as I said, but then gets more and more off with the subsequent rotations, until you actually cannot get the circle to change color unless your mouse is fully in front of it, not actually touching the circle at all.
Yes, even small error will eventually add up and cause a growing, increasingly noticeable disparity as error accumulates with every additional rotation step. Not sure how to optimize this away, to be honest, it will not be possible to get rid of entirely. The fewer rotations per round, the less error you'll accumulate, so perhaps keeping the number of rotations relatively low (3 to 4) and instead increasing the number of test rounds (values.Num_tests) is an option?
|
|