| Reference | Downloads | Github

Move picture at specified speed

Hi all,

So I’m trying to program a new version of an experiment where people will observe an object (a picture of a box) moving in one direction (from left to right) behind an occluder at different speeds. The tricky thing is setting the different speeds of the movement.
I have already collected data from participants who moved the object, and would like to use their data (the movement of the box on x axis + time stamp) to set the different speeds of the movement that participants will see in my new experiment. So basically I would like to use the movement parameters from a previous participant (two movement parameters: movement on x axis and time) to create stimuli showing movements at different speeds. I suppose that I could create a loop that goes through every value of x-axis and time from the data I collected and use it to update the location of the box in every frame? Or maybe there’s a better way of doing this?



Sounds about right. Practically, you might find it easier to just work through the list at one entry per frame (assuming it was gathered the same way), rather than introduce the complication of dealing with the time value. i.e. it will be much easier to deal with a progression of discrete values than deal with indexing them by a continuous time value, which won’t be exactly in sync with the time when your code runs, so you’d have to have some way of selecting items by minimising deviation between the recorded time values and the current time.

That’s assuming that you want to (almost) exactly mimic given trajectories, rather than parameterise the trajectory as a function of time, and just calculate the position analytically at any given time.

Thanks @Michael. The experiment is now working. However, I am trying to add a keyboard component to the end of the trial, so that participants can press one key (space) once they see the picture hiding behind the occluder. But when I do this, both the picture and the occluder disappear, and they only appear very rapidly (I think for one frame) when I press on space. My question is, how can I add the keyboard component at the end of the trial, once the box moves behind the occluder, and prevent these two from disappearing? Also, is there a way I can fix both the occluder and the box to their ‘final’ location (the last value on the Excel file) so that they remain there until a key is pressed?


Ok. I managed to find a solution: I created a new trial at the end of the experiment called ‘answer’ with the (static) image of the occluder, and added the key component in there. Now that the key component is not within same trial than the animated box, it works.

Oh, I forgot one thing @Michael. For some reason the transition between the trial with the animated box and the answer trial is too long (once the box goes behind the occluder, it takes aprox. 3 to 4 secs for the text from the answer trial ‘Press Space’ to appear). When looking at the Excel file that I get as an output once I finish the experiment, it looks like Psychopy keeps updating the location of the box for a long time (aprox 3 secs), but with a value of ‘None’. It basically looks like this:

Is there any way of avoiding this repetition of ‘None’ values?


Not to butt in on the discussion, but it sounds like you actually wanted everything to be in one trial, including the keyboard component. It’s just that you want the keyboard component to be activated/allow responses only after a certain amount of time has passed after the start of the trial, right? If so, you should probably use an if statement like “once the trial clock has reached >x number of seconds: activate keyboard”. Do you use the Builder View at all? If so, you could try creating a simple experiment with just one trial, where a polygon is shown and there is a keyboard component that’s set to activate after 5s. Then you can use the “compile script” button to see what code the Builder produces, scroll down, and see how the Builder does keyboard component control. Finally, you could use the produced code as a template for solving the issue you’re running into in your actual experiment.

That is, if I’m understanding correctly what functionality it is you’re after.

I don’t understand what’s going on with picture and occluder disappearing when you add your keyboard component - maybe trying to put together something similar to what you want in the Builder and see what code it produces would be informative for this also?

Hope this helps!

An update on this: As mentioned previously, I am running an experiment in which the location of a picture (ImageStim) is updated on every frame, using a (previously collected) list of x values.
I’ve been looking closely at how the movements look like when reproduced using this list of values, and for some reason they seem to look faster and less ‘jittery’ than the actual movements. (I’ve made a video recording of my screen when executing the movements myself, and then reproducing them using the collected values, and compared the two videos). I wonder whether this has to do with the way I’m implementing the update of the image (it’s supposed to update the location in every frame). This is the part of the code that I’m using to update the location of the image (a box):

        # *box* updates
        if t >= 0.0 and box.status == NOT_STARTED:
            # keep track of start time/frame for later
            box.tStart = t  # not accounting for scr refresh
            box.frameNStart = frameN  # exact frame index
            win.timeOnFlip(box, 'tStartRefresh')  # time at next scr refresh
        if box.status == STARTED and frameN >= (box.frameNStart + 1):
            # keep track of stop time/frame for later
            box.tStop = t  # not accounting for scr refresh
            box.frameNStop = frameN  # exact frame index
            win.timeOnFlip(box, 'tStopRefresh')  # time at next scr refresh
        if trials_1.thisRepN == 0:  # only update if drawing
            box.setPos([x_loc, 0.2], log=False) #x_loc is the list of values

Any idea why the x_loc values are being updated faster than when I actually produced the movements? Is this normal?