Go Down

Topic: Wanted: Build desktop device that moves a camera at a precise speed [$$ for you] (Read 2 times) previous topic - next topic


--> 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:
1. I type in the display screen's DPI into my own software
2. My own software displays moving objects
3. My own software calculates the speed your camera needs to move it at.
4. Via a serial command over USB cable, my own software commands your Arduino-powered camera rail to start moving now at a precise speed.
5. 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.


So the location of the camera when the shutter fires is not that important, it's the RATE of travel that matters, and that has to be constant within some limits?

(3) I have full control of the moving object, so I can automatically reposition the moving object to be in front of the lens.

How you do that with all the above variables I don't know but I believe you :)

Rob Gray aka the GRAYnomad www.robgray.com


So the location of the camera when the shutter fires is not that important, it's the RATE of travel that matters, and that has to be constant within some limits?
Correct.  The rate (including consistency & non-variability) is critical.

(3) I have full control of the moving object, so I can automatically reposition the moving object to be in front of the lens.

How you do that with all the above variables I don't know but I believe you :)
It's moving objects on a screen, completely generated by software, and the same software program can also be directly connected to the Arduino moving-camera rail via a USB cable.  The software becomes all-knowing if it controls the moving objects and it also controls the Arduino camera rail.  There are many techniques that I can do, such as:

(1) (if theres no feedback) Cover the entire screen with several copies of on-screen moving test-pattern.  The test-pattern can be full-screen, so it no longer matters where/when the camera starts moving -- the camera will "scroll" along with the horizontally-scrolling test pattern, and take a picture anytime before the camera reaches the edge of the screen.


(2) (if there's feedback)  I'd simply physically position the left end of the rig precisely at the left edge of the screen, and manually position the camera at on-screen target "X" displayed by my software program on the left edge of the screen.  Then when everything's set up, I click a button -- and the software triggers the camera to start accelerating....  You transmit position feedback over the USB cable (notch count on cogwheel = notches sent down the cogwheel belt, converted to millimeters in linear distance).  Then once the camera has finished accelerated to a specific speed (e.g. 960 pixels per second at the monitor's dpi -- see below for calculations)  My software immediately ensures a moving object in front of the lens based on last-known positional information (+/- 1-2cm inaccuracy is okay -- it just simply means the object is not perfectly centered).  Trigger the camera shutter.  Viola!  The Arduino rail just needs to continuously transmit me motor rotation or position info in real-time over USB, I can do/calculate the rest based on a known "home" position (e.g. setting up the rig in front of a screen in front of an on-screen "X" marker).

How do I know where to put the moving object on the screen?   You'll see that I'll position the rig in front of a displayed "X" on the screen.   Knowing the dot pitch of the monitor is important to me, but that's my job.  For example 960 pixels on a monitor at 0.25mm pitch, is 240 millimeters long.   My standard test patterns are moving at 960 pixels per second.  So to determine the necessary camera movement speed, I know the resolution of the display (e.g. 1920x1080p), then I use a measuring tape to find out how many millimeters wide the display is.  Then divide by horizontal resolution width (e.g. 1920).  That's dot pitch -- the width of a single pixel.  Then multiply this number by 960 (for test pattern movement speed) to program the desired camera-movement speed (the calculator will be built into my software).  Viola.  I now know how fast I need to move the camera at, and I also can know exactly where to display the moving object (if there's motor feedback, combined with cogwheel), to be in front of the camera lens -- as long as I've pre-positioned the whole rig first at a starting "home position".

This is the easy peasy part... I'll do (1) if there's no feedback info, but I prefer to also be able to do approach (2), so I prefer you to use a cogwheel & cogwheel belt (And a motor-position sensor) -- that way, by known distance between cogs (e.g. 1mm per cog) and by knowing motor position -- then all that information can be easily converted to linear position information along the rail.  

Your hard part is the tricky science is maintaining motor speed at a high accuracy, the momentum, the dynamic speed-maintaining (more-or-less camera-mass independent, as long as it's a relatively lightweight camera).


I would use a stepper motor, threaded rod, with trolley mounted on bearing rails
attach camera to the trolley
I've built several camera movement trolleys in the past

where are you located?
do you want this just designed or built/delivered?

there are only 10 types of people
them that understands binary
and them that doesn't

Go Up