Submitted by shutterdrone on Wed, 01/20/2010 - 03:39
Posted in
I've been working on the 0.82 engine, and have been adding two-way communication to the serial API to handle status requests from the engine, and making it possible to retrieve current parameters, etc.
For the time being, the 0.82 branch is available from SVN on sourceforge, and you can view it here: OpenMoco_Timelapse_Engine. The header of OM_Serial_Com_Client.pde lists the additional serial values.
(The new stats code is largely untested, but compiles properly as of this message)
The first part added is command response -- each command is responded to with a single response byte. Presently, there are two values: 0 (0x0) for error (such as unknown command), and 1 (0x1) for success.
Command response happens upon the completion of the given request, so if you're setting the interval time, for example, the response will be nearly instantaneous compared to the time it takes to respond to a request to move a motor 10,000 steps. Client code will need to use timeouts to prevent blocking forever should an issue occur. (The in-dev version of the perl API uses a default of 20 seconds.)
Following a command response, will be the length of data (in bytes) the engine is going to return in addition to the response - from 0 to 255. Neither the length byte nor the command response byte will be counted in the data length. Thus, a command with no data returned would be responded to with the following sequence:
[ 0x1, 0x0 ]
Naturally, the commands that set parameters or order the engine to do something do not return any additional data, so they will always have a data length of zero. If a command is unrecognized, or an error occurs, no bytes will follow the command response.
The following new capabilities have been added thus far:
- Status Check / NOOP
Does nothing, simply gives back a positive command response. You can use it to see if the engine is currently available to listen to commands.
- API Version
Responds with API version (one byte)
- Running status
Responds with Running or Stopped/Paused (one byte)
- Run time
Program running time (ms, 32 bits)
- Camera Enabled
Camera currently enabled (one byte)
- Shot Count
Current shot count (32 bits)
- Interval Time
Current interval time (secs, 16 bits)
- Exposure Time
Current exposure time (ms, 32 bits)
- Post Delay
Current post-exposure delay (ms, 16 bits)
- Camera Currently Exposing
Whether the shutter is currently triggered for the camera (one byte)
- Motor Enabled
Whether a given motor is enabled (one byte)
- Motor Dir
Motor direction (one byte)
- Steps Moved
Steps moved for a given motor (32 bits)
- Home Distance
Distance (in steps, positive or negative) from home position (signed 32 bits)
- Motor Steps Max
Maximum step count for given motor (32 bits)
- Motor Ramp
Motor ramp rate for given motor (one byte)
- Motor Backlash
Motor backlash compensation for given motor (one byte)
Still need to add protocol codes to retrieve keyframe and action data. Additionally, still need to add motor steps between shots parameter retrieval.
Any suggestions, questions, or feedback would be highly appreciated!
!c
Some other changes (currently
Some other changes (currently checked in to svn):
* Fixed bug in motor home, now properly goes in either direction
* Fixed bug where focus tap could not be enabled (introduced in 0.82)
* Fixed bug in setting certain motor keyframes (introduced in 0.82)
* Full support for 4th motor axis
* All keyframes extended from 8 or each type to 16 of each type
* Recorded actions increased from 8 to 16
* Backlash compensation for each axis (up to 255 steps)
* Shot count for camera keyframes extended from 8,192 to > 268 million
* Fire camera now protocol command added (with exposure len)
* Removed NewSoftSerial lib for the time being, to make it easier to compile
Coming in the next check-in:
* Shared motor kill line: use a single line to kill motor axes between movements (reduce power consumption)
* Focus high with shutter high: resolves issue with nikons and some other cameras that need both high - selectable via serial protocol
Still waiting to be developed:
* Repeat camera cycle
Allow a shot cycle to specify that with each shot taken, it should be repeated x times, moving motors and/or changing exposure. Used to enable stereoscopic and engine-controlled HDR shooting, as well as make it easier to script panoramic shot actions
* Improved velocity and step control
Will aid in using a variety of motors and drivers, improving performance over very long and very short moves
* MIN/MAX_STEP delays, CAMERA_SAFE_WAIT, and other parameters set-able via protocol.
Makes engine more configurable without re-compiling
As always, any feedback, requests, or suggestions are greatly appreciated.
!c
Great to see this
Great to see this development. I cannot wait for the Nikon support.
Ok, I checked in a bunch of
Ok, I checked in a bunch of changes to 0.82, Slim, and the perl API to subversion. The new perl API repo is here: 0.03, and the new Slim repo is here: 0.12.
You'll need to download and install both, in addition to the latest checkin in the 0.82 engine to use the new features. If you can test it out, and let me know if anything doesn't work right, that would be awesome - I have regressed a lot of it, and fixed some small issues in both Slim and the engine (I updated the Slim docs, too =)
Thanks!
!c
A new check-in tonight: Added
A new check-in tonight:
Added ability to specify that, when firing the camera on the intervalometer, one should repeat the exposure x times. This allows you to do multiple triggers per exposure, say for using bracketing on-camera. In addition, you can call up to four actions between each exposure in the repeat cycle, and if you choose, you can have all motors re-set back to where they started after each exposure cycle completes. As one might hope, the shot counter is not run-up by the repeat exposures, only the original exposure counts there.
This can be used to drive stereoscopic shooting, panoramas, or even multi-speed timelapses!
(Oh yeah, I forgot to mention that I added an action type of 'move now', to enable motion during a repeat cycle. It's limited to 255 steps for now, will bump it up later.)
The update has been applied to the 0.82 branch of the engine, 0.12 of slim, and 0.3 of the perl api. You will need to update all three to take advantage of the new features. Once you've updated everything, run Slim and type 'help repeat' and 'help set_camera' to get an idea of how to use it.
For grins, here's a script I use w/ my pan axis, as axis 0, to get a clear idea of what this new feature can do:
c
camera on
camera cycle 5
camera exposure 200
camera post 300
camera repeat 5
camera rep_home 1
action motor 1 move 255 0 1
camera rep_act 0 1
motor 0 enable
motor 0 steps 5000
motor 0 dir 0
start
For a little more intrigue, here's a script that will interlace three time-lapse videos of the same subject, each one moving at speed 30 steps faster than the next =) (You would have to separate out the images yourself, but the first would move at 90 steps/frame, the 2nd at 60 steps/frame, and the 3rd at 30 steps/frame - as we're countering the main motion.)
c
motor 0 enable
# set motor 0 to move 90 steps in dir 1
# between each interval cycle
motor 0 steps 90
motor 0 dir 1
camera on
camera cycle 5
camera exposure 72
camera post 300
# repeat an extra two shots every time the camera fires
camera repeat 2
# send motors back to starting point after repeat cycle
camera rep_home 1
# add an action to move thirty steps in dir 0
# between each repeat cycle shot
action motor 1 move 30 0 0
# tell the repeat cycle to use this action between shots
camera rep_act 0 1
start
To get an idea of what's going on above - the 'normal' movement between shots is 90 steps in direction 1. However, we also state that we want to repeat each exposure twice at each interval cycle. And, between each of these shots we want to move motor axis 0, 30 steps in the 0 direction (opposite normal travel). That would result in a shot cycle that looks like this:
Shot Steps
1 0
1.1 -30
1.2 -60
2 90
2.1 60
2.2 30
3 180
3.1 150
3.2 120
... and so on
That way, you'd have three speeds interlaced, and you just need to separate out the files when you're done. Obviously, the first shot cycle has starts in a weird position, but burning one shots isn't too bad =)
Enjoy, let me know what ya think.
!c
Hi Chris, I have installed
Hi Chris,
I have installed the latest software. All is working as you mention it. The feature set is becomming more impressive every day.
Have you tested the script above with your pan/tilt head? De last script is pushing the camera and motor at a very high speed. Can the head keep up with this? Does is accelerate fast enough to make the movements in time?
Regards,
Andre
Oh, Andre - sorry about
Oh, Andre - sorry about that!
Please adjust your MIN_STEP and MAX_STEP defines. I pushed it pretty hard during testing the motor kill function (which, btw, allows one to drive at a much faster speed as the motor stays cooler between motions, and I found the easydrivers would hit their heat cut-off point in long motions w/o it), but it will mess with small motions (the max step time is too low), causing them to be jerky.
The next update will allow these to be controlled via the serial protocol, so less worries there - I can test w/o accidentally leaving my changes in the code =)
But, yeah, it definitely works. Just gotta use good lubrication - my metal worms whined like a banshee at 100Khz until I added some more grease =)
!c
Ok, tonight's check-ins added
Ok, tonight's check-ins added support for setting the min and max step delay parameters to the serial protocol, and the latest version of the perl library includes it (step_control()) as well as the latest check-in of slim (stepper command).
You can of course, run motors with higher torque (relational to load) faster, with faster velocities (smaller difference between min and max) than smaller motors, but depending on your load and capabilities of your gearing, you can tune how fast the motors will move.
!c
This weekend's check-ins
This weekend's check-ins included:
* Fixed issue with camera repeat cycle mixed with max shots, the logic went awry and any repeat cycle actions would continue to run forever after max shot reached. This has been fixed and everything works like expected.
* For actions: Increased step size and shot interval values to 16bits for motor and camera actions, making them more useful
* Added a 'set exposure' action - set exposure for camera to 16bit integer
* Added 'change direction or enable motor only' action - previously, it had to be combined with a set step size action, or any other motor action
* Modified step and direction values for actions, such that one can specify a hard direction change (0 or 1), or an inversion of current direction (2), or leave direction unchanged (3). This made actions MUCH more useful in the repeat cycle, and reduced their impact in normal use (like triggering a down ramp when another action may have changed direction)
* Added a 'trigger down ramp now' command, in addition to the action, to make it possible to manually trigger one when one feels like without going through the hassle of adding an action and setting a keyframe
* Obviously, due to the above, the action serial commands have changed in substantial ways, but the related perl code has been updated as well, meaning slim works with new commands
* Modified handling of 'repeat cycle complete' actions such that they are allowed to change motor direction (related to new action type listed above) - this allows on to do a 'rows and columns' type motion array without wasted movements back to home
!c