Nebula 4000 Stabilizer – Part I

UPDATE February, 2015.  Am now happy with the Nebula.  Feel it best with the Sony A6000 or BMPCC.  It works with the A7 and GH4 of course, but is easier to balance and run with smaller cameras.  I no longer use any weight “mods” like those seen in the picture below; indeed, I don’t recommend them.

On YouTube, I saw that Dave Dugdale, at, was spending hours-upon-hours trying to figure out how to get a Nebula 4000 camera stabilizer working.  At $700, the device promises major league Steadicam quality in the palm of your hand.  Sample footage from China, where the device is made, was/is certainly tantalizing.  But back at Dave’s studio, the Nebula was shaking his GH4 around like a bad dog with a rag doll.  The software looked only marginally easier to configure than the cockpit of the Space Shuttle.    I thought, ‘better him than me’.  Maybe I’ll get into it after he figures it out; that is, if it doesn’t all end in tears (which was seeming more and more likely).

Nebula with Yaw balance fix

Then, in passing, the photographer/D.P., Red Wylie told me he had a Nebula and, since he didn’t have a GH4 to use anymore (having sold it to me), I could borrow the Nebula and try it out.  He warned me that he couldn’t configure the Yaw anymore and that he might have a ‘dud’.  The only dud was me–I’ve now spent two solid days with his Nebula 4000 and I barely know what end is up anymore–gimbal pun intended!

After watching Dave’s latest video I decided I had to share what meager knowledge I’ve accumulated so far.  Some of it might be wrong, very wrong.  When it comes to the Nebula 4000, at this point in time, even good guesses are probably welcome by fellow sufferers.

The goal of a stabilizer is to keep an object, in this case a camera, in the same position no matter what movement the person holding it makes.  If I lean down, the stabilizer would lean the camera up, to compensate (pitch).  If I twist my hand a bit in the clock-wise direction, the stabilizer would twist the camera an equal amount counter-clockwise (roll).  If I point the camera a bit to the left, the stabilizer would move it to the right (yaw).

For each axis (pitch, roll and yaw) there is a motor that will move the camera.  In a perfect world, the Nebula would know that a 1-volt surge for 1 millisecond might move the camera up an inch if I moved it down.  Unfortunately, temperature, weight, speed of movement, battery power, etc., all influence the net-effect of any voltage applied to the motor.  In short, the Nebula is like a golfer who can’t predict exactly how the ball will roll on any particular grass.

So what does the stabilizer do?  It practices hundreds (?) of times a second, and through a feed-back loop, eventually points the camera in the exact same direction it was pointed when you first turned it on.  Like a golfer, after a few tries it can figure out the power, speed and grip strength it needs to get the ball exactly where it wants.  Unfortunately, you have “configure” the Nebula with how much power it should use when it tries, how much error it will tolerate, and how quickly it will try again.  Every camera (weight) necessitates different settings.  Will you be running or standing still.  Should it keep the camera really still while you’re standing still?  Or keep it reasonably still while you run?  There is NO perfect configuration for the stabilizer (just like there is no one perfect club for a golfer).  The stabilizer can’t predict what movements you’re going to make.  You must prepare it.  Configuring a stabilizer is an art.  I call anything an ‘art’ when I stink at it 😉  For example, when the stabilizer shakes it does so because the power and timing does not match the object it is trying to balance when not moving.

Too much power and the camera will over-shoot the target (sort of like Shaquille O’Neil’s free-throws).   Too little power and you have an air-ball.

Before the Nebula can balance anything with its motors you need to balance it on the device, physically.  This takes us to the first serious design “problem” of the Nebula 4000.  The camera platform is not balanced itself (without the camera).  It expects that the camera weight will be added to each axis, in a certain direction.  That is, each axis begins “top heavy”, so to speak.  The reason I (and Dave) have so much trouble balancing the cameras is one must “solve” two centers of gravity at the same time (times 3 for each axis)–the device’s arms and then the camera’s.

The worst “top heavy” balancing problem is the Yaw.  You can only adjust it by moving the sled forward or back three positions.  To allow more better tuning, I have added counter weights to the Nebula where I can move weights small increments to get a perfect Yaw balance.

Above is a photo.  This post is very rough, I will re-write it later, with more info, and publish better photos.

I also place the camera on a clear, see-through CD case on top of a dowel (or any round object).  I then move the camera back and forth until it is perfectly balanced.  I then mark where on the camera it is.  By knowing the 3 centers of gravity for my camera I know theoretically exactly how it should sit on the Nebula. I find this is very helpful.







Logitech 910 Robotic Panoramas

All winter, while my workshop (garage) has been too cold for robotics, I’ve dreamed about making a panoramic robot with one of Logitech’s new HD webcams. This weekend I got to it.

The 910 has a 5mp sensor (though they use software to bring that up to 10mp for advertising foolishness). Naturally, a webcam will never beat the photo quality of my Canon G10 (now G12–more on that in the weeks to follow) or Sigma DP1 that I used last summer, but it could reduce the complexity of the setup and go fast. Speed is what I’m really after.

Last summer’s camera panoramas generally took more than 12 minutes to complete. The Sigma DP1 was especially slow (it’s a slow camera to begin with). Already, I’m able to create a 3 row, 360-degree panorama with the 910 in less than 3 minutes.

Here is one I took in my backyard.

Here’s a photo of the 910 on last summer’s Arduino panoramic head. I moved the camera closer to the center point on the tilt and that improved the pano stitching. You can see in this photo why there would be parallax problems in the earlier efforts.

My next step is to create a robotic head specifically designed for the webcam. Because it isn’t heavy I don’t need to distribute the weight on a ball-bearing platter. I plan on using two GWS S125 IT 2BB Sail Winch servos. These servos rotate 360 degrees, unlike most servos that do under 180.

I’ll also try the new Arduino UNO. Apparently, it has a different serial chip than the Arduino Duemilanove. Improved serial speed would be a plus since that’s how I send commands to the servos, through the PC. With the cameras I often had the Arduino run a program, but since the webcam has to connected to the PC, I might as well have the PC run everything.

The controlling software is done using C#. I modified one of the sample programs that come with open-source aForge. I can’t say enough great things about aForge .NET.
Capturing an image from a webcam, programmatically, is a pain. aForge makes it relatively easy. In the following weeks I hope to post my code for my robotics (which I should have done last year). If you can’t wait contact me at max at htgrp dot com.

Next week I hope to build a robot that creates 64 megapixel, correctly stitched panos in under a minute.

Other to-dos are fixing the exposure on the webcam and/or fixing the focus point. These require some DirectShow craziness. Kimchi and Chips have done it–whoever they are! The bottom line is that yes, the Logitech 910 is a cool sensor. I bought mine for $65 reconditioned on Ebay. Because it really has only 5mps I’m wondering if the cheaper 310 wouldn’t be just as good. A test for another day.