Submitted by kevlarmedia on Thu, 04/16/2009 - 01:14
Posted in
What architecture (or coding language) does everyone want to create this open moco engine in?
Another thing to think about is what outputs will this support...
pySerial and pyParallel are working and have loads of documentation on python.org site.
Something that Dan Thompson has mentioned is that he's not confident in a realtime data stream over a serial connection. Any thoughts?
Another thing that needs to be discussed in the beginning is whether this is going to be a PIC based system. ie the output will be sent to a PIC then to drivers then to motors. Another thought is using you computer as the controller, and sending step and direction pulses directly over either your parallel port or serial port to your drivers, with only an optocoupler between the computer and the motor drivers.
Excited to get this journey kicked off with many brilliant minds!
Kevin
Kevin, Thanks for joining
Kevin,
Thanks for joining us!
Have you looked at the existing code I've provided? It's tested heavily and completely functional already on the AVR platform. (Aka the 'arduino' microcontroller.) I think we should consider other platforms as well, but I'm not entirely ready to abandon the months of work put into the existing code =) If you feel that there are deficiencies in the existing implementation, I would prefer to vet them out and fix them, rather than abandon it entirely.
In fact, it has everything covered except a stand-alone GUI. (And I'm beginning on one of those right now, to be run on a low-cost hand-held touchscreen interface [~ $150], again based on the AVR platform [Liquidware's Touchscreen Slide].)
There is an existing PERL API for the serial protocol that I've provided. We should support python as well, but I fear there's little help I can provide in porting to python.
I'm not really convinced that a parallel interface is the best choice. My reasons are three-fold: many modern computers do not come with a parallel port, and especially not laptops. The arduino platform has largely superceded the need for a parallel interface through the bootloader, and the primary interfaces (outside of the standard jtag interfaces, etc.) have been serial over USB, i2c, and SPI - which are all serial interfaces.
While I understand Dan's hesitation to use a serial protocol, this would be countered by the wide and large acceptance of serial protocols in general, and as you'll note from the code, I have no issues passing very large amounts of data via a serial protocol. I would even prefer an i2c over standard serial protocol, as it is fast, multi-point, and efficient with hardware support just like the hardware serial UART. The primary draw-back with i2c, is that a interim device would be required to communicate with the engine via a PC - increasing cost and complexity. Essentially, most low-level protocols are error-prone, and the higher order protocol and design should over-come these deficiencies.
I have been designing on the concept of engine and interface, each being independent and self-contained. That is, the interface does its magic interacting with the user, and tells the engine, at a low-level, what tasks to perform. The engine, once informed, executes its job autonomously. This allows a single engine design to support numerous use-cases, with each interface tuned to platform, use-case, users' level of expertise, and cost factors. For example, one could simply purchase or build an engine unit, and then either use an existing laptop or netbook, buy/build a low-cost interface built around a small lcd screen with a less user-friendly interface, or buy/build a higher-cost, fully graphical and easy-to-use stand-alone interface.
What do you think about the current engine and interface should be changed, or needs a design change?
Thanks - church
Kevin, I'm sorry if the above
Kevin,
I'm sorry if the above message comes through a bit unclear - it was rather late last night for me that I wrote it =)
Let me explain a little bit, I started on this project a while back, and have been working for some time to share and contribute different DIY techniques for moco/photography electronics on my blog roamingdrone.wordpress.com. I have been working on this OpenMoco project for some time as well to produce a low-cost hardware/software system that was completely open targeted at both the non-diy and the diy-types of shooters. That is, unlike other systems on the market, beginners could buy into a low-cost system that would be a basis for many different capabilities, and they would not be entirely locked into a single-source for software and extensions.
The documentation link here: OpenMoco Time-lapse Engine should give a high-level answer to some of your questions about what already exists. I know the documentation is incomplete, but I will be posting both the hardware schematics and completing the functional documentation shortly.
My goal with this site is to not only produce the OpenMoco system, but also to provide a place that can serve as a home for the diy moco community. The OpenMoco Engine I have developed thus far is the base for the "official" release, but I encourage branching, deviation, and specialization. I also encourage other open applications/systems, and I think this site will be a great home for them, and will support them in any way I can.
Milapse (Jay) is also working to get an application he had developed for the Meade DS (aka: 'milapse moco') head up and running on here, you can find the documentation under the Documentation link to the left.
I hope that we all can provide more than just software, but also articles explaining how to do different things, ranging in target audience from the complete newbie to the advanced explorer.
I take from your message that you believed that this was a project that had not yet begun, however, there is already a lot of work done, and a lot of time invested, and I hope that you would be interested in trying out what there is and expanding on that, as much as you are interested in a completely new solution.
!c
THE BEGINNING
Quote:Something that Dan Thompson has mentioned is that he's not confident in a realtime data stream over a serial connection. Any thoughts?
Hey Guys,
Just wanted to clarify what I meant about the above quote from Kevin. I was referring to a project that I am about to release on this site as a branch/deviation from the actual openMoco engine initiative shutterdrone was outlining earlier. It's essentially a realtime Maya to Moco Pipeline. It allows you to use Maya as an animation interface for Arduino controlled steppers or servos.
My main concern was not so much with the serial connection, but more the unpredictability of a openGL realtime Engine. The frame rate of the openGL engine depends on so many variables, ei. graphics and cpu hardware. So playing back a animated motion control move could greatly vary each time you run the move.
So the application I am working on would be more for previewing a moco move in realtime. Once you are happy with the move, you would then upload the Move Data to a SD Card, or some form of Ram for a more robust form of playback.
Shutterdrone, as for a Python Interface Port, I won't put up my hand just yet as I am still new to Python. But I will download the the openMoco Engine and the Perl Interface and have a play, just as soon as I get this Maya thing off my chest ;)
Dan - thanks for coming by!
Dan - thanks for coming by! Make sure you go to the SVN repo and download the latest branch (0.81 of the engine and 0.02 of the API) - I should have new packages ready in zip files this weekend, I fixed a few ramping issues and added some missing controls to the API.
I can't wait to see the Maya control pipeline! I agree that once you get involved with the high-level GUI abstractions, any notion of "real-time" is truly difficult. I think, however, your design seems to be on the right path -- primarily abstracting the motion from the Maya interface. I.e. your commands being simple "move left 4 degrees" and leaving it to the control engine to figure out what that means. The less control data the Maya machine sends, the less likely there is to be a missed execution.
Are you intending it to be "real-time" in that the camera actually moves as the screen image moves, or are you planning it to be scripted? I.e. the screen images shows the move, and then afterwards the real camera control repeats the move?
I did put the engine in my old TLA prototype last weekend and shoot some test video. Unfortunately, most of it's really boring to watch, and I'm not happy with the granularity of the existing prototype. I'm about 80% complete on the CAD for the new motor axis prototypes, and then hopefully will get started cutting out the first enclosures. House shopping, too, so it's a bit of a stressful time. BUT, you can't sit on these things forever as they say =)
!c
Dan - thanks for coming by!
House shopping nice! Good luck with it.
I'm Still adjusting to this forum. It's a bit confusing with the Subjects changing in the same thread topic. Also how do I subscribe to a thread?
A couple of answers to your questions:
- The whole of Maya is scriptable, you have access to everything! So in theory, you could build another high level layer of commands to drive the virtual stepper. But at this stage I am just working on the core building blocks.
- The plugin I have written makes it possible to create a custom node in maya(think lego bricks). The node is connected to the output rotation of any object in maya. Those rotation values are sent to the node which calls an abstraction layer of python code. This python code executes every time the maya node receives a new value. The python code uses a module called pySerial which sends the serial over the USB to the Arduino. It sounds complex, but really It's just a lot of small, simple pieces :)
Here's a video I just uploaded showing the basic idea. http://www.vimeo.com/4324899
I've also been working on some vector icons and starting to play with processing. We should have a chat at some stage about the GUI design. I imagine you have some stuff in place already with your touch shield. I don't want to double up if you have a working design already.
To start with I will be writing my gui library in processing. But I imagine that it won't be too hard to port to sub-Processing. But let's not get ahead of ourselves ;)
Status / The AVR platform
Hey guys,
Sorry its taken me so long to respond. I've been slammed trying to finish renovations on my new house. Getting settled into a new place can be stressful as most of you probably know.
Dan - thanks for clearing up your concern with the ability to run realtime... This is a big help!
You guys are a lot further along with things than I thought! That's super exciting. I still haven't tested out your code for the Arduino platform, however it on my to-do list. So far my moco project is a 4 axis motion control crane. I'm utilizing NEMA 17 steppers for the pan and tilt axis' (with step / direction drivers) and Pittman LO-COG DC motors for swing and lift (with Gecko servo drivers). Mechanically everything works for all of the axis' so now I'm focusing on the software end of things.
My approach thus far has been an attempt to create realtime control via step and direction pulses over the parallel port. I started this way because the machine that milled my moco components was built this way and used a CNC software called Mach3. Though this works, it is difficult to program moves since it requires use of G-Code.
So I'm now starting to think I might want to try and use the Arduino card to control my rig. I really like the endless possibilities for the UI and the modularity of the engine you guys have built. I was looking through the moco engine docs and saw that it currently supports only 3 axis'... is this a limitation of the arduino card? or the amount of data that can be sent over serial?
I'm also curious if there are plans to support non linear motion in the future, so one could ease from one position to another?
Be in touch,
Kevin
Dan, I'm super excited about
Dan, I'm super excited about the concept of integrating and designing moves in 3d software! Do you think it will be difficult to migrate the foundation your building in maya to max?
Dan, I'm super excited about
Milapse,
I have used max about ten years ago (I don't think that counts). I don't know any max script or how to write plugins, but I have seen this video which leads me to think that it's possible.
Do you use max? I'd be happy to give you the gritty details if you want to give it a go. It will probably be a few weeks before I start putting any info about the tools up on the site. But if you can wait till then?...
Hey Kevin - that sounds like
Hey Kevin - that sounds like a great rig, I'd love to see photos of it! Still getting my CNC up and running, if I buy a house in the next month or so, it may slow me down a bit. (I have to build a completely contained enclosure right now because the CNC is right in the middle of my living space, but with a garage, I wouldn't need that.) I'm familiar with Mach3, as that's what I've been using to run movements (cutting air) on the CNC, and I definitely wouldn't want to do G-Code for photographic motion control =)
The reason why it only supports 3 right now is basically because, well, I stopped there. =) There are plenty of I/O pins available, just would need some re-mapping out in the engine software, and the hard limits in the code removed. I got lazy and made all the step/dir pins sequential to reduce the code size (i.e. byte pin = MOTOR0_STP + 1), so that has to be kept in mind when adding the new axis pins, otherwise, you should be able to do 4 axis w/o issue, more than 4 would require a change to the keyframes and serial protocol code (they allocate 2 bits for motor #, allowing 4 motors). If run on either an Illuminato (http://www.liquidware.com/shop/show/ILL/Illuminato), the Teensy++ (http://www.pjrc.com/teensy/), or the Arduino Mega (http://arduino.cc/en/Main/ArduinoBoardMega) -- it could easily support 30 or more axis.
I did some more refinement on the engine this weekend, as I realized some of the possible transitions didn't go as smoothly as I liked. (for example, once a down ramp had been completed, the motor was set to move zero steps, I changed it to when an axis completes a down ramp to zero steps, the motor is disengaged and all ramp counters removed, this makes it easier to create motions where you say, pan left for a while, ramp down, stop, wait a bit, set the pan to right, ramp up, trigger ramp down, change motor move rate, pan left, rinse, lather repeat, etc. =) I'll update the 0.81 branch tonight with the changes, and try and push out a new zip package for those unfamiliar with SVN.
Dan - I realize this forum lay out is kind of insidious. I think forum is a misnomer, they're really pages w/ comments. I'm still looking into a better software integrated with Drupal, forgoing that, I may just install phpbb.
!c
the next step
Wow, I couldn't imagine running a cnc mill in my living room. That's dedication! Yeah programming with g-code was a nightmare! Cutting air... Ha I remember doing that with my dad several times... What CAM software are you going to use?
I'll try and get some photos of the rigs current condition and post them soon. Also I didn't mention this before but the rig has been designed with a heavy video camera in mind. I haven't done any weight tests yet but I'm guessing a 30lb camera will not be a problem. Everything is in my dads basement next to his cnc machine.
I looked at the Arduino Mega boards and was considering pulling the trigger on one. Can you move multiple axis' move at once with the Arduino's? I've heard many people debating on different forums that they can hiccup with that much data passing through them. Also another thought I was having was if controlling high resolution servos was going to present any problems. If you look here you will see a basic diagram of my rig and the swing axis.
The swing axis is driven by a Gecko G320 servo driver and needs 13,977 step pulses to move the crane arm one degree. I know its a bit of overkill... I can add a gecko G902 card to reduce the pulses requires by 1/2, 1/5, 1/8, or 1/10th.
Any thoughts?
Kevin