Close
0%
0%

VisualK-OS (Control Console) [Prototype]

A custom-protocol multi-component stage lighting/FX system.

Similar projects worth following
The needs of this project outgrew the casing, in addition to the proof-of-concept circuits having allowed me to learn and therefore improve the entire system... As a result, VisualK-OS has literally been torn apart and re-built into a far superior system. Be sure to check out the new module on my projects page!

[Original description (truncated)]
VisualK-OS is similar to the go-to standard of DMX lighting systems that most anyone using stage/club lighting has probably run into (in varying form) over time. Well, my band (Saturn's Iris) needed an extra edge of appeal and since I really like building things for myself, why not bypass the costly pre-made commercial stage FX systems and design make my own?

I've learned over time that I bit off way more than I could chew at first and, like many aspiring engineers, keep finding ways I could have done part-x in a lot more efficient form: Neater wire routing, simplified circuitry, less PCB crowding, etc. Alas, such is life.

[Intro]

{Updated 2/25/2016}

VisualK-OS collectively refers my custom-built system of lighting devices, intended for use with my band's (Saturn's Iris) live shows. To date, the system consists of: The main control center, Thor and the Flood Bank Array (w/dual flood boards featuring 4-lamp configuration with dedicated board-wide white (non-RGB) strobe). There are other devices in development, but during their live debut (of course...) on 2/20, I discovered some limitations and slight connection/immobilization issues that need to be addressed before I begin working on new additions.


---{ COMPONENTS }---

[Control Center]

  • ABS plastic case: Gutted digital trainer kit, modified to resemble a briefcase-like setup which houses the main components. This is also to conceal/protect the AC power distribution (which also makes a general purpose set of outlets available), including the Flood Bank Array's 16A desktop PSU.
  • Raspberry Pi (Model B): Host system, configures and manages all modules, which connect by USB via a powered 4-port hub. The rPi is running RetroPie (which may change to a custom kernel) and has a configuration management utility running in curses via Python. Said Python script also directs input from the PS3 gamepad.
  • PS3 Gamepad: Used to control the Flood Bank Array more effectively/intuitively than a keyboard. Profiles defining various different button mappings/layouts are used to expand the efficacy of this input device.


