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

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

One thought on “Open Controller Progress 15_04_15”

Leave a Reply