Using a Pi as a Photo Finish Camera

[hogwam]

I am a complete newbie so please excuse my ignorance in advance!

Looking for a bit of advice on a subject that from a lot of googling doesn't seem to have been done (in public, anyway).

I want to create a photo finish camera, based on a Pi, as described here:
http://inrng.com/2012/04/photo-finish-camera/

There are several products out there, but costing over £10000+ each, they are mighty expensive!
So you can see why I'd be interested in investing some time in developing a Pi solution, even if it's not accurate to 1/10000th/sec!
Then linking that to a DSLR (for best optics) or even a domestic digital video camera.

Can anyone give me a few pointers as to how and where to begin?

[jamesh]

Use the Pi camera - should be a new batch available soon. Resolution will be good enough (5MP or 1080p30), and easier to interface than other sorts of camera.

[hogwam]

As the distance to the finish line from where the camera is sighted can be over a few metres, I'd need zoomable optics.
Unless there is an optical zoom add-on for the Pi camera.... that would be very nice

[mahjongg]

The question is whether the PICAM can make a photo quick enough after a trigger (connected to a GPIO).
I don't think so, it seems it needs a long time before the shot is actually made!
Perhaps filming the finish would be better, and using the trigger to somehow mark the finish moment.
Another way would be to simply put a LED in view triggered by the finish moment.

[hogwam]

Should have perhaps mentioned.... this is for motorsport use and the passing at finish line would be in excess of 70mph so we need something as fast as possible. Even video at 60fps can sometimes be too slow.

What the expensive systems do is have a time sync with a GPS clock and look for changes in the previous image.
If there are no changes, drop the frame captured. If there are changes, log that frame (or specifically, a small line of that frame) and splice it together with the next detected frame and so on. Frames logged are time-stamped with the GPS time down to 1/1000th of a second.
So all the useless frames are discarded, thus not needing to store 60,000 frames per minute of the race.

[jamesh]

I think you just explained well why the systems cost $10k...requires fast frame capture, fast interframe processing, and fast reactions!

[PiGraham]

Is the Pi hardware capable of windowed readout? Some CMOS sensors can scan only a small ROI ar proportionately higher frame rates. If a Pi could produce video from, say 1k x 100 pixel ROI high frame rates might be possible.

[hogwam]

Exactly!

I'd imagine that using a raw bitmap of the image (which doesn't have to be megapixel quality really) it captures the centre column of pixels and ignores all others, thus getting the data being handled down to quite a small amount.

But before you get to that stage you have to line up the camera, zoom & focus the lens (manually), have it talk to the Pi (without camera going to sleep!), output a constant stream of what the camera 'sees' and have the Pi capture the central column of pixels.
Then once the column we are interested in is there, dump that somewhere then have a software splice it back together in the correct order - the software of course doesn't have to be on the Pi, but could perhaps connect to it via Ethernet to get that data

[tenochtitlanuk]

I started on something similar & then was hung up waiting for the camera. See http://www.raspberrypi.org/phpBB3/viewt ... 29#p297329
The camera happily takes long narrow horizontal images. ( I turn the camera 90 degrees to make this sensible) & ImageMagick happily appends these images to give a y/t image, ie showing what is actually ON the finish line as a function of time. I haven't tried it yet on any fast events however, although the camera looks to be happy at high frame speeds...
Your post reminds me to get back to it now I've got the camera running... not sure if my Python is up to it..

[PiGraham]

Don't get too excited. Windowed readout may not be possible on the Pi camera, it isn't important for what the camera is designed to do.Even if it's possible, it isn't likely to be something the foundation are going to devote resources to anytime soon.

There are cameras around that do windowed readout for less than $10K, but they are a LOT more expensive than a Pi + Cam.

One approach to this is to use a linescan camera. The motion of the cars past a single row of pixels builds up an image as they cross the line.

Here's a "cheap" linescan camera:
http://www.mightexsystems.com/family_in ... ries_id=92

