Submitted by Matt on Mon, 05/17/2010 - 15:29
Posted in
I was wondering if realtime moco is possible with the OM engine by just changing the interval timebase from 1 sec to 1 frame (that is 40 milliseconds in PAL world and some odd value for the 60 Hz countries...)or shorter intervals.
I can't think of a reason why this should not work, but I didn't dig into the code yet. Is it possible ? Is the Arduino capable of doing this ?
Just thinking...
Matthias
Well, it's a matter of
Well, it's a matter of whether or not your moves can actually be completed in that time =) 0.82 still has 'blocking' movements on the stepper. For the next release, it will have "asynchronous" stepper control, which means movements can effectively be interlaced with other activities. Still though, to shoot one frame every 40ms, and make movements... It's not a matter of what the arduino can do so much (it runs at 16MHz =) but about the rest of the equipment: can the camera shoot fast enough (or are you just tracking movements to a time code input?), and can the motors make the movements you want in the time you ask (is the voltage and torque high enough to move the load at the rate one is asking).
I have gotten step rates close to 10KHz using a single motor with the new technique I plan on implementing -- that's at the highest speed though, one still has to count the velocity ramp into stepper-based moves.
How many steps are you planning to make between each 40ms "interval"? That's the real data we need to see what can be done. If it exceeds a few thousand, it will be unlikely and would require dedicated motor control hardware.
!c
... to separate out some
... to separate out some questions I have from above:
* What do you mean "real-time"?
** Synchronizing with a film or other camera that sends a time-code such that motions are synchronized between frames
-or-
** Firing a high-speed camera every 40ms or so and making movements between them (presuming shot exposure is on the order of a few mS)
* What type of motors are you driving?
The motors are going to be your biggest limit. To achieve extremely high step rates at decent-sized loads will generally require running well-north of 12V. Think 36-120V DC with a motor with 400 oz/in of torque. The torque and voltage have to be pretty high to bring the velocity curve to the shortest period possible. Lower voltage and lower torque motors will have to spend more time "coming up to speed".
!c
I was talking about syncing
I was talking about syncing to TC/ shutter pulse of a film or digital cine camera.
I use 1,6A Nanotec stepper motors, driven by microstep drives set to 1,6A. With a proper balanced rig, it's no problem to move a Canon 5D with a 24-70 around. I imagine a small HDV or DVCpro HD camcorder should be fine too, if well balanced. I would think that a few hundred steps will be sufficient for a move in a 40ms interval ( I get about 30000 -40000 per 360 degreee, depending on the axis, so 40000/360= 111 steps/degree)...
I'm totally aware that for fast motion of bigger cameras large hardware is needed, but I'm rather thinking little: small cameras, little weight, slow moves. At least for now...;-))
If I understand you right, it's just a matter of the async motor control ?
Matthias
Basically, yes, async motor
Basically, yes, async motor control would be the starting point. The second would be linking the control flow for stepping to an input.
For this case, one would do two things:
1) keep the motor control code running at a constant interval. i.e., just use flags to enable or disable stepping. (Async does this, but doesn't keep the control code running constantly - only when needed, so there would be a change needed here.)
2) use a pin change interrupt to monitor the sync line (like how ALT I/O works as an input - set it to fire off an ISR every time the pulse is rising).
So, in this cause, if we set, say, Timer1 to fire off an ISR for motor control every 10uS, and in that ISR it uses flags to see if the motor should be stepped, then we know that we can have a maximum response time of around 10uS to any change in motor requirements. Now, if you combine that with a pin change interrupt watching the sync line, so that it 'enables' motor movement by setting the required flag every time the pin is brought rising - voila! You now enable the motors to step every time a rising pulse is measured on the pin with the pin change interrupt (your sync line). The only trick is to make sure the motor control part can handle the movement required before the next pulse is registered on the sync line.
What I meant was not about how beefy your motor was, or what it can move now, but at what _velocity_ it can move. For example - my little 9 oz/in 650mA motor can move 10lbs of gear around with its 120:1 gearing. BUT, it also requires a long velocity curve to reach maximum speed, else it stalls. There is where the combination of torque AND voltage are important. The higher the voltage, the shorter the velocity curve you can use with most steppers.
By velocity curve, I mean "how long it takes to get to where you can step at full-speed." If you max step rate (speed) is 10,000 steps/second, then one would likely presume the delay between steps to be 100uS - however, with most steppers, if you attempt to _start_ moving at this speed, it will stall. So, you need to "curve into" and "out of" the movement, by starting with a longer delay, and decreasing the delay between steps until you reach full speed - likewise for slowing down. This really wouldn't be an issue unless you can _only_ achieve your 100 steps in the time allotted by moving at the maximum rate for each step. In this case, you'd reduce your gearing so that you can do fewer steps, or increase the voltage to your steppers.
To increase the velocity of my CNC machine, I run the steppers at 36V. I get much better velocity than I did at 12V. However, to increase velocity, I'll have to either get motors w/ more torque (to run at the same voltage), or increase the voltage to the motors. This is all secondary to how the code logic is designed, but it's important to set the right expectations =)
!c