--> The more important criteria is precision of the camera motion <--
(1) Camera positioning is not as critical.
(2) Timing of the shutter is not as critical.
(3) I have full control of the on-screen moving objects through my software, so I can automatically reposition the moving object to be in front of the moving camera lens (via feedback mechansim if needed), or use a larger area or multiple copies of on-screen moving objects, so that it doesn't matter what part of the screen the camera is pointed at.
The job is capturing motion blur behaviours in exactly the same way as eye-tracking effects.
Shutter latency randomness is not as big an issue as thought.
The shutter can be electronically held halfway down (shutter button modification) so that shutter lag becomes more predictble.
Error of shutterlag +/- 200milliseconds is acceptable, because I have control of other variables.
As long as the rail is long enough that the shutter will probably occur while the camera is in steady motion, it will work.
At 250mm/sec, that's 25mm per 1/10sec. The rail can even be just 500mm long, with 200mm acceleration, 250mm section of smooth-coast (picture taking section), and 50mm of deceleration. Then we have a safety margin for shutter lag of +/- 500 milliseconds. See? Shutter lag isn't important, even for a short rail.
Many compact cameras have a very small error in shutter lag if I do the half-press first
To the camera's perspective, the moving camera in front of a moving on-screen object, the on-screen object is more-or-less stationary to the camera (barring various effects such as sample-and-hold (eye-tracking, pixel persistence, etc) motion blur, etc.) So there's a big window of opportunity for the shutter to open for 1/10sec, sooner or later.
--> The more important criteria is precision of the camera motion, perfectly tracking the on-screen object <--
This rig needs to use a screwmount, so it can use almost any camera.
It shall not be camera specific.
My favourite mechanism is the cogwheel belt (used by inkjet printers). Using cogwheel belts, and precise motor control on the cogwheel driving the cogwheel belt, inkjet printers move cartridges at over 1 meters/second with near-perfect accuracy (submillimeter precision). How do they spray a dot at an exact location otherwise; it's rather impressive how accurate inkjet heads are even at 1 meter per second movement. So let's use the same cogwheel belts that these printers use (but with variable speed, and good speed feedback for dynamic speed adjustment). Although the design goal is 250mm/sec, I will give an additional bonus money to a mechanism that can move accurately at 500-700mm/sec (for a mass of a compact camera), since that means I can test moving objects on 60" HDTV's with moving objects moving at 960 pixels per second. This may mean the rail needs to be 1 meter long, to allow sufficient acceleration.
Although it can be targeted at a favourite camera, the rail ultimately shall not be camera specific. Rail must be tripod-screw mount (that tiny screw hole at the bottom of all cameras), and permit experimentation with all sorts of different cameras. Smart electronic feedback motor speed control, to adapt to any mass, up to a limit. Faster adjustable coast speed achievable for smaller/compact cameras, slower adjustable coast speed achievable for larger/SLR cameras.
Ideally, this is what I want:
- I type in the display screen's DPI into my own software
- My own software displays moving objects
- My own software calculates the speed your camera needs to move it at.
- Via a serial command over USB cable, my own software commands your Arduino-powered camera rail to start moving now at a precise speed.
- You can even leave the shutter operation details to me. Just move the camera precisely for long enough (e.g. move accurately to my own specifications for 1 full second).
If necessary to achieve 1mm/sec accuracy, linearity differences (e.g. belt stretch, etc) can be cancelled out using a separate calibration pass and an appropriate multiplier to compensate (calibration details TBD). (This may not even be necessary, if you find a good metric cogwheel belt and a good metric cogwheel, etc.)
My software will handle triggers and calibration of timings (e.g. calibration for latency of acceleration, calibration for shutter lag, shutter trigger, etc). Ideally, you are responsible for the design of the mechanical operation and the ability to accept serial commands over the Arduino's USB/serial bus, to command the rail to begin accelerating to a precise speed, and then keep maintaining the speed for at least 1 second at 250mm/sec. Leave the rest of the details to me.
BONUS FEATURE: Ideally, I'd like your Arduino rig to give me continuous feedback (over serial) of the camera's current approximate position (+/- 1cm) relative to start position. This can be easily implemented by giving me motor-rotation speed feedback, which can be translated to cog-gear-count on the cogwheel-belt. Quite very doable. That way, I can synchronize my on-screen moving object to the position of the moving camera. And also know when acceleration is finished and the camera is in steady motion (this becomes my shutter trigger). Your job is to keep the camera moving at a steady speed for as long as you can.
Preferably, the rig needs to be strong enough to be portable, since I'll want to travel with it, and put it on all sorts of table tops, in front of all kinds of displays, of all kinds of brands/models/sizes.
Yes, pictures of construction is a bonus. Parts should be parts purchaseable from online stores, if possible. (I can buy the parts for you, shipped to your address). Scavenging is acceptable, but this is an open-source project that will be published online, and it needs to be easily reproduced & replicatable by other people. Therefore, a list of links to online purchases for every component in the project, is ideal, if preferred.
I currently have a strong contender of a person who has given me a resume & credentials (webpages of existing projects), with a price quote within my budget. If you want to apply to do this creation, please email me a 1-page (or more) email message explaining your proposal and your pre-existing experience (resume and web pages with proof of your electronics abilities) -- email mark[at]scanningbacklight.com ... Submissions are still being accepted till December 7th.