Alas, it is slightly different than the systems you've been working with, but some of the compromises may be highly useful for you.

Unfortunately, motor move commands are synchronous.  You say to move a thousand steps, and the response tells you when it's done.  The vast majority of other commands (including expose camera) are asynchronous, and you can query their status while running.  edit: I can make the command non-blocking, but since the device is single-threaded, and not using interrupts for stepper movement, it would simply block the next command, else engine timing would be completely off.

One of the primary differences between OpenMoco and some of the other 'controllers' out there, is that it's a full scripting engine.  You don't actually have to monitor, and time everything yourself.  You can set parameters once, tell it to start, and then come back and check on them.  This is especially useful in timelapse shooting, as you can completely disconnect your computer/PDA, and then come back later and see how far along you've gotten.  Additionally, it supports pre-recorded actions and keyframes to call them.

An entire pano sequence could easily be scripted such that you enter the parameters, tell it to start, and then its done.  (Using a vertical movement between shot cycles to make the rows, the repeat shot setting equivalent to the number of columns you want to shoot, a movement action between each repeated shot, and a direction action upon completion of repeat shot cycle to reverse direction for the next row. Set the max shots to be number of rows, then tell it to start.) 

All four axes are "independent", if by that you mean, they should have separate commands, parameters, status, etc.

I'd be happy to discuss some use-cases with you, and talk about how to achieve them, and help you put together the commands.  If you just want to do "manual" control of the engine, everything related to that is listed right here: http://openmoco.org/node/142  (there aren't many manual commands).

I'm the author, btw, and would be glad to make any changes (it's fully open-source) you'd like - but it will be some time before the motor movement for steppers is non-blocking, as that's a complete re-write of the motor control code

!c

Last edited by shutterdrone (2010-04-11 17:19:11)

fma38 wrote:

Ok, I think it will require a different way to write the plugin. As I said, I don't have enough time now, so I will put this on my todo list...

Understood - it takes time to get through those to-do's (I remind people of that sometimes myself

To give an idea of how scripting works with it, I created a workflow example:  here's something I was playing around with yesterday, using the "Slim" script interface (which just basically converts all serial api commands into human read-able commands and allows one to enter them at a prompt - I use it for testing and 'advanced' scripting...)

This set of commands fully automates a 10x10 sequence image sequence (assuming 1000 steps movement between each), by shooting each column, and then moving on to the next row.  Each column alternates, so that it ends at the top of one, and moves to the bottom on the next to avoid wasted moves, it moves over one column after completing the current one:

 # set direction for motor axes (0= pan, 1= tilt)
motor 0 dir 1
motor 1 dir 1
 # create action id1 to move axis 1 1000 steps, in current direction
action motor 1 move 1000 1 3
 # action to move motor axis 0 in fixed direction 
action motor 2 move 1000 0 1
 # action to invert the direction of axis 1 (tilt)
action motor 3 set_dir 0 1 2
 # enable camera
camera on
 # set 72ms for camera exp trigger
camera exposure 72
 # wait 25 ms before moving motors.. actual exp time is 1/1000 on camera
camera post 25
 # set 10 shots per column
camera repeat 10
 # move motor 1 between repeat (column) shots
camera rep_act 0 1
 # call actions to invert direction of tilt and move to next column
 # when the current column has completed
camera rep_com 0 2
camera rep_com 0 3
 # limit to 10 columns (repeat sets 10 rows per column)
camera shots 10
start

That's it - it shoots the whole cycle fairly rapidly, automated, and then stops.  One can query the current shot, motor distances moved, whether camera is currently exposing, program still running, etc. while this is going on.  14 total serial commands sent (about 100 bytes total) to do the whole 10x10 shot.  Up to 255x255 (well, actually millions x 255) panos can be triggered with the same 100 bytes.  There are about a dozen other ways to do the same, but I think this is the most succinct and obvious way off the top of my head.

!c

Last edited by shutterdrone (2010-04-12 19:56:32)

Hmm that makes me ask can a script generator be included into Papywizard? this would be useful when using differing lens and bodies whilst shooting.

Best
Gordon

fma38 wrote:

All jones generators can be executed locally on aby browser; I'm pretty sure they work on a Nokia. Then, the only thing to do, is a little uploader. How does the openmoco firmware communicate with the host?

The host sends binary serial commands, and reads the responses. Depending on which Arduino you use, the interface will either be straight Serial, USB->Serial, or Wireless.  All you have to do is make a serial link, and start pumping commands at it.

The engine runs on any 328p-based Arduino (code size will outgrow the 128 chipset within a release or so, and RAM usage already exceeds 128's abilities), so the ways one can make a link are pretty numerous, but the important part about the serial protocol is that it is binary, and expects big-endian data.  So, if you send an unsigned int (16bits in the arduino-world), you would send two bytes: MSB,LSB.  This can be problematic from the client end until one realizes that if some of the commands were expressed as ASCII, they could be up to hundreds of bytes long, and no existing serial command supported requires more than 9 data bytes right now, so the longest stream is 11bytes. (Command+DLB+Data)

!c

It should be totally do-able in that way.  If you can also load perl code, there's already an API with every capability mapped to a method, and does all the binary building/communicating with the engine for you.  The OpenMoco::Interface::TimeLapse module is pretty simple to use. I'm not terribly familiar with python, but as I understand, it uses a similar pack methodology to perl for building binary strings.  If one wanted to re-implement in python, could just convert the existing pack templates.

In fact, I like that way quite a bit (webserver) - it's efficient, light-weight, and easy to implement.

!c

Hello Frederic,

I presume that "shutterdrone" speak about "OpenMoco Slim" the user interface:

http://openmoco.org/node/99

Here is also the global link to all the software for OpenMoco:

http://openmoco.org/node/12

All the job done by "shutterdrone" is fantastic and make me think about a "certain" FMA38

This is the best thing since peanut butter and jelly sandwiches! (and believe me I don't say that every day...)

Well, it depends; in preset mode, it is usefull to drive both axis at the same time. But in mosaic, only one axis generaly moves at a time.

It would be very useful to have a script generator for now until a driver is written for Papywizard. For VR photos it would be easy to have pre-written scripts for OpenMoco but when you get into gigapixel panoramic shots a script generator would be very handy. Then we'll get into the timelapse stuff and that can get very complex to move the camera on a boom/trolley while panning to keep an object as the center of rotation in the image.

Jones,

Just one correction - right now it only works with stepper motors, not servos.  Servos, DC motors, etc. will be selectable in the not-so-distant future   The firmware can either be used to do interactive control of up to 4 axes of motion and a camera, or can be used as a scripting engine, and run in an 'autonomous' mode to fulfill your desire after being setup.  The more 'autonomous' mode makes it very easy to do complex shots, but the 'interactive' mode can be more easy to integrate with to start with.

Greg,

It's funny that you mention object tracking - Matthias had posted a video where he did that using his dolly+pan+tilt using 0.81.  Here's that video: http://www.vimeo.com/11016934

I think he did it the hard way (I've seen his windows GUI, and I don't recall a special set of functions to calculate such moves for you), and simply calculated the relative speed for the pan vs. the output speed for the dolly.

!chris

Last edited by shutterdrone (2010-04-20 16:25:25)

I think it would be best if the number of steps per 360 could be a field you fill in since there are many different variations. My system has 18000 steps if using full stepping but I can also increase that if I use micro-stepping. I think Chris is using 20000 steps at full stepping right now.

Now I see the main firmware is dealing with the steps and the client takes the responsibility of figuring out how many steps etc. Thanks for the explanation.

Jones