Submitted by shutterdrone on Sun, 04/25/2010 - 15:45
Posted in
All,
I've put together some demo code for a simple user interface using the engine directly, with 5 buttons and a serial LCD. This will enable one to create an engine-only package that can be used in the field for simple usage without a computer or GUI or any sort. (Advanced options are not available, however =)
The following parts are the ones I'm using:
Sparkfun Serial-Enabled 16x2 LCD: http://www.sparkfun.com/commerce/product_info.php?products_id=9395
Sparkfun Mini Button Pad Set: http://www.sparkfun.com/commerce/product_info.php?products_id=8996
Sparkfun Mini Button Pad PCB: http://www.sparkfun.com/commerce/product_info.php?products_id=8963
When ready, it will work with a standard arduino duemilanove. There are enough pins to handle the 6 required for the above setup (using 5 buttons, and 1 pin for the serial lcd). They can be any six pins, so all normal engine functions are still supported.
The basic controls I've laid out so far:
Up/Down:
Scroll through options in menus, set values. Can hold to scroll multiple times, or press once to scroll once
(in main menu) up: play/pause
Center (bottom center):
Go into menu mode from main screen
Select menu item
Save menu item
"do something"
Left/Right:
Select value positions
(right) go to previous menu
(right) cancel input of value
The button assignments will be a bit more obvious when I can show y'all a video later.
Anyways, if you want to play with the code (not yet integrated to the engine) you can download it here: http://openmoco.svn.sourceforge.net/viewvc/openmoco/OpenMocoInterfaces/arduino/demo_lcd_button/trunk/OM_BaseUI/OM_BaseUI.pde
One of the primary reasons I'm posting this is to get feedback on the menus, and here's what I have so far:
Main Menu:
- Movie Mode
Enter basic parameters, and have it shoot a complete timelapse film
- Intervalometer
Use the intervalometer, enter values for motor and camera through setup menus
- Camera Setup
For use with intervalometer mode, settings for the camera
- Motor Setup
For use with intervalometer mode, settings for the motors
- Do This!
Take a manual action right away
- Settings
Set up engine parameters used in all modes
Selecting the movie mode presents the following menu, each item also shows the path through that item
- Time/Length
- Real Time
- Elapse Time
- Movie FPS
- Motors
- Distance
- Manual
- Ramp
- Start
This is the 'simple movie mode' it doesn't require much thinking: you say how much real time should pass, what the output length of the video is (elapse time), and the fps of the video. It sets the intervalometer directly from this input. For each motor, you can specify how far to go (10 inches, or 190 degrees), or you can go into manual control to set home and end points. You will also be able to set points in manual controls to start other motors, etc. Ramp specifies how many shots to ramp up to full speed. 'Full speed' is automatically determined based on movie length and distance traveled.
Intervalometer:
- Seconds
- Start
This is pretty straight forward. It's how to you make a film without using the simple movie mode. You can setup how the camera and motors operate before starting the intervalometer, or use the camera/motor settings menu to change parameters on the fly.
Camera Setup:
- Exposure
- Tap Focus
- Post Delay
- Focus w/ Shutter
These settings should be fairly obvious for those familiar with the engine =)
Motor Setup:
- Enable
- Travel Distance per Shot
- Direction
- Ramp
Again, this should be pretty obvious for those used to the engine - these are basically analogous to the slim set_motor parameters. One has to select a motor.
Do This!:
- Ramp Down
- Shoot Now
- Manual Motor
Ramp down triggers a downramp for a given motor if program is running. Shoot now shoots the camera a specified number of ms whenever you want. Manual motor allows manual positioning of motors (will do so in 'real-time'), setting keyframes, etc.
Settings menu will be specified later.
Any feedback, suggestions for the UI layout and flow would be greatly appreciated.
I'll post a video later of the UI in action (well, what's there so far), but the PDE downloaded above is ready to roll for just scrolling through the menus, etc. (It's just the UI, see the file for pin assignments.)
!c
I found this site about a
I found this site about a month ago and I love this. I have a little experience with Kuper Moco so this is way cool! I can't wait for this to be included in the engine software. I am working on building a timelapse rig so this is timely. The menu system looks good. Could you include slewing for setting up the move and make it possible to define a move with keyframes. This may be getting to be to much for the little arduino to handle but maybe not. Also in setup would it be possible to slew the motor to find the number of steps for say 1 inch or degrees of movement and then use that use that to interface with and let the arduino figure out the number of steps needed for the move.
Thanks and I am looking forward to learning how to use this.
Cheers
RC Fisher
VR Photography / Cinematography
RC, The engine already
RC,
The engine already supports keyframing, though it's a little different in how they're done from a traditional system to allow for flexibility. Basically, you can set a keyframe at the position of any motor, time passed, etc. and then you specify what action to call - it could be changing the speed of any motor, the direction, adjusting exposure time, etc.
"Slewing" is a little different than what we have now, but you can specify the velocity of "real-time" moves (how long it takes to get to full speed in "real-time" movement), in addition to defining ramps (how long it takes to get to full speed in "output video movements").
The "simple menu" in the engine will allow basic use - and will have some keyframing hidden under the hood, but it won't provide complete control in that perspective, as there's only so much you can do with five buttons, two lines, and a few K of memory =) The idea here is that people will write more advanced applications for computers, PDAs, etc. to do highly advanced techniques -- where one can play with a GUI, etc. The "Simple UI" that will be built into the engine is to allow for the engine to act as a small hand-held moco unit that will solve a large portion of the basic use-cases. (Including setting start and end points for a video, triggering other motors to move when a motor arrives at a certain point, in this way providing easy ways to supply keyframes, etc.) This way, most users will only need the little hand-held controller in the field if they're not going to be scripting massively complex shots.
It will, of course, allow one to specify the steps/rev and microsteps for steppers, the gear ratio of a particular axis, etc. And in this way allow a user to input distances as degrees or in/mm based on the type of axis.
Last night I completed much of the code for the value input, which I'm hoping people will find easier than some existing methods for entering very specific values (down to, say, six digits of precision for decimal values =) -- basically, the value is displayed on the LCD with a cursor, and the left/right changes the cursor position on the screen, up and down change the value at that cursor (0-9, ., and blank). It also fills in the gaps, so if you started with a value of '1' and wanted it to be '1.005', you would press right once, up to select '.', right three times more, press up to select '5', and then the zeros would be filled in for you.
!c
!c Any idea when this will be
!c
Any idea when this will be included in the code and publish the hardware schematics? I am working on putting together a system this would be cool to include.
Thanks
RC Fisher
Chris, this rocks ! I'm not
Chris,
this rocks !
I'm not aware if it's possible with the engine, but have you thought about a go-motion feature (I'm not sure if this is the right topic, or should it be moved to 1.0 wishlist ?..). That means to deliberatly move the camera while exposing to get motion blur. So it would be like a negative post delay, if you know, what I mean.
If possible, it would be great if there would be a bracketing feature in the camera setup menu, so you can do multiple exposures with different exposure times.
There is a arduino shield with a lcd and pushbuttons by DFRobot (http://www.dfrobot.com/?product-245.html), which I have used for a small project recently. I like the sparkfun stuff, but this is a little bit more compact. You might want to take a look at it.
Matthias
RC: I'm working on it as we
RC: I'm working on it as we speak, the code hasn't been integrated in with the engine yet, as I'm still working on the basic functionality, but the code is here: http://openmoco.svn.sourceforge.net/viewvc/openmoco/OpenMocoInterfaces/arduino/demo_lcd_button/branches/scroll_input/OM_BaseUI/OM_BaseUI.pde?view=markup
I expect to have it integrated in the next week or two, and will publish schematics and tutorial on how to assemble it all.
Matthias: We should definitely talk about that. I always call it "hybrid" motion (it's a hybrid of continuous and shoot-move-shoot, you could say =) The right place is the 1.0 thread, as it's dependent on the async motor control. Which, now that I have a working model for, will be included right after the UI.
I had considered the DFRobot LCD shield, but it uses too many pins =( The combination of the sparkfun keypad and the serial lcd uses only six vs., the dfr's 8. The DFR shield is also "fixed" in its pin assignments, spreading out the motor drive pins and making the async motor control too slow. (I'm using a single PORTx register to set all step signals with two cpu instructions). In addition, the U.S. supplier for DFRobot (Robotshop) is really frustrating to deal with. They sit on orders for nearly a month before shipping, even when the product is in stock. (I'm still waiting on the last stuff I ordered from them.)
I do think it would be fairly simple to port the code to handle the DFR shield though!
I wrote a library for the serial lcd to make it easy to use, and every function can be handled with a single pin - any pin.
One thing I had to abandon for code size's sake is the concept of positional input. Where you would input values by moving the cursor left or right and then scrolling up or down through the available numbers (0-9, ., and ' ' to clear a value) to input a value. It worked quite well, but the required use of strtod() and dtostr(), along with utoa/atou caused the code to explode in size. strtod() uses 2k of memory alone! So, I've done a basic hold up or down to increment/decrement the value. To make life easier for big runs, the longer you hold the button down, the faster it gets =) It takes about 15 seconds right now to scroll from 30,000 to 0. I'll make it faster too, just to make life easier.
!c
Well if you are running out
Well if you are running out of pins and space for the program then maybe a version that runs on the Mega. Would that make the UI easier? For my project the Arduino is going in a small pelican case so there is room for the arduino and stepper drivers and connectors. I use Amphenol CRC connectors which is what my other moco system uses and I have plenty left over from that project. That limited my case dimensions with 3-4 S/D outs and 3-4 stepper driver outs plus camera connectors (for 2 cameras), power, LCD and buttons. My goal is to make the controller as adaptable as possible for a small package.
Cheers
RC Fisher
!c I forgot to say thank you
!c
I forgot to say thank you for your hard work!
Cheers
RC Fisher
I have used the DFRobot LCD
I have used the DFRobot LCD for my studio controller. It a great compact shield, but as said it uses a lot of pins. @Chris: I sent you an email about that project; did you get that?
RC - anyone can definitely
RC - anyone can definitely use the mega. I don't have any myself, and with so many of the non-mega boards sitting on my bench, I'm trying to keep it compatible with both *grin* Thanks for the kind words!
Cronix - sure did! I apologize for the slow response, my email queue is pretty backed up right now, but I'll be getting back to you in the next day or so. I think you should definitely share what you've been working on.
!chris
I would be interested to see
I would be interested to see if anyone has been working on porting this UI for DFRobot LCD Shield (I have one and was planning on using it for my prototype) By the way I ended up getting DFRobot - clone off the eBay from Hong Kong for about $8(USD) and it arrived very quickly.