Engine v1.0 Goals

I'd like to see the following:

• Support for bulb exposure ramping (linear, logarithmic, manual intervention, etc.)
• Selectable DC motor (PWM) or Stepper control
  
  • Tie to bulb ramping for DC motor control such that when interval increases, motor slows down to keep motion speed the same (even if objects move faster, motion should be smooth)
• Built-in minimal UI support (few buttons and LCD, control for basic options) to provide the cheapest field-ready unit
• Support for SPI-based peripherals (bluetooth dongles, other devices, motor driver boards, etc.)
• Continuous-motion stepper control

!c

Jay, one of the first things that jumped out at me about bulb ramping, was that it just couldn't be used with a continuous motion system unless the motion system was aware of the exposure time and adjusted accordingly. Otherwise, as night hits - not only do the clouds start speeding up, your dolly move goes rocketing off at warp speed!

!c

Cronix,

We'll need to make sure it still runs on the basic arduino, or have to start using #ifdef's heavily in the code. The mega, even the off-brand ones, are still quite a bit more expensive in the U.S. than the regular ones.

I highly suggest using SPI for what you're talking about. Each device could daisy-chain into the next (like Camblocks), and you can control up to 16 pins with a 3 or 4-pin SPI connection. Alternatively, i2c works very well too - but requires more difficulty and a more expensive buffer chip at each connection.

You can simply send an SPI command that toggles a particular pin on the remote device to turn it on. If that device had a simple buffer chip, it could run your FET or whathaveyou, to enable/disable power.

Many of the multiplexers also support 2-wire normal serial, so you could just use SoftwareSerial and two pins! If you look at the ADG738 from Analog, you'll note that it's a fairly inexpensive way to drive 8 pins from 2.

You would also be able to daisy-chain dozens of them, using only three-four pins =) I've been talking to Brian Schmalz (the easydriver developer) about productizing the quad driver he developed, and that's how it works: SPI + Daisy Chaining = a lot less pins. He's tested up to 64 steppers at a rate of > 1,000 steps/sec with no issues.

You should already have the three pins available though, if you're just running steppers and camera. I have six pins unused on my regular arduino.

Let me wrap back around though, and talk about how to enable you in your journey as part of the engine, without changing your hardware design.

Would you say it's worthwhile to add a feature to support individual stepper kill lines? 0.82 already has a shared line, and properly brings it low/high (configurable) before and after making moves, and works quite well. The additional feature would be to add motor-specific kill lines to the engine. Not hard at all, and there would be no issue with conflicting pin definitions on the non-mega if one doesn't choose to use it.

!c

OK, I think we can tie all of the human control up under 'basic UI support' - where a user can have buttons, etc. to control basic parameters. Then, we could map what controls what.

For the joystick -- I take it you guys would like asynchronous stepper control? I don't know how you could effectively control the steppers via a joystick in real-time without it. I.e., one has to both poll the 2-4 analog pins representing a joystick, and make changes to the currently-moving motor on the fly. That is, if the user presses further to the right, it should move faster, and if the user lets off the JS, it should immediately stop.

EDIT: I haven't forgotten about SPI questions btw =) I like the idea of driving steppers via SPI, but also still supporting direct step/dir controls for those who want them. Although I think it can only work as a decision at compile-time (well, and still be efficient =) -- having the option there is very important to me.

!c