Tag Archives: gimbal

Three-Ring Circus

Ring #1: Open Controller Project (Episode III)

I had some major progress this past week.  It all started when I ordered some Fischer connectors that don’t need absurd amounts of precision to start working with.  I was able to locate a variant of the 102 056 that can plug directly into a breadboard rather than needing to solder small wires into cup terminals.  I think this works out well because I will be able to prototype with these PCB mounted connectors straight into a breadboard and then, when I am ready, I can use the better (more waterproof) versions on the final build.  It’s very similar to what I am doing with the voltage regulators.  I have one set of regulators for the prototype phase (that has an LED display that accurately reads its output voltage) and the other is beefier and more reliable with heat-sinks and the ability to not only regulate but actually boost the power from a DC battery.  The battery system for the prototype and the final product are very different as well.  The final uses an Anton Bauer Dionic battery plate/24V XLR input/ 120V AC Power while the prototype will work with just two hobbyist battery packs filled with AA batteries.
With this prototyping setup and my new miniature oscilloscope, I have fast-tracked the progress into reading the values from the encoders.
After I meticulously patched things and double checked them for a couple of days, I was able to get a reading from the encoder out pins on my Hurricane Wheels.  I was reading them as analog for a few days.  During that time, I was starting to worry about getting that 5V logic signal down to 3.3V cleanly and with very little latency.
I soldered some pins onto one of the logic level convertors and wired it up as well.  I was kind of worried about all of the impurities in the signal, having read it in analog, but once I got both sides of the logic convertor wired correctly, progress!I was instantly able to see values.  I did one last check on a hunch and wired my oscilliscope for digital…..it worked.  No problems whatsoever and I don’t perceive any delay at all.

Here’s what I have bought for this project so far….


Electronic Components:

Test Equipment:

The next step on this ambitious project is to make use of the code for the hardware quadrature encoders that are shared here.  I managed to kludge some terribly incorrect code together that let me know via Serial monitor that everything is sending signals properly (apart from using my precious oscilloscope to find out), but the values were TOTALLY wrong.  It was saying “0”….. “1”…. “0”……”1″.  Not correct in the slightest.  I was hoping to be seeing 10-12 bit numbers that represent shaft rotation from 0 to 360 degrees.
The guy at the PJRC forum’s contribution is so advanced and foreign to me that it has caused me to question whether or no I don’t want to just buy some actual quadrature encoder chips instead.  However, I labor on, knowing that I have already gotten further than many people expected… and I am learning SO much.  I am approaching the most esoteric and dry part of this project and I must take my time to prevent myself from getting burned out and moving on.

Stemming from a comment on that PJRC forum, I have started to look at dedicated quadrature decoder chips that send out 16-32 bit data via SPI.  Here are the chips that I am looking at:  They work faster (I think) than the Teensy can decode quad encoders AND they have the extra benefit of working at 5V and send the values over SPI (I can’t seem to find out what baud rate they work at…anything under 115200 is a deal-breaker for me).  I would rather introduce latency to the signal AFTER the decode, but I like the fact that the Teensy is more versatile and can shape/error correct the data.  It can’t hurt for me to purchase one and test it against the Teensy.  If all goes well, I may be able to use the Teensy’s for number crunching and value conversion instead.  I wonder if this will prevent my project from being truly open source and honestly, that is a HUGE concern.

I am SLOWLY going through the code and simplifying it for debugging purposes.  I don’t want to create a blocking algorithm (one that takes up all of the clock cycles and prevents the data from getting off the chip in a reasonable amount of time) right off the bat, so I am analyzing this guy’s use of code that reminds me of “blink without delay”, which is a sort of finite-state machine that seems valuable for real-time applications.

Ring #2: Gimbal Build

I am finally working on getting the other end of this project up and running.  I am doing the necessary modifications to make my Came 7000 gimbal into a CAME 7800.  I have added a few bells and whistles that don’t even exist in the stock CAME 7800 gimbal

  • buttons from the left hand programmed with extra functions for tuning on the fly
  • a joystick on the right hand (replaces a d-pad)
  • a battery switch instead of sparks every time I plug the thing into a 3s/11.7V battery
  • bluetooth module to receive control signals from my controller project (Bluetooth or Bluetooth LE…that is the true question)
  • PERHAPS a voltage regulator (the small non-variable ones) that might allow me to use two batteries simultaneously and have them last double the time instead of having to switch batteries every 4 hours
  • MAYBE a magnetometer for extra accuracy
  • MAYBE some rotary encoders to add even more accuracy
  • HDMI to analog on the tilt phase

