Following on from my introductory post, I have revived my early prototype, cleaned it up a little, and declared it to be Prototype 1. This is still separate from the Parallella.

There will be a follow up post soon in which I will show the thing in operation - the Adapteva guys asked for a video. While videos are not something I've ever done before, there is a first for everything, so I thought I would give it a go. I'll get it hooked up to the Parallella first however.

The aim here is simply to show what I am starting from (which is not much), and I will then provide further posts as I iterate the design and make progress on the development.

At this initial stage, I wanted to show the (very) rough mechanics, and the AVR controller. I have not bothered attaching the USB host controller to the AVR as in my previous prototype discussed in the intro post, since I have a much better control solution in the Parallella (see posts on Camera Control). So yes, while you can use an AVR as the brains to trigger photos as well as controlling the motor, this is quite limited, and of no further interest to me. If you want to know how to do this, let me know, and I can point you in the right direction.

So what does it look like?

Like this.

If you want to see more, I'll include the remainder of the images at the end of the post.

Mechanics - why did I do it this way?

See the post referenced above if you want to know what it does (and will do once finished). Here is a rundown of why the current (first) prototype is as it is.

Reason 1 - Availability

I had previously purchased a tap/die kit, was looking forward to trying it out, and had been sorting all my salvaged screws (from PCs, printers, scanners, etc) into thread sizes). Now I needed a project which required assembling bits and pieces from old junk. So I had a fun time using the old noggin, and being creative with what I had already lying around. I had a week's leave, and the aim was not to do it right, get the right parts, and ultimately never get it finished - no, I decided I was going to use the wrong bits, but bits I had, and ensure I got something finished. I built this as well as a mini 3-axis CNC plotter using old optical/floppy drive slides (essentially complete, but I haven't hooked this one up yet).

Reason 2 - Affordability