[Thor (Acoustic Drum Lighting Module)]

  • Etched PCB (photofabricated) w/8 channels that takes its input from piezo triggers, which (if one crosses it's defined threshold) control an RGB LED strip mounted to a drum. Each channel uses a CAT5 cable to run 12v+/Rch/Gch/Bch/GND to a given drum, which has a small RJ45 breakout board connected to the drum's RGB LED strip and piezo.
  • Thor contains 3 74HC595 shift registers and 24 Tip122 transistors to manage 8 strands of 50/50 SMD RGB LEDs over CAT5 cables and is controlled by an Arduino Nano. Expansion pads were included on the PCB for later expansion beyond 8 channels/ports with additional shift registers, so that re-fabrication would not be necessary.

---{ Upcoming Modules }---

[EnigmaBox: General FX Module]

  • Controls general stage FX (ex: pedal-triggered overhead lighting, used by synth player to encourage audience participation). Device is in planning stage, no pictures as of yet.


---{ Old Parts }---

  1. Synth-Station (Keyboard Lighting Module): This was the first unit made for the system (in its current form) and was a multi-tier free-standing shelf system (intended for a stereo) that had been outfitted with RGB LED strips on the underside of each shelf and in the hollow channel of the shelving's "spine" that runs up the back and had notches for the shelves. This device was powered by an Arduino Uno, which listened for instructions via serial from the computer it was connected to; The computer in question ran a python script that hooked the incoming MIDI data from the controller and determined what light/sequence should be activated.

VKOS (v3.8 - 2016.12.20).7z

Improved the overall layout of the source code and did some general housekeeping with the documentation supplements (gamepad tester, header generator, etc); The launcher is now simply "runVKOS.sh", which executes the new GUI front-end. This new front-end lists a "Program Editor", which is intended for setting up automation routines/scripts, but this has yet to be implemented anywhere in the system... The basic framework for such a system update is likely to be the next version, since this update was all about unifying and simplifying the source code and user-side parts of this system. I've debated over an eventual full windowed GUI, but the current needs of the project can still be comfortably contained within the curses UI. Perhaps a future version will implement a more complex windowed UI, but until that time, I will continue to use the curses approach until I deem it too much of a nuisance to keep up with the evolving capabilities of the system, as I am generally fond of the look.

x-7z-compressed - 9.12 MB - 12/20/2016 at 09:47

Download

VKOS_CC (v3.7 - 2016.12.05).zip

Updated source code to include GPL license info/output. Info can be triggered with command line arg "ABOUT".

Zip Archive - 26.89 kB - 12/06/2016 at 04:20

Download

VisualK-OS Control Center - Documentation (v1.1).pdf

Minor update with typo corrections and a corrected linear diagram of the FBA board flow.

Adobe Portable Document Format - 71.72 kB - 11/03/2016 at 07:29

Preview
Download

VKOS_CC (v3.6 - 2016.10.24).zip

First release of the control center source code.

Zip Archive - 25.66 kB - 10/24/2016 at 08:27

Download

Adobe Portable Document Format - 72.22 kB - 10/24/2016 at 08:27

Preview
Download

View all 20 files

  • VisualK-OS is now officially GPL open source.

    Lord K-OS12/07/2016 at 21:11 0 comments

    I had always thought of this as an open source project, despite the niche need it fills and the unlikely possibility that someone may seek to recreate parts of the rig, but now it is official; Supplying the command line argument ABOUT to the main "VKCC.py" script on launch will trigger a display of the GPL license and then exit. This was largely necessary to obtain a free license for WingIDE, which I've included a link to the company's web page in this project's external links. I could have kept using the free 101 version of the IDE, but free stuff rocks for us poor people that don't feel like dealing with hunting down a crack/serial/patch.

  • First release of the Control Center source code!

    Lord K-OS10/24/2016 at 08:29 0 comments

    The first release of all of the Python source code to the VisualK-OS Control Center has been posted. I have also uploaded an initial documentation for the system, available in the files of this project.

  • New revisions abound!

    Lord K-OS08/08/2016 at 07:21 0 comments

    I've realized some of the limitations that the current protocol imposes (parameter specification for more complex device control, among other things I can't think of at the moment), so some things needed to be addressed. Namely, keeping the constant values synchronized between the Arduino/Python sides of things was becoming tedious, so the serial comms approach needed reworking. I'm trying to break the dependency on strings (as it is expensive overhead on the Arduino side of things), so commands and parameters are now limited to one byte. Granted, this puts an arbitrary limit of 256 on the number and size of commands and any associated parameters. For now, I can deal with that... By the time that becomes a limitation, I imagine I will have thought of or been exposed to a new methodology to accomplish what is needed.

    So, with this addition of the standardization of the headers/constants, I need only refine the serial implementation's use of delimited strings to a series of bytes and then I shall be ready to post the code. I hope it may be help to someone, but I doubt anyone will be replicating my work as such. Stay tuned! >: )

  • FBA is now hardware-complete!

    Lord K-OS07/25/2016 at 05:27 0 comments

    The Flood Bank Array (FBA) boards now have completed enclosures, have endured a bit of drop-shock testing and are fully debugged... Each board now works on all channels (R/G/B/W). The Control Console (CC) software has had some further debugging work, with the addition of the manual FBA control screen now fully functioning (which is how I tested/repaired the FBA boards just now, which is exactly what that screen is primarily intended for). Yay, progress!

    I may upload a video of it working, but it's a set of RGB lamps on a board... What's to see? The guts are a bit hacky (due to some unforeseen PCB repair issues related to how the board was laid out), but they work, despite some of the seemingly-exploded TIP120 transistors that have leads attached and are glued down in no certain order looking like a weird dead-bug style of construction.

    Now, to add in more commands and automation. The code was cleaned up on both the arduino and python sides, but I'd still like to implement a little bit more before I post any of it.

  • 5 months and a lot of revision work...

    Lord K-OS07/12/2016 at 18:27 0 comments

    Greetings! First of all, I'd like to thank the ~25 followers this project now has. Usually people don't give two shits about the technical details of my electronics projects, as they just want to see footage of it working; I understand it's not everyone's thing (programming logic, circuit efficiency/design, etc), so for those that are actually interested in how this system is made/evolving, I sincerely thank you for giving a fuck and I genuinely look forward to any questions and/or constructive input you may have. I intend for there to be much more frequent updates, but we'll see if that actually happens or not.

    First off, the versioning system used in the source code files (currently v3.5) are generally all from 3.0, onward. There are two reasons for this; I have been working on this project for a couple of years now, generally expanding and modifying it on an as-needed basis without any real documentation so-to-speak of the work. Resultantly, when I decided to standardize the code across all of the VKOS devices (both for efficiency and readability by someone other than myself), I began at a favored and reasonable major version of "3"... I'm also semi-irrationally fond of odd numbers. The individual module files are versioned from 1.0 on, though it is arbitrary as well since the split into different files occurred very recently and makes the progression through version numbers quicker than visually implied.

    I hope my code and hardware documentation may be of some assistance to someone, someday, as the published work of other aspiring engineers has similarly helped me out in my work when I couldn't figure out how to do part-x. In retrospect, I now look at the circuitry of some of the devices and think of how I could have done it in a more efficient and aesthetically-pleasing manner (though I am a lover of all types of circuit porn), but it's not worth re-doing everything... This is not a commercial product, so what matters is that it works and isn't exhibiting any glaring ineffiencies.

    [Source code overhaul]

    The code has been successfully split into files relevant to each class, object and driver instead of the 800+ line python script that drove the control console and the few hundred lines of Arduino source that was hacked up to work with each device as needed. The code is now structured as follows:

    "CS" = Curses screen (UI is in curses, mainly because I like the look)

    \\ Visual K-OS Control Center

    | - globals.py[All global constants/object definitions]

    | - _screenCfgFBA.py[CS - FBA configuration]

    | - _screenCfgMain.py[CS - Config. selection menu]

    | - _screenCfgSS.py[CS - SynthStation configuration]

    | - _screenCfgThor.py[CS - Thor configuration]

    | - _screenClientScan.py [CS - Display status and/or scan for slave devices]

    | - _screenDisplayMapping.py [CS - Display the current GamePad mapping profile]

    | - _screenMain.py[CS - Main menu]

    | - _screenManualFBA.py [CS - (limited) Keyboard-driven FBA control]

    | - VKCC.py[Main script]

    | - VKCC_Constants.py[Constants used everywhere: Serial, color, etc]

    | - VKCC_objFBA.py[Flood Bank Array object definition]

    | - VKCC_objGamePad.py[GamePad I/O driver]

    | - VKCC_objScreenManager.py [Curses/console UI manager]

    | - VKCC_objSerialManager.py [Serial I/O manager]

    | - VKCC_objSynthStation.py [SynthStation object definition]

    | - VKCC_objThor.py[Thor object definition]

    [FBA Enclosures]

    The FBA boards (2 total, currently) have finally gotten wood backings. One has had a full back piece for a while now, but the 2nd's circuitry has been exposed since its inception until last night. Now, to finish sanding down, leveling and re-painting. The good part about recycled palette wood is that it's free... The downside is that it is often semi-warped and/or irregular in dimension, which is why the enclosures have a bit of "character" that I'm attempting to minimize. They will eventually have hinging mechanisms so the boards can be angled and supported without needing to be propped up precariously on the stage.

  • Evolution!

    Lord K-OS02/24/2016 at 09:13 0 comments

    Since the previous post, the first 2 flood boards have been built and used live at a concert (unexpectedly, but helpfully, allowing me to find where my protocol and approach has had some inherent weak points). To simplify, I shall just post an itemized list of the current state of things:

    [VisualK-OS Control Center]
    - Remodeled interior now uses a side-mounted AC port instead of a hardwired cord for the main power input to the system.
    - Flood Bank Array controller/driver is mounted on top of its' PSU with a DB25 connection used to send the SPI control signals to the 2 shift registers in each flood bank board.

    [Flood Bank Array (FBA)]
    - Arduino driver sits inside control center, connecting to a small 3D-printed breakout box (carrying 5v+/12v+/SPI/GND signals) that currently has two RJ45 connections. Each RJ45 port sends 5v+/12v+/SPI/GND to each flood board with 3 pins allocated for current (GND) due to the relatively high amount of ~198 RGB strip segments per flood board. All transistors, resistors, capacitors and shift registers are located on a PCB mounted inside the flood board, to save from having to cram all the wiring into the already-crowded control center and run one cable to the stage to control both boards.

    - Connected by RJ45, each board contains 4 RGB lamps and one board-wide set of white LED strips (5 addressable lamps total). The 2nd 74HC595 register's serial out pin is connected to one of the RJ45 pins to send the data back up the line and into the next port on the breakout module. Basically, the boards are one chain of multiple 74HC595s (as far as the Arduino is concerned).

  • Finally, progress!

    Lord K-OS01/24/2015 at 10:37 0 comments

    New photos of the PCB fabrication for the newest and coolest module (Thor) have been posted, component list has been updated and the general info has been better articulated... It's still a whole bunch of words to me, but at least it's much more accurate, now. haha

  • Makeover!

    Lord K-OS04/19/2014 at 18:32 0 comments

    After some compromising due to budget (I suppose this plagues a lot of us DIY folks, at times), the flood panels have been put on hold. However, this resulted in forcing me to re-think how I was approaching this project and relatively simplify the mechanics of it a bit more, ideally reducing future headaches. The Synth-Station, previously running off the RPi/Arduino duo, now uses only the Arduino and simply listens for commands over serial. The Synth-Station will later be able to be controlled from the main system, for off-stage management and to allow the synth player to focus on what they're playing, rather than selecting the proper lighting routine for x-song). So now, said Arduino is commanded by a Python script that sniffs the messages coming from the MIDI controller (being used by FL Studio for live synth generation) and reacts accordingly as the script determines if each note is to trigger a light or sequence.

    Once I had colored the "Back-Bone" channel LED strips black (Yay for Sharpie ghetto-art!), I then changed the shelves' connector out from tedious terminal blocks to relatively convenient D-SUB 9 connectors for improved modular functionality and connection flexibility/stability. Yea, having to unscrew 4 terminal blocks from each shelf just to allow the shelves to be removed for easier storage and transport was quite cumbersome, time-consuming and annoying. For the needs of this component, terminal blocks were clearly not the great idea I thought they were. However, D-SUB casings filled with hot glue have proven to be much more reliable for making a secure and easily-removable connection.

    Now, with the guts all nicely glued (at least as well as they can be) into the container, this component only needs some more automation routine programming and it will be the first finished piece of this new system... Yay!

View all 8 project logs

  • 1
    Step 1

    I doubt anyone will desire to re-build my band's lighting controllers/FX. haha

View all instructions

Enjoy this project?

Share

Discussions

Jasmine Brackett wrote 09/11/2014 at 22:38 point
Hey Lord K-OS, got any video of this in action at a Saturn's Iris gig?

  Are you sure? yes | no

Lord K-OS wrote 09/11/2014 at 22:45 point
Not as of yet, but there is footage of it in use in our upcoming music video release and crowdfunding campaign video... The latter of which I hope to release in another day or so. :-)

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates