OpenMoCo seems like a bad choice of name to me as it's pronounced like the more famous OpenMoko (open source mobile phone). Perhaps you should think about a change or those could be confused with each other Wink
Well, it's a bit late for all of that - as you can see it's been active for about a year, and that's what everyone knows it as now (there've been podcasts, an article in Tom's Hardware Guide, at least one forum has its own section devoted to it, and the timelapse/video motion control industry-types are all aware of it by that name now).
As there's little overlap in audience, I doubt it would be a big deal going forward - and I highly doubt they'd take that much issue with another opensource project having a similar name =)
Hehe, actually one can produce a very high speed out of the steppers, based on some factors about the load, motor, microstepping, and how your velocity curve is implemented. I've been able to push that setup as fast as 5-7KHz step rate - but at that point, the metal worm gearing starts to howl and scream, and the amount of grease required to support those speeds results in too much backlash. I did a test last night with some new asynchronous motor code I'm working on, and pushed it to 10KHz, but that was stressing the gear chain too much.
The reason why the tilt is not centered with the mass of the camera is primarily to reduce the size/weight of the unit, while still allowing maximal tilt. In this case, with the camera off, the tilt bar can rotate a full 360'. Of course, one can simple turn the tilt upright frame around 180' (it's just two bolts that attaches it to the pan base) and get 360', but one goes completely off-center of the pan.
For those shooting panos, they'll want to be able to nodally-center the camera, so in that case, you just get a longer piece of extrusion to mount the camera to, and then slide it down a bit =) For timelapse, a little off-center is better, as you mention, to give a feel more like a person panning the camera.
FWIW, those motors only have 9 oz/in of torque! The gear chain is 120:1 worm gearing, and power is cut to both axes between moves in that video. So, it can run on a 4Ah battery all day and night - and then some.
It may not be obvious from the surface, but the project has really taken off. If you pick up this month's copy of Wired, the fetish photo was shot using the OpenMoco system, I have worked directly with that photographer to help him build a system based around OpenMoco to solve many of his studio needs. Jay Burlage (of HDR and 'milapse' notoriety) joined me in the project a few months back, and has really helped increase the traction of the project with both pro and amateur shooters.
We're currently in talks with several hardware vendors, designers, etc. to start producing "kit components" that take the hardest work out of producing a high-end moco system (for timelapse, gigapano, studio shooting, etc.) and work for the lowest price. There have been a bunch of projects based around the system from DIY guys so far. Here are some examples:
It seems like every day I learn about someone new working with it.
This latest version greatly expands the scripting capabilities for the engine, providing easy support for not only regular timelapse motion control and shooting, but interlacing videos at different motion speeds, or event different positions - you can shoot multiple videos in one pass with different view targets. Also extended support so that HDR timelapse, gigapixel panoramas, and even HDR gigapixel panoramas can be shot easily! (A 10x10 GP script example is included with 'Slim' that shows how to do the whole shot in only 14 commands.)
Speaking of gigapixel panoramas, the Papywizard guys are working to add support for the OpenMoco engine.
Of course, I've also added support for the 4th motor axis in this version, and the full serial protocol is now documented - making it easier to write new UI's or integrate it with other systems.
Along with the sketch for the arduino, I've also provided a perl API library, making it easier to interface with perl applications, and the "Slim" scripting engine, which allows one to use human-readable commands to script and repeat actions, or control the engine in real time from any machine that can run perl (windows, mac, linux, etc.).
We will be providing a native arduino library for serial communication soon so that it can be easily integrated as a network component in an existing arduino project.
Work on a processing-based GUI has begun, but a contributor has also created a Windows-based GUI, like I mentioned we're working with Papywizard to support it there, and some of the contributors are currently working on a native GUI for the touchshield slide.
The next release will add support for a simple native-ui running from the engine (lcd+5 buttons), the ability to mix DC motors in with the steppers, and asynchronous stepper control for using stepper-based continuous motion and real-time motor interaction with the steppers -- amongst many other things =)
There are plans to expand to a gigapano platform as well, which wouldn't be terribly difficult. I'm waiting until I have functional motorized axes together that can be had for a low price before expanding the scope =)
Yes, it requires motor drivers that have step/dir interfaces, like easydriver, probotix, gecko, etc. This allows one to use the right hardware for their solution (i.e. a large crane style automated jib wouldn't work very well with direct-driven steppers from the arduino, but it would work great with some beefy gecko's and AC steppers =)
As for pictures- what would you like to see? Pictures of a setup, or end-result? Right now I've been running an old hardware setup for all testing purposes, and here's a picture of it:
It's just a one-axis system with all of the guts for a three-axis system =)
As for worm gearing, have you checked out sdp-si? They have a great selection of worms and worm gears at a fairly inexpensive price. I've been making my parts lists and getting the parts drawings for the prototype designs I'm working on from them, and have been able to design a 175:1 worm gear setup (based around NEMA 14 steppers from anaheim automation) that part out completely (minus enclosure materials and machining) for about $120/axis. That would make it, in theory, about 42lbs of torque at final output, and a minimum rotational step of about 0.0019 degrees per step w/ an easydriver and 1.8 degree stepper.
Right now I'm working on some tutorials for the beginning DIY'er, while I wait to finish saving the cash to get my CNC system completed. I think there are a lot of great examples of how to do things out there for the newbie (certainly, I learned from a lot of them), but they don't explain how and why they were designed the way they were. I guess you could say that I'm surreptitiously defending all design concepts I've made through tutorials that show different ways of doing things, and their strengths/weaknesses =)
It's still fairly early in the life of the project, with a few people already using the software in their own hardware designs.
At least one other person, Dan Thompson, is contributing his own take, with a direct control interface between Maya and a multi-axis rig.
Recently, I completed the first versions of my OpenMoco software for the Arduino.
The purpose of the OpenMoco system is to provide an open-source, relatively inexpensive motion-control solution for time-lapse that provides many of the capabilities of the closed-source (and fairly pricey!) options on the market.
The OpenMoco design concept is presently:
A centralized 'engine' that directly controls up to two cameras, or one camera and an external flash, and interfaces with three stepper motor controllers to control motion on the axes.
Any number of human or machine interfaces (up to two at one time, via hardware and software serial) to control the engine.
Current engine features:
* Intervalometer control: from 1 to 65,536 seconds interval time * 'Optimistic' scheduling of exposures -- fire at earliest available point longer than interval, don't miss shots due to actions taking longer than expected, and don't shoot during an action * Bulb mode exposure control: from 1 ms to ~ 50 days * Pre-focus tap (tap focus before firing) * Post-exposure delay * Pre-exposure delay * Shot-count limiting (none, or limit up to 65,536 shots) * Control of up to 3 stepper-motorized axes * Motion control is shoot-move-shoot (no movements while camera firing) * Linear ramp up and down of motor movement (make smooth transistions in final output video) * Linear speed ramping of individual movements (avoid shake and bounce when driving steppers multiple steps) * Direct manual control of axes (move this far, now) * Set home/go to home on motor axes * Alt Input/Output port * Alt input triggers actions when brought high * Alt in can trigger: camera exposure, motor movement * Alt output acts as secondary output when firing camera (another camera, flash, etc.) * Trigger alt out before or after: camera fire, individual motor movement * Action scripting: set pre-defined actions into program memory * Actions can modify nearly an aspect of program execution (exposure time, camera on/off, motor movement/direction, motor ramping, pause program, stop program, etc.) * Keyframing: trigger actions when keyframes occur. * Up to 8 keyframes of each type: shots fired, time elapsed, motor movements * Dual control by both hardware UART and software UART (control via computer and a hand-held device at the same time)
It also currently has a PERL API for controlling and interacting with the engine from a computer. I'll be releasing a human, textual/scriptable interface to it soon.
Some of the changes coming up in the next version:
* Removing software UART (never liked it anyhow) * Adding i2c support for other devices (like my LightRails exposure control device), and separating some functions out of the engine into different components * Backlash compensation * Extending to 4-axes
I expect to have in the next couple of months a reference design showing how to create a two-axis unit using off-the-shelf components from Sherline, for about half the price of a commercial system that's currently on the market using the same sherline components.
Also, by end of the year, I intend to be releasing my first prototype motor axis units that do pan/tilt.
The goal is to both enable the DIY time-lapser to create great systems without having to hassle with re-inventing software wheels, and also to enable the dabbler to buy off-the-shelf setups that are much less than the current market prices for systems with similar features. (Presently, approximately $2k to $20k for commercial systems.)
I meant the "bin" directory in the hex uploader source tree... not /bin on your computer =)
Download the source from the link above, you'll see it has its own directory tree, including a sub-directory called "bin", another "hex", "data", and so on.
As for avrdude... You'll need to google that one =) I'm going to have to leave getting avrdude, and understanding what it is, up to you (hence my original statement in my first post =) ... In fact, all you need to solve your problem is avrdude, and trying to hack this hex uploader just to use avrdude in a gui will be more work for you!
All you should have to do is load up processing, replace the files in bin/ with the avrdude binaries for mac (I'm going to have to leave that one up to you =), put your hex file in the hex/ directory , and then adjust the avrdude parameters in the processing sketch to match the right ones for your lilypad. (Hint: go into arduino ide, and upload a basic sketch, but hold down 'shift' when you click on the upload button to get verbose output.)
So, I had a need for an easy-to-use hex firmware uploader that anyone could use, without having to explain how to install and run the IDE, or explain the command-line for avrdude.
It's actually pretty easy to just use avrdude, but sometimes we have people who aren't even familiar with the command shell in windows, mac, or linux. Considering this took all of a few hours to put together, it costs less to do than constantly re-explain avrdude *grin*
I'm sharing it in case anyone else has a need for similar, it only works with the Atmega328-based duemilanove's, afaik, but can easily be modded to support any board.
I use it with avrdude 5.10, so there's no need to do any serial port reset hackery, instead it uses the "arduino" programmer type.
Here's the processing source and a windows binary: http://dynamicperception.com/docs/mx2/uploader
Focalist, I like what you're trying to do. I'd hope you'd come join us @ OpenMoCo.org (It's a community focused on open-source photographic motion control and DIY camera projects w/ the Arduino), if for no other reason than to join in the community discussions.
I think there are a few things you can do to help improve your tutorial process, however.
Namely, I'm left wondering what the content difference (I understand that you're going for a presentation difference) is between your tutorial and the dozens out there for doing intervalometers. I was asked by some of the timelapse guys to do the same a while back, and when I did, I was struck with the same problem, so I chose to focus the tutorial on understanding different timing techniques, which hadn't been covered in the existing tutorials.
It's important that if you're going to cover well-trod ground, that you provide new content. This will really help to draw your readers in and keep them with you.
I have a second, more utilitarian question - your tutorial says you're triggering a bulb exposure of 5mS on the Rebel XT. I think you've made a mistake here -- you may be triggering the shutter at 5mS, but I don't think you've got a 5mS exposure. (If you have, you've just made a bunch of people happy to find a camera that can do very short bulb exposures.) A lot of work has been done on measuring timing on different cameras, it would do well to check on some of the experiences people have had with this: http://timescapes.org/phpBB3/viewtopic.php?p=14652#p14652
Finally, it would help a lot to inform your readers why you've taken a bulb-control route, and what the limitations are over using PTP control, much like the Promote controller does - as there are very real limitations compared to PTP control for HDR bracketing.
@twoblue: some of the components can be had off-the-shelf from 8020, SDP-SI, and Grainger, whereas other parts are custom built by us. The DollyShield will be sold as part of a larger package to timelapse shooters via DynamicPerception.com come September. If you look at the first video in that series, Jay talks quite a bit about pricing (less than $800 for everything).
@Funky diver: I'm not sure I get your drift, are you saying you don't like timelapse video, and want me to encourage you to like it, or you're not familiar with timelapse video? I'm not equipped (nor terribly interested =) in performing the former, but there's a lot of info to help with the latter...
The whole purpose of taking pictures like this is to create videos (one frame at a time!) showing the passing of time, often to great artistic effect.
Of course, timelapse isn't the only thing that utilizes this same technology, but to open up the doors on photographic motion control would take a lot more chars than I have here =) Try http://timescapes.org - look around on the forum there, there are hundreds of people uploading their videos, maybe something will catch your fancy, or not.
There are actually a number of cases where each method is applicable.
Continuous motion is tied to minimum possible speed (although this can be faked using speed averaging techniques), and therefore largely unusable for multi-day timelapses (say, one shot every hour for several days/weeks/months).
Additionally, there are a number of "artistic" effects that can be produced using either. For example, when shooting 30s exposures to eliminate moving objects, but still having static objects sharp, S-M-S excels. (Whether or not it seems "too sharp" is often a subject of debate, rather than land on one or the other side, it's a no-brainer to do both.)
Additionally, when working with really long lenses and macro work, any vibration, including that of a running motor can blow focus. For critical focus work with big heavy lenses, S-M-S can be quite useful.
A number of people use S-M-S for star work, as "tracking stars" also blows your foreground subjects - blurring and smearing them. It's ok for stars to trail slightly, as the mind understands them as moving objects in the sky, but if the tree in the foreground is a blur, it can kill a shot. "Tracking stars" works well when only stars are in the shot, with real foreground items that draw and focus attention, you want some flexibility in how you create it.
An extreme is to move during the shots more than between the shots. I describe the benefits and drawbacks of each method in a very short article here: http://openmoco.org/node/93
While I was working on finding the right combination of open-source hardware to create a stand-alone 2-axis motor driver, with user interface, I got frustrated with a lot of the options out there, and decided to design my own. (That is to say, there were plenty of capable components out there, but trying to solve each major problem through combinations of them resulted in a very high cost.)
We call the shield the "DollyShield," and combined with the firmware I've created, it's the "MX2 Dolly Engine," (the naming makes sense for the project =)
The design is based on the Arduino Motor Shield v3, and uses the same L293B driver chip and driver circuitry. It expands on the normal capabilities of the motor shield by providing all elements necessary for a stand-alone user interface, an integrated and isolated camera connection, easy access to the hardware serial pins through a stereo jack, and an additional stereo jack connecting to pins 2 and 3 of the Arduino to allow for the use of encoders or limit switches. Pins 2 and 3 are chosen for their association with hardware interrupts which increase the reliability of encoder or limit switch actions.
As far as I know, it's the only shield that has both dual DC motor drivers and complete user interface, I could be wrong though...
The board design is, of course, licensed under CC 3.0 Attribution Share-Alike, and I intend to make sure any designs I release through the OpenMoCo community meet the OSHW definitions.
I'm using these to run motorized camera dollies, but they could probably come in useful anywhere you need both a motor controller and a UI. Additionally, I'll be showing in the next couple of weeks how to replace the internals for a Meade DS telescope head with this shield+arduino to unlock better capabilities.
Here's a quick rundown of the features:
* 2x DC Motor Speed/Direction PWM Drivers (Up to 1A) * 1x 1/8" TRS Plug for isolated camera connection (focus+shutter) * 1x Camera exposing LED * 2x 1/8" TRS Plug for auxiliary I/O (Hardware Serial, Digital 2+3) * * Can be used for encoders, limit switches, serial communication other boards, etc. * 1x 16x2 LCD for display * 5x Momentary pushbuttons * 2x DC Barrel Jacks for Motor Hookup (2.5x5.5mm) * 9v-12v supply voltage * Compact: 3.85x2.7" * Low-cost
and the MX2 Dolly Engine Firmware Features:
* Alter any setting on-the-fly * Easy start/stop mode * Manual motor control * All basic control from a single screen
* Camera Control ** Intervalometer ** Focus Trigger ** Shutter Trigger ** Exposure Delay ** Focus+Shutter link (for Nikons)
* Easy Motor Control (speed/direction) * Speed in percentage or inch-per-minute * Linear output video speed ramping * Continuous Motion * Slow Motion Modes ** Enables far slower speeds than PWM alone ** Pulse for continuous slow mode (target average speed) ** Shoot-move-shoot to move between exposures
* Adjust LCD backlight from software * Turn off LCD entirely after inactivity * Completely configurable with five buttons
Here's a video walk-through of the basic usage: -- this video shows it as part of a low-cost motorized dolly setup for timelapse usage.
I got the chance to give a talk about this shield in The Studio at SIGGRAPH last week, and had a lot of interest from people who hadn't heard about the project, so I thought I'd share it with a broader audience than just the timelapse community.
I plan on making these boards generally available for sale come late September, and they will be priced around $50 for a kit, or $80 assembled.
I would appreciate any feedback you have on this shield, or anything else you'd like to talk about =)
Yes, having built many, many pinhole cameras over the years - I'm familiar with diffraction (not refraction =) You can even find a video on vimeo where I pointed out the cause of flicker in camera-driven apertures (vs. manual apertures) for time-lapse was over-shooting the aperture setting rather than under-shooting via a diffraction example.
As a rule, it's considered largely part of the "aesthetic effect", and f/stop ratios greater than 100 are common. I have one camera floating around somewhere that has f/280 and a 9" focal length. It took this photo:
I think that was about an 8-hour exposure under 500W of hot lights onto 3000ISO polaroid. The flower was toasty-crittered by the end of the day.
Here's one at f/98, IIRC, on 35mm:
Although, I can't recall the name of the scientist, but I believe there is a formula wherein one can create a photo which is as sharp as a lens photo, but having nearly infinite depth-of-field. I've seen some of the photos taken by the guy, in pinhole, and they, well, rock. I'd have to look it up in the books when I get home.
The cats over at f295.org would have more to say - you can find some quite sharp examples there.
Halley - that's do-able, you should be able to stop the MsTimer2 during exposure without affecting the exposure (the on timer trigger function closes the shutter, effectively) and set a new timer after first eliminating the amount of time you have already exposed from your calculation.
And, you're right - that would make a perfect addition to any pinhole or super-long exposure shot. It's specifically for that kind of thing that I placed no limit (other than (float) size) on the f/stop.
.. of course, I left out the fancy rounding the camera manufacturers do in ISO and f/stop calculations, and just used the pure logarithmic implementation. So, some of the numbers seem weird, but at least they're "true" =)