I have a very specific development cycle for projects like this. First build something out of legos and see where the difficult bits are. A twisted rod or a brick flying off is a pretty good indication where one might want to rethink structure and power transfer. After this step I figure out what materials are best suited to make the unit proper. This often results in something that has great potential for improvement, resulting in a rebuild. This is why a lot of my projects will carry at least a Mark III label when I get it to work the way I wanted.

This project however, is amazingly stuck at version II and it's fully featured and damn near complete and perfect for my needs. What gives?

To be honest, the layout, electronics, software and mechanics of this thing have changed so many times (in small iterations), that I could possibly call this Verto Mark VI or thereabouts! This means that the projects evolution is far more interesting than the actually spinny-clicky bit, which is quite mundane if it just works (and very irritating when it doesn't). I'll try to describe the concepts, learning curves and thought processes that went into this thing.

Need a spinny photography thing

I do a lot of object photography of archaeological artifacts. This can be pottery of various shapes and sizes, small objects like coins or valuables and other interesting objects we dig up. In a lot of cases, two or three shots just do not do the object justice, so I wanted a turntable to easily record batches of objects and publish them as virtual objects or perhaps 3D objects after processing. This is a pretty nice way of presenting the objects and it is also useful in a digital referencing collection sort of way.

So what I needed was a fast, flexible, repeatable process that could handle the entire range of stuff I get to dig up and take pictures of.

Verto Mark I

The Lego prototype worked remarkably well up to a few kilograms, but the plate wandered just ever so slightly and with heavy objects, the drive could not keep up. The image processing also left something to be desired and the NXT motor hitting the space-bar to snap a picture in my motioncapture software was...True to the bodgers ethos..

Verto Mark II.0

For the rotating bit, I found a cheap rotating plateau at IKEA mean for presenting cakes or something else extremely necessary and useful. It used a lazy Susan which looked like it could support wedding-cakes made from uranium, the the plateau wasn't centered very well. After remounting the plateau I started to build a case for the unit.

In the parts bin, I had a continues servo and some *duino boards. I rubberized the bottom of the plateau by gluing rubber bands to it. Yes, I was planning on using a continues servo as a friction drive.. Extremely bad idea! Not because it doesn't work, but because it almost works, but never quite!

First of all, I completely forgot that you can't control a continues servo like a normal one, meaning that I needed to need to rotated it based on time (and power). Well, this started out promising. With a bit of tinkering, I got the unit to do large steps and end up pretty much where it started, but for small steps it completely failed do to accumulated slippage on the rubber.

Then there was the problem of power. I wanted the unit to operate on batteries for some odd reason (because in the field, shooting conditions are so predictable and nice!). Naturally with different batteries and voltages, the travel of the plateau differed necessitating a calibration nearly every damn run.

Mark II.1

I needed to know where the damn platform was so I needed a form of rotary encoder in the platform itself. The servo would not work because of the slippage. So what I did was the most reasonable choice, surely! I gutted an optical mouse (I'm obsessed with mice?) and wired the ADNS sensor directly to the Arduino. The remainder of the mouse was put on spring suspension and jammed against the plateau. Now I could read the movement of the plateau and correct for any slippage or inertia problems. That is, if it would actually work!.

No matter what I did, patterning for the sensor, using the vector result of the X and Y, slowing it down, speeding it up, would give an accurate reading. This was not going to work! I needed an accurate rotary encoder type of device.

So for Mark II.2.1 I took the same mouse, took the scrollwheel and stuck it on some prevboard. Again jamming it against the plateau and reading the value with the micro. All in all a very good lessen in "how low the resolution of a scrollwheel really is!".

Mark II.2

I ditched the servo idea and came to my senses, concluding that I really need a stepper drive. Why I did not continue my journey on the path towards clarity is beyond me, because not only did I not ditch the friction drive idea, I rebuild it!

I put a flange under the plateau and on the inside glues rubber. The stepper has a rubber wheel and was pulled against the flange with a rubber band. The idea being similar to small gear running on very large gear, but with rubber wheels.

Again, slippage and it finally dawned on me that gears are the solution. finally! I needed a large inner gear with pretty fine teeth and I had no access to a CNC machine or 3d Printer. I found that flexible electrical conduit had teeth that were just about to large, but when bend on the inside on the flange, the teeth were almost perfect with the small gear I found. I hot-glued a piece of conduit in place all around the inner edge of the flange.

After re-writing much of the control software, I calibrated the unit and it was millimeter prefect. No matter if I did a 20 part of a 720 part rotation, starting and stopping, the unit would now end precisely where it set off. Best of all, I remains accurate with loads up to 25 kilo's. It's not very fast, but it does not need to be.

Power

I also ditched the idea that it should be battery powered so a build a Q&D power board that provided the voltage for the micro and the stepper from a 12 volt wall-wart. Naturally I was far to lazy to put in some diodes so I did blow 1 or 2 caps in the process.

Camera control

I wanted to control my canon 350D (later 70D) via IR. I tested IR control on the breadboard and this seemed to work a treat. An old IR unit from a line-tracking robot nicely fit the machine and it all seemed to work very reliable as long as I pointed the camera in roughly the directions of the unit.

Unfortunately it turned out to be less reliable in studio lighting conditions. It didn't misfire often, about 1 in 80 times, but this was bad enough to ruin virtual objects runs. It needed to be fare more reliable. I don't know if it's because the carrier frequency is a bit off, or the IR leds I tried are not optimal for the camera's receiving end, but I could not get this to play nice with 3 lights on the object.

I ended up building a small trigger unit with two optocouples, mostly only using 1 with focus set to manual. this method never fails.

Stuff that I got right almost the first time

It wasn't a complete comedy of errors, building this machine. Some of the design choices worked out pretty well.

It was my first go at i2c that I used to drive the LCD panel. I now want i2c in everything.

The resistor ladder button interface used for control is quite intuitive

the menu system itself works and has a lot of nice features. It can recalibrate, test all the functions, set timeouts, speed, steps, HDR mode, enveloped, multiple runs and it stores all setting in eeprom memory.

Conclusion

All in all it was a very useful learning experience both in simple electronics as in mechanics. It's not the prettiest of machines with all it's unused mounting holes, pervboard hackery, and wing-it contruction, but it is what it is and it has worked reliably without major maintenance for some time now.

(warning, cheesy video of a early test setup!)