This is made of 100% recycled components (didn't cost me a dime, other than the tools to make it, which I had, and possibly a band-aid or two).

• Stepper / gearing assembly in base is from a flatbed scanner.
• Servos are from a 1980s RC plane kit my father in law found in his garage and kindly gave me.
• Side beams are from a 3.5" to 5.25" HDD bay conversion.
• Horizontal bits are the dash mounts for vehicular mobile radios.
• Screws are all salvaged from old PCs.

Reason 3 - Apparatus

In order to understand why I did it this way, I should also note that I have no access to metal cutting / bending tools - I lack a bench vice or even a humble hacksaw. So all bending was done with pliers, and nothing could be cut to size - I had to find innovative uses for what chunks of junk I could find. I really used only a drill press, files, and a tap-and-die kit.

Reason 4 - Aptitude

I'm really not the mechanical type. I'm comfortable with coding and soldering, designing software/hardware - but real world interfacing is something I don't do nearly enough of - so I'm doing this to stretch my abilities, not because I have the knack. The robot revolution won't be wrought by software and hardware alone :)

What hardware?

The motor controller is a ULN2003A Darlington transistor array. I am using this since it is the only driver I have on hand for driving unipolar steppers. The scanner mechanism which turned out to be ideal for a rotating base plate (because I could drill holes directly into the plastic gear and mount the base of the upright component onto it via screws) has a unipolar stepper. For the bipolar variety, I favour the L298N which is a dual full H bridge chip, requiring external diodes.

As for the mechanics, I may put together a subsequent post where I tear down the whole lot and show how I threw it together (if this interests you, please do ask in a comment - because as I'm not overly interested in the current iteration moving forwards, this may not happen unless you do!)

At present, the electronics are based on a simple 8-bit AVR micro, the Atmega128A. This has 128kB flash, 2 UARTs, JTAG, and many features I don't require, such as a parallel Address and Data bus for external memory/flash interfacing. The code I am running is functionally so simple that you could run it on something much smaller, but this is the board I had lying around. It cost me around $6 to build it myself (I ordered in blank PCBs for ~$2, and chips for around $4 - and a couple of caps for managing noise and you're done.

True it is only running at 8MHz since it is using the internal RC oscillator, and I could double that using a crystal, not to mention much faster UART baud rates - but this will do for now.

Future improvements

So, what would I do differently in future? Pretty much everything. I will also take the opportunity to drill down into some of the details of what I have done in the context of how I will change them.

3D printed parts

Eventually, I plan to replace much of what you see here with 3D-printed parts I will design myself. A couple of months back, I designed the first part I would need, modifying a somewhat related part I found on somewhere like thingiverse. In so doing, I was able to teach myself OpenSCAD in an hour or so, as it is so simple to use - for some reason, this took me back to my school kid days using Logo on an Apple IIe). Unfortunately, the 3D printer I was going to use (my brother's) had developed an issue, and is not yet fixed, so no progress to report on this to report just yet.

Design the motors properly

Rather than just grabbing what I had on hand, I want to redesign the motors to get the correct balance of the following aspects.

• Speed - this doesn't need to be fast, am happy to trade this off for more important characteristics
• Holding torque - this is important, as the camera is not light, and the heavier the kit I can put on it and have it stay up, the better.
• Vibration - this is important, a servo / motor struggling to hold the load at the programmed inclination is going to mess up shots (especially long exposures).
• Accuracy - having small increments is good for pin point accuracy of angle. Not something I really need except for tracking a target. In particular:
  • You can generate a cool effect by tracking/shooting a moving target, where the target is in sharp focus, and the background a blur as you pan.
  • For tracking stars in the night sky on a long exposure, keeping steadily on the programmed arc is vital, or you'll get smudges rather than points.

So using servos for the pitch axis was one example of using the wrong parts. In particular, having two trying to work together turned out to be a bad idea. They do not track linearly respective to each other, and at any point on their arc, they won't move to the exact same point - so often one or both is vibrating. I did it this way in the first rough prototype for two reasons. Firstly, I couldn't think of a simpler way to provide a pivot at either end using the parts I had at the time. Secondly, because the camera is heavy, I figured the second servo might be required just to provide enough holding torque. It certainly holds it in place with two, and not sure a single one of the ones I had lying around would be enough.

Balance / centre of mass

In order to limit the amount of work the pitch motors have to do (mostly thinking of vibration here, for motors that do cause vibrations holding a heavy load in place) you need to balance the load. This allows the motor to do much less work holding the mass in place. However in the case of camera, where different bodies/lenses may be fitted, this will not be an exact science. Although, if I can, I would like to look into building in a sliding camera plate to allow changing the balance for the load.

On a related note, the current prototype can't incline the camera above 60deg from the horizontal without fouling the USB cable on the side beam. You can see this in one of the photos at the end of the post.

Gearing

In order to improve both holding torque, and accuracy (but at the cost of speed - which as I mentioned is not important to me), adding gears (or a worm) allows the motor to very easily hold the load in place (so with less vibration), hold a bigger load, and more finely adjust the position (due to the gearing reduction).

Electronics

There are two reasons I will change the AVR processor / board.

The first is cost. I built these ATMega128A boards almost 4 years ago, before you could get boards fully assembled for even less. I am referring to the likes of the Arduino Mini/Nano sporting the less capable Atmega328P (quarter the flash and EEPROM, half the RAM and IO) which seem to be enjoying the economies of scale resulting from the popularity of the Arduino platforms over the past 4 years. Back then, the cheapest fully built alternative was upwards of $15 - now it has fallen as low as $3 (and that can include XTAL and a serial <-> USB conversion). Hence other than when spinning my own boards (where I will use whatever CPU I like the look of at the time, so I get oodles of flash, JTAG, and other goodies), I will probably start using these cheaper boards - cheap enough to throw away (that is, put them in some project, and never need to recover them to use elsewhere later). As much as it irks me, as a veteran of this architecture being perceived as 'mainstream' by using Arduino hardware, I know when I'm beaten on cost.

The second is discussed later in the section on "Commitment to open source" - but essentially I want something that others can easily replicate. Yes, I write my code properly so a Makefile target is all you need to change between building for an Atmega8, an Atmega128 and an Atmega1280. So while I could get hold of a 328P (I think I even have some PDIP chips in a drawer somewhere) and port my code to that platform, I still think people newer to tinkering with micros will find this more accessible if I'm using a board they can obtain (it even has 'Arduino' in the name).

Software

I use FreeRTOS, simply because I like to. Yes, I could do it all with a single thread, and it'd be small enough to fit in an Atmega8. But I have been playing around with FreeRTOS on the AVR and Arm processors for a long time now, and simply re-use code between projects - besides, I am a masochist, so I like needless concurrency - at least in my hobby projects :). Currently my code (without any optimisation) would fit on a 328P (has a mere 32K of flash, 25% of what I enjoy now). And I intend to keep it there, because once I've cleaned it up, I plan to share it, and realise most people will be using the simpler processors.

Power

Not something I've even bothered designing yet - that will come much later when I want this to be portable. At present, I run the AVR off a 5V supply, as well as the servos - with the stepper being run from a 12V supply (it won't work below around 9v).

Reproducibility (open sourcing)

Another benefit of 3D printing the parts is it makes it much more accessible to the masses. There is only so much value in making an open source design based on odds and ends I happen to have in my garage. The idea is, at the end of this, if anyone wants to build one, either to use, or as a basis to further develop it with their own ideas, they should be able to reproduce what I have done.

Commitment to open source

I am committed to making everything open here. Exactly what license I will be using, I am unsure of yet. In some places, that will be determined by what I reuse. But where I am free to choose, I have yet to decide between MIT and GPL.

For non-custom items:

• Hardware - all the existing hardware I use will be open source hardware.
• Software - all existing libraries/tools used will be open source and freely available.
• Mechanics - any existing parts I use (if any) will be open source. All parts will be obtainable (i.e. eliminate servos you can buy this side of 1985, and motors/gears you won't find only in specific models of old scanner).
• Tools - only freely available tools will be used. Ideally open source where possible, but obviously not possible with e.g. Xilinx tools.

For custom items:

• AVR code - this will take some time - while being entirely written myself from scratch (so no licensing qualms), this needs cleanup before I'd be happy it was in a good state for someone to peruse it, and for me to support people trying to adapt it.
• BOM - once I am using more obtainable components, I intend to make a full list available, along with whether to get them.
• PCBs - any daughterboards / level shifter boards, etc I design and build will be fully open source.
• Parallella code - python scripts, C code, custom FPGA improvements will all be available too.
• Mechanics - as discussed, the 3D parts will be made available - since OpenSCAD files are "source code", anyone can freely replicate/modify/learn from/improve what I do here.

Keeping it architecture independent

I will try to keep in mind those with no particular interest in the Parallella (who do not own one, nor intend to) - since no aspect of this project (yet) really necessitates the awesome power of the Parallella - that will be leveraged by the potential applications once the platform is there. Because I consider the Parallella a worthy project, and support their cause, I will use it as my main development platform - and hopefully do the platform justice eventually. But anyone wanting to drive this from, say, a Beaglebone Black will find this just as doable - and I might post some guidelines for this platform eventually (but if you can't work out how to enable/connect a UART, and waggle your GPIOs there are umpteen tutorials around on how to do this...)

Any platform able to run Linux should be able to act as the host. If that is a laptop or a PC (driving the UART on the AVR via a USB<->serial dongle, and driving the camera directly via USB), a BeagleBone Black, a Raspberry Pi, or any board of your choice, I want to make it available for your projects.

This is part of the reason I am keeping the AVR, and interfacing to it via UART - this keeps the interface very generic. I will be providing a subsequent post in which I hook this all up to the Parallella, at which point I will cover the various connectivity options I considered, along with the advantages/disadvantages of each, so that you can decide for yourself which approach is best for you.

If you want to drive it directly from your Linux smartphone, be it via USB or BlueTooth, I want to make this possible (I might even provide an app). Do note that if you want to make your smartphone a complete replacement for the host, you will still need a strategy for connecting to and controlling the camera, as I do not intend to provide a USB host for the AVR as in my previous prototypes. Since cameras are coming out with WiFi, if your camera is modern enough, accessing PTP this way should be entirely possible.

The only limitation is really the camera itself, where you might need to cobble together a Bluetooth<->USB Host, say using a cheap Arm with integrated USB host controller, or put a Linux dev board in which simply acts as a BT<->USB bridge, and having all the brains in the smartphone.

For my purposes, as discussed in my introductory post, the smartphone will simply be used for controlling the host (which is a separate board capable of full controlling things via a number of control sources).

Further images

Here we see the controller in the neutral position. Same as intro picture, different angle. Off to the left is the USB cable used to control the camera (trigger photos, change exposure settings - I have covered how this is done elsewhere), alongside the 12V power supply for the motor. To the right is the gray box which is an Olimex USB-AVR-JTAG I use to load code into the AVR, and a small red USB<->Serial adapter I use for the control UART as well as supplying the 5V for the AVR and servos. In from this is the ULN2003A unipolar stepper controller.

Here we see the controller rotated to the left. You can see it has rotated on the base plate. Additionally, I have elevated the camera to the maximum angle (~60deg from horizontal) to illustrate the point at which the USB cable snags. You can also see the edge of the upright base catching on the tip of the protruding rotor of the stepper. Fixing the latter is just a matter of getting longer screws and more spacers.

Next we see the controller rotated to the right.

This is a shot of the AVR board I am using. You can clearly see all 3 components. The chip itself, and two decoupling caps. Pretty basic stuff.

With the camera removed, you can see the simplicity of the mount. This is simply a bolt (M6 or thereabouts from memory - this is absolutely the standard which every camera will have), and 3 nuts. To attach the camera, I just hold the camera over the nut, then twist the nut using a driver from the reverse until the camera is secured. Not the most stable mounting, as the camera could easily twist. I intend to replace this with a quick release mechanism - maybe one I print, or perhaps I can find one cheaply enough.

This is the servo gear, the pivot for the entire upper section holding the camera. There is one at either end.

This is the servo horn. I have affixed it by drilling a hole the right size for the horn itself, as well as two tapped screw holes to hold it in place.

And this shows the servo horn from the other side - you can see the tips of the screws coming through.

And finally the gearbox (ripped straight out of some hapless flatdeck scanner). In order to mount the upright section, I have simply drilled 4 holes in the plastic cog, and screwed the base down directly onto the gear.