Home » Forums » OpenMoco Developer Forum » Engine

Slim HDR script question

Submitted by cronix on Sun, 07/31/2011 - 21:01
Posted in

I am trying to write a Slim script that I can use for HDR time lapse series. The script is also using the ramping functionality of the engine. The ramping is working perfectly. The example below ramps in the first 30 shots and ramps out the last 30 shots.

My problem lies around the repeat command. I use repeat 3. That is working; the camera takes three shots. I let the camera handle the bracketing.

The problem is that the motor is moving two times to the next position and not one. The camera takes the tree shots and then the motor is moved twice. The script is below. I hope this is me that is doing something wrong and that this is not a bug of the 0.82 engine.

debug 1

port /dev/ttyUSB0
connect

sleep 2

interval 8

# Enable kill signal
kill on

# For HDR repeats
camera repeat 3

# Other camera settings
camera on
camera focus 1
camera exposure 100
camera post 500
camera shots 450

# Motor 0 settings
motor 0 enable 1
motor 0 steps 666
# Start ramp up first. Argument is the number of shots before full speed is reached
motor 0 ramp 30

# Define ramp down as action 0 for motor 0
action motor 0 ramp 0

# Define keyframe from where the ramp down starts (example is at shot 40)
keyframe camera 0 420 0

‹ Minimum uSeconds between motor steps Home and Move commands are not working properly ›

Dumb question on my part - is

Submitted by shutterdrone on Sun, 07/31/2011 - 22:24.

Dumb question on my part - is it stepping twice after each shot, or once before and once after? (i.e. - does it take a step before the very first shot, or do the steps always start after the first shot?)

!c

The steps (two of them)

Submitted by cronix on Sun, 07/31/2011 - 23:14.

The steps (two of them) always occur after the shot. So from the start of the script: shot, step, step and that is repeated. There is a clear time interval between the two step sequences. Hope that helps.

I tried using the camera

Submitted by Panascape on Mon, 08/01/2011 - 05:23.
Panascape's picture

I tried using the camera repeat function on my equipment running the following command script and encountered the same exact "double step" situation between each successive burst of three camera shots.

port /dev/tty.usbserial-A9007Q6A
connect
sleep 5
set_motor 1 home
set_motor 1 dir 0
set_motor 1 steps 20
set_motor 1 ramp 10
set_motor 1 enable
set_motor 0 home
set_motor 0 dir 0
set_motor 0 steps 20
set_motor 0 ramp 10
set_motor 0 enable
set_camera repeat 2
set_camera cycle 4
set_camera tap 1000
set_camera exposure 50
set_camera post 1000
set_camera shots 130
action motor 0 ramp 0 0 0
action motor 1 ramp 0 1 0
keyframe camera 0 90 0
keyframe camera 1 90 1
set_camera on
start

Interesting - I'll look into

Submitted by shutterdrone on Mon, 08/01/2011 - 12:53.

Interesting - I'll look into it and see if I can come up with anything.

!c

Hi Chris, I hope you have

Submitted by cronix on Tue, 08/02/2011 - 22:35.

Hi Chris,

I hope you have more luck. I have given this a try today and cannot find the solutions at first sight.

Hmm, I tried replicating with

Submitted by shutterdrone on Wed, 08/03/2011 - 03:14.

Hmm, I tried replicating with the nanomoco setup, but was unable to. I'm going to have to wire up a driver tomorrow to a regular arduino, and run the 0.82 branch and see how they differ.

I was thinking that it might be that the final camera exposure in the repeat was completing after the step through the main loop (checking the shot cycle complete flag) that moves the motors, causing the shot cycle complete flag to be reset after the motor moved and before the camera fired again - resulting in the double move. But, there's a call to delay for the post exposure delay there, and you both have the post time set longer than the exposure time.

So, it's going to take a little more digging!

!c

Actually, after sleeping on

Submitted by shutterdrone on Wed, 08/03/2011 - 13:09.

Actually, after sleeping on it - I'm pretty sure that I see the problem. While I was correct in saying there was a delay after the final shot, before the motor was moved - I was incorrect in stating this would protect the shot cycle complete flag.

I haven't been able to verify this for you yet, but I'm pretty sure the cause of the issue is here:

           // clear shot cycle completed flag
        action_status &= B11111011;
       
            // run any camera keyframee
        camera_key();

        if( camera_pst_delay > 0 ) {
            // TODO: replace with a status variable/timer
          delay(camera_pst_delay);
         
        }

Note that the delay happens -after- the shot cycle complete flag is cleared. As the flag is set by the stop_camera() function, which is called in an interrupt, it can (and most likely is) happen after the flag has been turned off, re-enabling it and triggering the second move.

Try moving the flag reset to after the delay, e.g.:

            // run any camera keyframee
        camera_key();

        if( camera_pst_delay > 0 ) {
            // TODO: replace with a status variable/timer
          delay(camera_pst_delay);          
        }

           // clear shot cycle completed flag
        action_status &= B11111011;
       

I noticed that this had been done in the nanomoco branch, so that's likely why I was having trouble replicating it. (I don't know if I did it before or during testing, to be honest, though.)

!c

Hi Chris, This is working!

Submitted by cronix on Wed, 08/03/2011 - 18:41.

Hi Chris,

This is working! Thanks. I hope to test this in the field next weekend

Cheers,
Andre

I did a field test today. A

Submitted by cronix on Mon, 08/08/2011 - 17:59.

I did a field test today. A combination of HDR and my dolly. I made some miscalculations with my settings, but here is the result:

http://www.youtube.com/watch?v=4L00XySvT4Q

Check the following link if you want to know more about this short example:
http://www.elysia.nl/content/third-field-test-my-time-lapse-dolly-watersnood-monument-nieuwerkerk-aan-den-ijssel