Ring #3: Digital Color Theory

I purchased a semester of fxphd a few weeks ago.  I had been drooling over DCT 301, 302, and 303, so I finally bit the bullet and bought it.  Charles Poynton teaches the class and I have learned SO much.  I try to only watch the class when I am in the mood, so I have been on a small hiatus for a few days.  I keep getting myself into trouble on the internet forums because I am unable to keep my mouth shut about all of the little misconceptions that I see perpetuating themselves in the school of “good enough”.
I got into an argument with a guy about whether or not C100 Log-C to ProRes 422 external recorder footage is grade-able.  I linked a video of a short that I shot that I think looks particularly bad (other than the shots where I was able to use my camera with Magic Lantern RAW) and the guy started to get hateful.  He said that I am the part of the equation that is the problem with the RAW vs. ProRes 422.  He said that if I need to shoot RAW to be able to get a decent color grade, I am just “bad at grading”.  I tried to get him to share some of his own masterful color grades from his HDV work, but he suddenly got very quiet.  All I really wanted was some constructive criticism of my color grade.  I even agreed with him that the C100 parts actually looked pretty bad, but I’d have loved to get some real pointers besides, “that looks bad”.  Perhaps I should ignore internet trolls, but my philosophy is that I should meet any criticism head on and explore the merits no matter how mean-spirited.  Sometimes, people sugar-coat their remarks and I look at criticism as my one true chance to get an honest or even brutally honest opinion.  I remain ready to be proven wrong on my opinion that it is absolutely the best thing I can do for image quality to record as much bit-depth and image quality as I can while I am on set.  It makes so much more sense to get more color data than to have to spend all the time dialing in the curves while on set.  Unless I have a dedicated DIT with live grading, I just really don’t like the prospect of burning my color grade into the file (which is, in my opinion, what people are doing when they shoot to such a lossy codec…or worse).  In my humble opinion, you can always do a careful color grade (or even a rough LUT) and render ProRes 422 out, afterward throwing the RAW’s away if you are so damned concerned about hard drive space.

Hurricane Wheels and the Open Controller Project


Three of these are coming in the mail from Germany!

Three of the handwheels pictured at right are coming in the mail from Germany!
My years-long dream of owning an electronic gearhead is nearing fruition.

Now, I will start to work on the (100% open source) code on my prototyping box (the UDOO) that will take the rotary encoder signal in real-time and translate that to multiple different kinds of control signals.

When the code is complete, I will grab 3x Teensy 3.1’s and write my code to receive and translate the signal, sending it to a master controller. The master controller will translate the input to whatever control signal I need for specific applications.

Current plans for this specific project:
– Bluetooth control of pan/tilt/roll on my/any brushless gimbal
– USB out for practicing with an android app or video game
– porting the rotary encoder code to work with other inputs to use in other applications and fields. Right now, I am doing research on DMX, MIDI, CANOpen, and other control signals. There’s a LOT of info already in the public domain, so I may even have a DMX controller very soon.
– touchscreen and Android OS ON the controller box to allow for rapid deployment of prototype code and tweaks.

The sky is the limit for this project, so I have started a repository called “The Open Controller Project” on github to port 100% open source code for this application and infinite others.

Current contributions to my Open Controller Project are limited to the source code from Lenzhound 1.0. Lenzhound is an open-source wireless follow focus that uses similar (but less powerful) 32-bit Arduino micro-controllers with transmitters and recievers that feature an onboard low-power stepper driver and Bluetooth master and slave units, respectively.
Lenzhound’s charitable contribution to the world of open source controllers lays a better foundation than my own pan/tilt code ever could because it uses Assembly language to handle the Arduino pin interrupts. Interrupts are essential with incremental and absolute high resolution rotary encoders (the main component in the wheels previously pictured is a high res incremental rotary encoder) to ensure that you don’t miss any clock cycles and the quadrature encoder code can start instantly (or imperceptibly fast).