Submitted by lightforms on Thu, 05/06/2010 - 11:41
Posted in
I have been reading through the site for the last little while trying to get my head around a few things. While looking for software that had the functionality I was looking for I not only came across this project which I think is fantastic, I also found Dragon Stop Motion
Dragon stop Motion
I understand that openMoco slim works off a computer and Dragon stop motion has the ability to talk back to the arduino boards. I'm wondering could the two be combined dragon performing image capture to computer and Moco taking care of motion control or are they incompatible?
I can see several advantages to doing this the fact that the dragon software has far more control over the cameras settings and a good set of live feedback tools.
Also the ability to take a video feed for the time lapse means less wear on the cameras shutters. Ive already killed one on my 40D through using it for TL, obviously there is a trade off here in resolution but given that your already putting the camera where you want it with the motion control I see this as less of an issue.
I understand that what your doing is open source and Dragon stop motion is propriety but none the less I like the idea I would be interested to know if this is possible and if so what your thoughts are?
Cheers
D
PS feel free to move this post if you feel it would be better somewhere else.....
PPS I would just like to say that I am in no way affiliated with Dragon..
D, Dragon can certainly
D,
Dragon can certainly integrate with OpenMoco. The Serial protocol is fully published in the Documentation section, and exposes all capabilities. Someone just needs to add support in Dragon =)
!c
You basically just need a
You basically just need a second arduino. You can download a sample arduino program from the Dragon website, which allows to control Dragon from a external controller, like a Kuper or any other MoCo System, like our beloved OpenMoco. Then you just use the camera trigger to trigger DSM.
It's really easy. The DSM serial protocol is even simpler than the OM ;-)) (4 or 5 commands, if I remember right). To trigger a shot, you just send "S" and the number of frames via the serial (USB) port. That's it.
I made a box for a friend, which allows to delay the trigger, in order to accomplish go-motion shots with a Kuper System using an arduino and a DFrobot LCD. Didn't take long and wasn't expensive. ;-))
Matt
If you have the Dragon
If you have the Dragon Library (which you can donload from their website), it's even easier:
// When input pin 2 goes LOW, send DSM a SHOOT 1 frame command
dsm.activatePin(2, LOW, DRAGON_SHOOT_CMD, 1);
I did it the hard way:
Serial.print("S ");// from DSM Simple seria protocol
Serial.print(1);// 1 frame
Serial.print("\r\n");
Thank guys I did wonder if
Thank guys
I did wonder if the easiest thing to do was to just use two boards. Im new to all of this I am curently waiting for my first board and motor driver to turn up.... Do you need two boards because they are running slightly different programes or is it because MO uses all the pins avaliable for motor control?
Thanks
D
D, The thing here is that
D,
The thing here is that Dragon already has an established serial protocol, and it's very different from the OM protocol. One can either modify Dragon to talk to the OM engine, and tell it how to setup everything on the engine (a fair amount of work), or one can use the OM engine as a "control" for Dragon.
By using the second arduino running the dragon sketch, you can then setup the engine as normal - but run the camera control line to the dragon arduino, and it will simply tell dragon to fire the camera when you need it to. Just make sure to set the post delay on the engine to a value high enough to account for the time Dragon is going to take firing the camera, otherwise your motors may move during the frame.
!c
motors moving during the
motors moving during the frame , hey we finally got go-motion ;-)))
Chris,
how about this:
========================================
Camera control functions
========================================
*/
void fire_camera(unsigned long exp_tm) {
// don't shoot more than the requested # of images
if( camera_max_shots > 0 && camera_fired >= camera_max_shots )
return;
digitalWrite(CAMERA_PIN, HIGH);
// start timer to stop camera exposure
MsTimer2::set(exp_tm, stop_camera);
MsTimer2::start();
//Dragon support
Serial.print("S ");// from DSM Simple serial protocol
Serial.print(1);// 1 frame
Serial.print("\r\n");
//end Dragon support, serial needs to be set at 57600, according to DSM protocol
// update camera currently enaged
// (turn on bit)
action_status |= B10000000;
return;
}
OM with naive...ehm..I meant native DSM support. What do you think ?
Matt
That will only work if you're
That will only work if you're not using anything else on the serial to configure the OM Engine =)
Otherwise, you'd have to have two processes on the computer accessing the serial port, and the one running slim (or whatever) would be corrupt if it got the buffer before dragon did =)
FWIW, you can almost always achieve 'motors moving during the frame' by setting camera post delay to, say, erm, 0 and using the camera to control exposure time =) that means there would be no delay between letting go of the shutter trigger and moving the motors.
!c
Once a programm is running,
Once a programm is running, you don't really need to have any serial communication, do you ?
It's a cheap workaround... in the end, a second arduino is not that expensive.
Matt
Quote:Once a programm is
Quote:Once a programm is running, you don't really need to have any serial communication, do you ?
Granted =)
!c