I am a cognitive psychologist / neuroscientist. In a lot of the experiments that I run I have participants - mostly undergrads - sit at a computer and respond to certain combinations of visual stimuli. The visual stimuli are generally pretty simple and are not created 'online' (ie. screen images are created and stored as pixmaps).

I'm considering trying out a Raspberry pi to run experiments. My tentative plan is to run linux and code experiments in python.

My main worry about using the Pi is that it might not have accurate enough timing for this application. I need to know with fairly high precision exactly when a stimulus was presented to the screen (eg. when the gun fires for the top-left pixel in a CRT monitor). When I call for a stimulus to be presented to the screen, will the delay between this call and the beginning of the draw sequence on the monitor be any more than I experience on my current entry-level Dell/HPs? Similarly, when someone presses a button on a keyboard / mouse, will the Pi be able to record the latency of this response with high precision?

If the Pi introduces more than about 5 or 8 ms. of variability, then it won't be suitable for this application. Static timing delays are much less of a problem... if a call to draw a stimulus always takes 10 ms. before it's on the video buffer, I can correct for this after the fact.

Has anyone used a Pi for something like this? Can anyone comment on the Pi's timing in this sort of context?

Many thanks for any help or comments!

  • Those critical timing elements what range are we talking about? Seconds, milliseconds, micro, nano?
    – ikku
    Jan 18 '13 at 14:39
  • Hi ikku, I modified the question quite to make it more specific. Thanks for your help.
    – appositive
    Jan 21 '13 at 21:40

Assuming that milliseconds is a fine enough resolutions for this type of experiments, I remember from driving theory books that they assume a human reaction time (eye/hand) between 200 and 500 milliseconds.

In this range of time, the RPi will for sure be fast enough to record the output versus input.

I have no idea what type of systems (hardware) + operating system you are using at the moment and what the maximum error in a time sample/stamp might be (because of kernel context switches, meaning other active tasks), but unless there is some special hardware in use for the current systems, I think you can safely get the same results using the RPi.

Precise timing is used in RPi projects for ultrasonic distance measurements, they seem to work fine on the Raspberry Pi and the times there are in the range of microseconds.

  • A follow up: What I need is to be sure that the time stamp for the beginning of a screen refresh is accurate to about 5 ms resolution. The same for a mouse or keyboard response. Static delays - offsets in recorded time from actual time - are fine, but random variability beyond 5 ms. is a problem. does this sound problematic?
    – appositive
    Jan 18 '13 at 15:55
  • What screen refresh are you talking about? The one that CTR displays use with their electron beams to repaint the total picture on screen, or the frame rate which data is sent out, or the time between between a command like 'put picture on screen' and the time it is actually shown. I think all will be within the 5ms (but test it to be sure). The first is going to be tricky because you're planning to use external HDMI to VGA converters to the actual VGA signal is not generated in the RPi.
    – ikku
    Jan 18 '13 at 19:34
  • Ikku, I put more details in the original post. Your comment on the video converter is a very good point... on second thought I'll try to find (slightly-newer-but-still-cheap) DVI-input monitors and buy HDMI-to-DVI cables to connect with the Pi.
    – appositive
    Jan 21 '13 at 21:42

I posted a similar question on the cogsci SE and answered it myself after playing with the RPi a bit... that text is below.

So I've had a chance to try out the RPi for this purpose. Short answer: it works great (with some limitations).

The RPi does not support OpenGL. I approached this system with the idea of using a python environment to create and present experiments. There are two good options for this that I know of, opensesame and psychopy. Psychopy requires an OpenGL python backend (pyglet), so it won't run on the Rpi. Opensesame gives you the option of using the same backend as PsychoPy uses but has other options, one of which does not rely on openGL (based on pygames). This 'legacy' backend works just fine. But the absence of openGL means that graphics rely solely on the 700 mHz CPU, which quickly gets overloaded with any sort of rapidly changing visual stimuli (ie. flowing gabors, video, etc.).

The RPi does have a very good video card (for a $25 computer) that supports OpenGL ES. Riverbank software provides python bindings for OpenGL ES (pogles), so there is the possibility for hardware acceleration in python. This has not currently been implemented on PsychoPy or Opensesame. It probably won't happen anytime soon, because there is currently an additional limitation on this system: there's no way to use OpenGL ES in the linux windowing environment (xwindows). This will probably be developed in the medium-term. But currently even a lightweight version of xwindows on the RPi is noticeably clunky and slow (overclocking the CPU helps with this). OpenGL can be used on the Pi through CPU emulation (via Mesa)... but this so heavily overloads the CPU that it's effectively useless.

So the RPi is not well suited for displaying rapidly changing visual stimuli (ie. flowing gabors, video). And PsychoPy effectively doesn't run. But Opensesame runs fine with the non-openGL 'legacy' backend. For a manual RT experiment involving the presentation of static images, this setup running on the Pi will have much the same timing resolution as the same setup running on any other computer.

And it will get better, probably pretty quickly. OpenGL ES support in xwindows should come pretty quick, and once this is available it will be possible to use OpenGL ES python bindings currently under development to make backends for PsychoPy and OpenSesame. These will support fluid moving stimuli and video, and free up the CPU for other tasks. My personal hope is that this will free enough resources to allow the RPi to interface with other systems... like an eye-tracker computer or an eeg amp.

But for now it seems just fine for basic no-video psychophysics. And it's very, very cheap... even factoring in the cost of a small DVI monitor you should be able to get a data collection system up and running for less than 100 euro.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.