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.

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