360° Photography

This project is about the most fun combination of electronics and programming that I've had since my MacDrums™ project in college. At a trade show in Chicago a couple years ago, I discovered a company called Ortery selling a system for shooting 360° photography that produces "spinnable" images like the sample at right. This is useful for anyone involved in web sales of small products that prospective buyers would like to see from different angles. Susan had a few products on her site that would benefit from this kind of photography, so my interest was piqued. Images like this are not interactive videos, but actually just a series of still photos taken at precise intervals of rotation on a computer-controlled turntable. The system I saw demoed had some really sophisticated software and a very robust turntable bundled for around $2400, which was at least $2000 more than I could justify. So, I set out to try to design and build my own system. My system is admittedly far less sophisticated, but in my opinion, the results are at least as good as those from Ortery, and for my purposes, even better.

Software

Being familiar with a web graphics technique known as CSS image sprites, I realized that this was the best way to load all the frames of my 360° photo, and all I had to do was write a bit of javascript to manipulate the sprite image within a smaller frame. Building the sprite image was easy, thanks to an Adobe Photoshop command called "Automate>Contact Sheet II", which I found I could use to take a series of images and arrange them neatly into rows and columns that make a perfect sprite image like the one below:

The series of images could be easily adjusted, cropped, and output to the desired size straight from Adobe Lightroom, so really, the only hard part left was building a turntable that I could somehow control electronically in precise and tiny amounts.

Hardware

The turntable and electronic control hardware became a research project in modern DIY robotics, and it became my mission over the 2014 Christmas break to study the many resources available at my new favorite web site, SparkFun.com.

Using Sketchup to create 3D assemblies from model files provided by SparkFun, I was able to create the scale model at left with enough confidence to go ahead and order the parts. When the parts came, to my delight if not necessarily surprise, everything went together exactly as planned, and the result is shown below.

The motor is a stepper motor, which is the kind of thing used to drive the print head back and forth in your inkjet printer. They are driven by computer control, and rather than spinning at a constant rate when you apply power, they move just one tiny step at a time. The motor is built to do 200 steps per revolution. I am using it with a driver board that supports 8 "microsteps" per step, which means it takes 1600 steps per revolution of the motor. My gear assembly slows the turntable down by 8:1, so for one complete revolution of the turntable, it takes 12,800 pulses to the driver board, which makes it possible to control the turntable with very high precision.

Electronic Controls

While I had lots of experience toying with electronic circuits in my youth, I hadn't tackled a project this complex since college. The two buzzwords I knew I needed to explore were Arduino and Raspberry Pi. A quick bit of web research revealed that the Raspberry Pi was much more like a computer, which ran an operating system (Linux), and was suitable for applications where you need the full resources of an actual PC, but in a tiny and inexpensive package. The Arduino, on the other hand, is a microcontroller that runs no operating system, but executes C++ code to control inputs and outputs, also in a tiny and inexpensive package. It was clear that Arduino was the way to go, so I ordered a SparkFun Mini Inventor's Kit that came with an Arduino-compatible controller, a breadboard, and a bag full of parts suitable for learning my way around the system. I also ordered some additional parts that I planned to use for my planned interactions with the device--a gesture sensor for command inputs, a tiny OLED graphical display for user feedback, and a stepper motor driver board.

Model 1 (A False Start)

The very high-tech-sounding gesture sensor and the OLED graphical display sounded like really cool elements of this project, but I ordered them before I fully realized the limitations. Namely, they operate at 3 volts, while the Arduino board operates at 5 volts. I tried valiantly to get things to work in a way that makes for a whole separate story, but ultimately I ended up ordering an Arduino Pro board that runs at 3 volts. The good news is that it all came together, and with a few hours of C++ programming, I ended up with a working system that performed the basic functions I needed. The crude, "rev 1" setup appears below (in 360° at 24 frames because I read somewhere that 24 frames was a good trade-off between file size and rotational smoothness).

24 frames

The bad news is that, due to the low power of my 3-volt system, I was unable to find a suitable relay to trigger the camera automatically. That level of automation was certainly one of my goals, but without it, I can just press the button manually at the appropriate times. Still, I need to find a way to drive the camera for a fully-automated system.

The brass post is for mounting on a standard light stand, which is often at close reach in a studio. The loose connector with the black and white wires is where the power supply connects. The blue board is the Arduino Pro, and the three small red boards are the stepper motor driver, the gesture sensor, and the display.

Model 2

After a mostly successful first model, which I used to shoot many 360° sequences, I was ready to try again with the goal of having the device fire the camera shutter automatically. This task is trivial using a 5-volt reed relay wired to a remote shutter cable connected to the camera, but of course, that requires a 5v system. I still had the original 5v Arduino-compatible "RedBoard", but going back to that means losing the cool gesture sensor and the OLED display. So, back to the drawing board. The input functionality I needed to redesign was the following set of gestures:

  • Swipe Right: start an automated shooting sequence
  • Swipe Left: Stop a sequence
  • Swipe Up: Increase the number of frames in a sequence by 6
  • Swipe Down: Decrease the number of frames in a sequence by 6

With those four inputs, it seemed to me that a little video game-style joystick might be a great way to go. I found a little joystick that had the usual up/down/left/right flexibility, plus it had a push-button switch that I could use to expand my controls. Using the joystick, my new controls would be these:

  • Push the button: start a sequence, or stop a sequence if it's already running
  • Stick Up: Increase the number of frames in a sequence by 6
  • Stick Down: Decrease the number of frames in a sequence by 6
  • Stick Left: Rotate the table counter-clockwise at a speed proportional to the stick position
  • Stick Right: Rotate the table clockwise at a speed proportional to the stick position

For output, I just had to redesign my user-feedback to use a 4-digit 7-segment LED display instead of a graphical display. The "Model 2" design is shown below, pictured with a Sharpie marker as a scale reference.

24 frames

This version works really well, controls my camera (yay!), and because it no longer uses the gesture sensor, it doesn't suffer from the random-start issue that happened occasionally as I walked past Model 1. The only problem is that it's a bit unweildy, and looks like it could be miniaturized.

Model 3

The biggest component in Model 2 is the RedBoard, which is about 2.2 x 2.6 inches. A little more shopping at SparkFun revealed the Arduino Pro Mini that has most of the same capabilities as the RedBoard, but it's only 0.7 x 1.3 inches. That's about an 85% reduction in board size! A little more re-soldering with a new Arduino and a fresh prototyping board, some extra standoff hardware to secure things, and voilĂ ! Model 3:

48 frames

You will notice that the 360° spin of Model 3 is much smoother than the others. That's because I shot it at 48 frames per revolution instead of the default of 24, which means each exposure is 7.5° from its neighbor, rather than 15°. The image file, then, has 8 rows of 6 frames rather than 4 rows. The need for this flexibility from time to time is why I wanted to be able to control the number of frames from the joystick. By standardizing my images at 6 images per row, I can make the joystick increment and decrement the frame count by 6, which makes it quicker to specify meaningful (noticeable) changes in frame count.