next topic »

[on:]

Hello,

I made a post in this thread, but since I need collaborators for my project.
http://arduino.cc/forum/index.php/topic,133035.msg1009342.html

I need an Arduino-controlled device that moves a camera horiziontally approximately 0.25 meters per second while taking a picture for 1/10th second.
This is for an experiment -- scientific measurements of display motion blur.  (Cameras taking pictures of moving test pattern objects on screen)
I can build it myself, but my time is quite short/lacking.   I can write Arduino programs myself, and I can create electronics circuits.

Essentially, camera starts moving, accelerates, [BEGIN precision requirement] then takes a picture for 1/10th second [END precision requirement], then camera decelerates to a stop.  I only need one picture, but when the shutter is open, the precision requierments apply.

Here are my preferred requirements:
(1) Must fit on a desk (ideally less than 1 meter long (1 to 3 feet long) maximum 4 feet long. Less than 1 feet deep).
(2) Speed control: 1mm per second increments, up to at approx ~300mm per second.  (more is desirable -- but not needed now)
(3) Speed error: +/- 1mm per second error (@250mm per second)
(4) Positioning error: +/- 1 centimeter (Manual shutter timing fine-tuning should be manageable)
(5) Amount of time the precision is required: 1/10th second (macro mode)
(6) Moving mass required: Typical point-and-shoot camera (1/10sec allows use of lightweight camera w/manual exposure ability)

Acceptable precision degradations, if certain parameters are expensive/difficult to meet:
(2b) Speed control: 5mm per second increments (= 0.5mm per second difference during 1/10sec exposure)
(3b) Speed error: +/- 10mm per second (= 1mm error during 1/10sec exposure)
(4b) Positioning error: +/- 5 centimeter (I can do multiple attempts until subject matter is fully in the frame)

The movement mechanism can be anything:
- Stepper motors and a metric threaded screw.
- A hacked inkjet printer mechanism (with the camera mounted to what used to be the cartridge holder)
- A conveyor belt mechanism.
The camera will be computer/Arduino controlled (using a modified shutter button wired to the computer, or by using Canon CHDK custom firmware modification).

The precise details are left to you, but the system must be reasonably cheap and easy to build copies of (100% open-source build instructions, with photos -- will pay extra $ for your photos taken while you build the device).   I'll be publishing the stuff on my BlurBusters blog.

You can also contact me directly at mark[at]scanningbacklight.com

Sincerely,
Mark Rejhon
The BlurBusters Blog

[Reply #1 on:]

Addendum: That was fast!
One application by an electronics engineer has now been received already.
I am accepting proposals from anybody until December 7th, and want to compare all the qualified ideas before money leaves my pocket.

[Reply #2 on:]

sorry i a had send you a pm b4, so i would like to make an offer for you now, the cheapest i could think of now is to use pvc as the main building material, with me doing for you i would give you the complete set of technical drawing, from the mechanical , electrical, electronic and the software program for you to post on your blog, if you need to i will also include some picture of me building it, and during the construction phase i would regularly send you update on the project phase. are there any requirement for the project to be super cheap or you don't mind as long as it is according to your spec?

ouh yeah for my qualification, I am a mechatronic graduate in one of a well know school in Malaysia, work for 2 years in the Automation industries , my specialty is on mechanical and programming  and now continuing my sturdy in Industrial Automation.

[Reply #3 on:]

I built a system that was supposed to take pictures using point and shoot cameras correlated in time to an easily detected event.  The system never met the time requirements, the images would sometimes be at the correct time but usually they were late by some non-deterministic time.  Troubleshooting in the lab with function generators and o-scopes showed the detection system and camera triggering pulse were all well behaved, the problem was in the point-and-shoot camera as it would take a while to make the exposure adjustments to make sure  that the picture looked good and this screwed my timing up.

Since then whenever I need to do similar I read for one of my Nikon DSLR as they do not have that delay, they can be told to take the image when the button is pressed.  Point-and-shoot cameras may have evolved such that they ojn be told to just take the image at the time you want it or the beautification fast enough so the time delay is not seen.  On that point you probably want to quantify how tight you want the spec take a picture for 1/10 of a second so when the acceptance test rolls around you do not get into an argument about close enough.

[Reply #4 on:]

What wwbrown says is correct, most (all?) cheap cameras don't have a deterministic shutter latency so I think you will have to use a good DSLR. That affects the mass to be moved.

______
Rob

[Reply #5 on:]

--> 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.

[Reply #6 on:]

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

[Reply #7 on:]

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.

--and/or--

(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).

[Reply #8 on:]

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?

cheers
Mike