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.

FPGA’s and their benefits to embedded systems.

This week, among my actual work responsibilities, I started learning about and my mind was partially occupied by thoughts of FPGA’s (or field-programmable gate arrays).

They are a type of chip that is able to be configured (similarly to microcontrollers) to perform simple logic on hundreds of inputs in perfect simultaneity (unlike microcontrollers). Instead of, as we see in the arduino, a single processor, cascading down a set of instructions in sequence, they do a simple task in parallel hundreds of thousands of times a second.
They are essential to applications that require arrays of simple logic gates on huge amounts of input signals. The most common modern use is GPU’s, camera sensors, industrial automation, and advanced scientific calculation.

In my estimation, they would make the project that I am currently working on around 1000% more efficient. An on-chip array of quadrature decoders would be able to take signals from hundreds of rotary encoders on one chip. In contrast, a powerful 32 bit micro-controller like the PJRC Teensy 3.1 can only reliably read at MAX four rotary encoder inputs with far higher latency. For this reason, I am currently forced to use a micro-controller for EACH axis of my pan/tilt/roll controller. The teensy has the added benefit of having libraries for a hardware quadrature encoder, but even with that, it is easily bested by the simple parallel logic gates on an FPGA.

The hobbyist world is almost entirely devoid of FPGA’s (especially in the open source realm) and that is why I am watching this project with great interest.

For now, I must work in cascading algorithms for my microcontroller-based system. However, I may someday be able to port those capabilities over to a much more efficient, low-latency, and compact device.
__________________________

Another application that I foresee FPGA’s being useful in is electronic drumming and triggering of samples. In the electronic drumming world in particular, there has always been a problem with latency. 40 ms may seem like a short amount of time, but it is actually really SLOW if you are talking about musical performance (particularly with drums). 20-40 ms is considered a standard latency for most electronic music applications..and it has always been unacceptable. This has always been my problem with Roland’s V-drums, but a system like this might be able to decrease the latency by a factor of at least 10.

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.