Category Archives: Cinematography

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….

Hardware:

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.

Open Controller Progress 15_04_15

I am working as slow and steady as possible on the Open Controller Project.  I have recently pulled in some code from other repo’s on GITHUB.

This project, as almost all that I take on, NEEDS to be approached with a slow and steady philosophy.  I am learning a ton, but I have a tendency to get ahead of myself and burn myself out VERY quickly.

These are the concepts that I am currently researching so that I have a direction once I can get values from the gorgeous encoders that Matthias sold me at Kidsofallages.de

  • Hardware Quadrature Encoder: This code was written by a forum user at PJRC and it allows the teensy 3.1 to read quadrature encoder values with as low latency as possible.  The guys over there are struggling to send those values out via i2C, so I am a little worried about when I go to do that.  One step at a time, though.
  • Smoothstep: an algorithm for creating S curves for easing in and out from one velocity to the next.  This algorithm is used in many, many pieces of animation software and will allow me to switch on a mode in the controller that makes even the jerkiest control signal into one that moves with utmost fluidity.  The code will slow down the latency from controller move to action on the machine because it adds machine cycles.
  • State Machine: I have been pondering the fact that my code on the brain needs to be non-blocking and a state machine seems to be the agreed upon way of accomplishing the feat of polling three (or many) different control signals “simultaneously”.  The plan is to poll the i2C data in a cascade, starting with the pan signal then create a state that factors in the incoming velocity so that when I move onto the next axis, I don’t block the first one from action.  All of the examples I have found on Youtube tend to focus on LED’s and don’t use real-time control signals, so my work is cut out for me here.  The OpenMoco project that I have pulled into my repo already has the non-blocking capabilities.  However, it wasn’t made to accept real-time control signals into it’s loop since it was made for pre-programming THEN firing multiple servos/steppers in real-time.
  • Power specs:  I bought two voltage regulators (one with an LED display and the other without).  These will allow me to connect DC at up to 30V and distribute the proper voltage (3.3V for Teensy 3.1 and 5V for hurricane wheels) without worrying about the ever-changing voltage you’d get from a voltage divider.  A voltage divider would cut out and change as the batteries drain, whereas the regulators will keep the voltage steady even as the batteries change their input voltage.  I also will eventually add an AC-DC converter so I can go off of wall power as well.  It will be tough to switch between the two automatically, but I am sure that that info is somewhere out there.  The DC power will come in via XLR 3 pin (24V) as we see on brick batteries and Anton Bauer battery plates, which is EASY with a voltage regulator in line.  There will also be a fuse and power switch for the controller.
  • i2C: The i2C signal in my controller will run at the maximum baud rate of 115200, which should allow for more than enough speed to overcome not being able to receive all control signals in true simultaneity.

There’s a TON of work to go, but I am still pulling in repositories to hopefully accumulate open source code that can function within my requirements.

The Udoo is starting to look like a poor decision.  I am noticing that the Teensy 3.1 outperforms even the best Arduino Due version (including the Udoo), so the touch screen capabilities of this device are starting to look tenuous at best.  If I can see a reason to continue using the Udoo, I will, since it will (theoretically) allow the user to load and control the mode that the Open Controller is in.  This sort of customization is essential to make this box do more than just one specific thing.

Since I want to branch out into follow focus, DMX, USB, ArtNet, OSC, MIDI, and other purposes for this device, the ability to load a different mode via a touchscreen (as one does on a PC when loading different software packages) is absolutely critical.

Here’s the box that the project will reside in.  There will be no holes on the outside of the box and all port connections will be on a panel in the box.  I am thinking that the panel will be laser cut acrylic or some kind of machined aluminum with a cool logo on it.  That won’t happen for a while, though since most of this project will reside on a breadboard until I can get it perfect enough to print out a circuit board.

I am working on schematics in Eagle and having a tough time with some very simple stuff.  Problem is, I am not schooled in EE, so I am having to research just about every part.  Why do I need a pullup resistor to ground?

I will definitely send the schematics to my buddy who specializes  in analogue circuitry, Tony Norton.  I hope he can go over it and catch anything that I am doing incorrectly or inefficiently.

There’s a lot more that has been going through my mind.  I will touch on those topics in a future entry.

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).