2048 pixels, 3,300 lines per second. I'm not sure if it can sustain that rate. The data mentions a 64 frame buffer.

This is moving off topic for RasPi.

[jamesh]

As far as I know, the max frame rate of the Raspi camera is 90fps in, I think, VGA. I don't think it can window and go higher than that.

And at the moment, I haven't got the camera working above 30fps at all.

[PiGraham]

I've a datasheet that says it will do 320 x 240 @ 120 fps

I expect there a few science teachers out there, among others, who could make use of that.

It also seems the sensor can be windowed but it makes no difference to timing.

[jamesh]

I've a datasheet that says it will do 320 x 240 @ 120 fps

I expect there a few science teachers out there, among others, who could make use of that.

It also seems the sensor can be windowed but it makes no difference to timing.

The datasheet is wrong I'm afraid. According to the Omnivision engineer I spoke to, 90 is the max.

[PiGraham]

The datasheet is wrong I'm afraid. According to the Omnivision engineer I spoke to, 90 is the max.

Oh well, never mind.

[ahmedj]

I started on something similar & then was hung up waiting for the camera. See http://www.raspberrypi.org/phpBB3/viewt ... 29#p297329
The camera happily takes long narrow horizontal images. ( I turn the camera 90 degrees to make this sensible) & ImageMagick happily appends these images to give a y/t image, ie showing what is actually ON the finish line as a function of time. I haven't tried it yet on any fast events however, although the camera looks to be happy at high frame speeds...
Your post reminds me to get back to it now I've got the camera running... not sure if my Python is up to it..

I'm looking into putting together a finish line camera for my daughter's athletics club, so was wondering if you could help with a few queries I have
- what sort of frame rates were you able to acheive with the PICAM
- were you able to use the standard functions : raspistill and raspivid or did you have to write some yourself

Could I use the type A board for this or should I stick with the B?

[Spinnaker]

I'm looking at doing the same kind of thing but on a smaller scale for a scouts Pinewood Derby.
The PiCam will be fine for my application but I am trying to get it to interface with a finish line sensor which will stop the recording, rewind the previous 4 seconds then the last 0.5 seconds in slow motion twice.

[PiGraham]

You could use IR gate sensors like these to detect when the finish line is crossed.
It will be no use for precise timing, but it should do for a video replay of free-running video of the finish.
Relay output is easy to connect to the GPIO.
I got a couple of these and tried them out triggering my DSLR (Canon 350D) through the shutter release socket.
They need 12 - 24V so I connected them to two 9V batteries in series (get some wire-ended battery clips).
The beam is modulated and filtered and seems quite immune to sunlight and showerproof.

I would suggest setting the beam a few seconds before the finish line (3 seconds, say) and set a script to start raspivid recording for, say, 6 seconds. Once raspivid returns call mplayer (or other) to play the clip with repeat and slow speed.

Code: Select all

mplayer -speed NUMBER file.ext

NUMBER < 0.01 - 100

Something like: (Untested!)

Code: Select all

    #!/bin/bash
    #AF
    gpio mode 3 in
    while :
    do
       TRIG=`gpio read 3`
       if [[ $TRIG == 1 ]]
       then
         #echo "Triggered"
         raspivid -o finish.h264 -t 8
         mplayer -speed 0.25 finish.h264
         mplayer -speed 0.25 finish.h264
         exit
       fi
    done

You run a risk that 30 frames per second may not happen to catch the exact line crossing, but for a school / scouts race it should do.

You could use twi sensor beams, one to start recording and the other to measure the approximate time to crossing the line, so that you can replay a shorter part of the clip with some confidence that it will show the key moments.

I suggest you include a replay button that re-runs the full recording, if required.

The good thing is it's really quick and cheap to try out.

[radaudio]

Dear All,

I am interested in building something similar to what PiGraham suggests. Unfortunately the link to gate sensors seems dead. Would anyone happen to know a good replacement?

Cheers,

Greg