nanoMoCo prototype

Hey Andre,

I will share the Eagle files publicly as soon as the changes I've made are tested (added LEDs and all that stuff, tweaked some things) - but I can also email them to you in the mean-time. And, if you want some PCBs... My proto batches usually come w/ about 60 boards in this size, due to the panel size!

A separate camera controller is definitely in-line with the concept and design. One of the shared lines is specifically intended as a "camera sync" line - that is, all nodes but one are slaves to the sync timing, and the "master" node (-not- the "control interface", but the one which originates camera timing - although they could be one in the same) changes state on this shared line when the camera cycle has completed and any SMS or post-shot activities are clear to run.

As for PTP, to be honest, I'm not a big fan of doing this on the Arduino! Limiting support to one or two camera types, and a whole lot of writing software vs. using a platform that's already made for doing this, has good open-source libraries, and lots of local storage available (say, through SD card), would make a lot more sense in my mind. The cost would only be -slightly- higher using a SC32416-based processor running linux, or even better - an S5PC110 running @ 1GHz - they make modules for these such that all you really have to design is the connectors (like USB, it supports it, you just have to wire up the interface). These can be gotten fairly inexpensively even in single unit counts (< $50 for SC32416). Check out: http://www.armdesigner.com/MINI110.html Then, running linux, it could easily handle gphoto2 for camera control and copying images back to device for any further processing/backup... Could even run a GUI if one really wanted =)

But, if one wanted to have a "canon models x,y,z" and "nikon model a,b,c" kind of firmware setup, it would probably work out ok w/ an ATmega device, I would just normally want a lot more firmware space for PTP/MTP control due to the size of a generic library like gphoto2.

It's definitely a concept to run without a computer connected - the nodes still operate independently and are only configured via the control interface. Some settings are moving to EEPROM, but not everything. A ptp-style camera control, of course, would need a lot more information in EEPROM.

Eagle is just a matter of practice =) Once you get comfortable with the fact that you have to design nearly any part you come across (create a new library and footprint for it), then you will be at peace with Eagle. The routing takes patience, but is quite rewarding when it works!

!c

Joao, hmm.. Is SPI the only available method? Would need to re-route some pins to use hardware SPI, since I'm using MISO and SCK for the camera controls, not to mention, would need to add another header for the SPI connection. Or, at least replace some of the existing outputs with the required pins miso, mosi, ss, sck.

Definitely can use some of the GPIO pins for sensors - switches would be easy to wire up, as would encoders and other higher-speed inputs, since there are two HW interrupts at the ready.

Don't know how long it'll take to get boards made and assembled, but I should have the next round of prototypes done in a couple of weeks, after everything comes in.

!c

Oh, no worries - yeah, it has TTL UART, which you can use instead of RS-485. The nodes don't actually talk amongst themselves, you control the network from outside. The shared control lines handle signaling between the nodes in the TLE-style of operation. That is, the arrangement should be largely familiar - you configure the nodes (either pre-configure, or send commands to them as you go) like with the OMTLE, except you select one on the network for a "timing master" when doing shoot-move-shoot, and it just signals the rest whenever a shot is complete and they are clear to operate. In fact, right now, it's just OMTLE with required changes for network operation - that is, there's now a command packet header that creates a start sequence and has addressing, so that no one gets mixed up and sees the middle of someone else's command. I'm working on ripping out the multi-motor stuff, and changing the way "keyframes" operate to make more sense in a moco setup, so instead of the combination of actions and keyframes, you'll set points the motor should arrive at, at certain times, and it'll figure out (based on other parameters), the right way to get there. So, that gets simplified, but the ways in which it can get there will be more rich (continuous, shoot-move-shoot, and it will always be asynchronous - so no more blocking moves). Real-time control will be much easier, etc.

There will still be some actions, like for camera repeat, but freeing up the old keyframe/action stuff will make available a lot more points of freedom in a pre-set program - I'm thinking 32 points in space for starters, maybe more. Basically, each point is a distance from the home position.

Serial protocol isn't documented yet, b/c there're a lot more changes to make, but I have a (mostly) working multi-threaded Qt/c++ library now, and slim/perl libraries are working with the current dev version. That is to say, the only difference is the start sequence =)

All commands, except status requests, will also end up supporting "broadcast" messages, i.e. - all nodes start now, stop now, or move 100 steps. Status requests, obviously, would be a problem for the controller =)

Of course, you don't necessarily need a "timing master" node, you can make them all slaves and control the timing line from the other device, to tell them when to advance. But, to talk to all of the nodes from your wi-fi enabled PIC, you'll need to talk over RS-485. A driver's a few cents to convert from TTL to RS-485 and really easy to wire up. (Otherwise, how do you communicate with each? Would you want some serial com then repeated from one to another node? How should responses return? Should this block other operations? Some questions raised there.)

!c