Kaimana RGB LED Board thread, RGB animations and more! SRK Tech Talk 2013 Product of the Year!

The Kaimana LED Controller is a powerful new tool for those looking to get the most out of their custom arcade stick or cabinet! This is the first board to used indexed LEDs in an arcade stick and allows for RGB control and animations. It is also the first fight stick RGB LED controller to provide full RGB control for joystick ball tops and hit box configurations.


The Kaimana can run conventional LEDs like the Pele’s or Uila’s with an adapter board or can be used to run the new Kaimana J’s:

Unlike previous LED boards, the Kaimana uses indexed LEDs so they can be connected in series and you don’t have to have multiple wires running from the controller board to each LED
Diagram:

http://support.paradisearcadeshop.net/lib/exe/fetch.php?w=500&tok=633a2d&media=kaimana_led_chain_default.png

Example (jwyder’s stick):

It is also designed for easy installation as a pass through board. The pinouts are the same as a PS360 so modding your dual mod stick could not get any easier!

Diagram:

I have installed three of these systems, and total install time, including installing all the buttons and joystick ahs been less than 1 hour each time using the Kaimana J’s

Based on the infinitely flexible Arduino, this board can do just about anything you can imagine. Because it uses the extremely simple to learn Arduino programming language, this board opens the gate for anyone to create their own light patterns and shows.

As people invent there own animations series we will be adding them to the store for download and people who contribute programs will be able to earn store credit! As of right now the entire Ryu special move set for SFIV has been coded with animations. The best part is that all you need is a USB cable and any of the programs created can be loaded in seconds!

Boards and accessories can be purchased here:
http://www.paradisearcadeshop.com/1656-home_default/paradise-kaimana-led-controller-pcb.jpg

Wiki:http://support.paradisearcadeshop.net/doku.php?id=kaimana_led_controller

This section is where we will post new code and links to the videos for that code:
https://github.com/armi0024/kaimana/archive/master.zip

Thread for kits lists:

This section will be used to create lists of parts for different configurations.

New Idea #1 - make direct adapter harnesses for the Arc Eye 2, inspired by Beakersoft
-The Kaimana adapter will allow Arc Eye 2’s to be incorporated into the system, so if I have the pin out I can make custom harnesses so this is just plug and play!

Anyone else have ideas they want to see incorporated?

Maybe for a new iteration of the board to have a trace from VCC to the corresponding points on the bottom terminals that start the chain?

Also maybe some compatibility for a solderless solution for uilas using an adapter board?

Great suggestions: I can do a harness for now and maybe a 2 pin jumper so it’s easy and doesn’t require a wire harness?
If someone tries to run LEDs at a different voltage and that is connected into the VCC that could cause big problems. This way there is a catch when connecting power. Stop! if you can’t figure this out, you shouldn’t be doing it! For now I can just include a harness with the board ready to go…

For the Uila’s we have the housings and crimps in so you can add your own fittings, the only problem is they sent us the female housing and male metal crimps… we are changing this, you up for making a tutorial when we have them :slight_smile:

How about a Y signal adapter which connects to the PS360+ (in my panel) and then to just one side of the Kaimana and out to my buttons and stick? I could use that with a right angle pin header down one side of the Kaimana too.

@ZonbiPanda Shoot me a sketch of that in PM, sounds possible but that’s why we have the pass through to make it easy to integrate. Maybe a pin set that would plug into one side with free wires to screw into the PS360, or… with a plug for the PS360 solder point.

I like the right ankle that’s a great option, we will add that.

Code still needs some cleanup but here is a peek at what I was able to get done this weekend on the kaimana sketch. New stuff includes:

  • menu mode w/ custom colors (up to 8 “profiles” supported)
  • last profile memory (kaimana remembers which profile you were using between sessions)
  • new idle animation (K.I.T.T. inspired scan)
  • And a marvel 3 profile
    (original kaimana master profile can be loaded from menu)

The marvel loadout features Yellow buttons on point, Green on assist, and purple on anchor. A unique animation plays during a hard tag for each character… sort of a flash loop in thing for nova, green slide footdive thing for doom, and random purple flashes for strider. The buttons and assist button colors also shift when a hard tag is made so they use the color for whoever is on screen or behind each button. and Xfactor is red. Hopefully a good starting point for some better marvel stuff, the animations themselves arent too impressive (and i left nova’s out of the video :frowning: )

1 Like

Awesome! When you finish the clean up we can post that with the video for others to download.

This is just the beginning!

Here is another version of the Wire Logic Diagram:

I did this to show that the Kaimana does not necessarily require wiring on both ends but wiring to the same inputs as the PCB. Hope this helps.

Looks good @jywder but you only need one ground wire between the ps360+ and the Kaimana.

That’s the way I am running mine.

Sounds great @wahoo747. When will you be able to post this? I might integrate some of it into another class demo I am working on.

@beakersoft We are going to work on the instructions for Arc Eye 2 Installs

Later tonight or tomorrow. It will probably take a little work to drop it in another project though because I have rewritten the history as well. I have 1 function not in the master (to check if an input is held for a length of time), and I did away with the array-based history entirely in favor or a circular buffer. The buffer also holds the length of time each input was held. I was thinking of writing a “debounce” routine in the history test function because, and i will admit i am not a good player with precise execution etc, but for every 10 fireballs that come out on-screen my stick lights up the animation 7 times. It occurred to me that the problem might be that maybe the game will take “Down, Down+Right, Right+Attack” without that extra “Right” for the 3rd move where the code for the LEDs does not allow for that. So i thought maybe the problem was maybe not sloppy inputs but just the limited definitions we are using. So i stopped with the whole debounce thing but the time is still there so it can be picked up later or by someone else.

@ZonbiPanda I did not know that as I thought is was required to complete each circuit with each group of grounds. I will adjust the diagram, which GND did you use?

@wahoo747 looks great!! Please share!! Shows how versatile and how much we are scratching the surface with the kaimana. I like the debounce thought as it is more forgiving on the animations.

We also need to setup a way so users can pick an choose colors for each button and button combos as a option as well as even choosing a color scheme for the idle animation, meaning a color scheme that are closer to the theme of the stick. Profiles with these options is an absolutely awesome idea!!

Ok, here it is. Don’t know of any bugs but who knows…


boring info

Spoiler

First off, i wasn’t sure the best way to add on in an “open source” manner to a “all rights reserved” project so I moved as much of my new code as I could into new files and tossed the Apache 2 license up there so everyone can have at it. That being said I know there are 2 structs in the kaimana.h file that I just can’t remember how to forward declare so i left them there.
I am pretty sure I got all my #define customizations moved into the kaimana custom include file but I am not sure I caught them all. If you are looking to change just about anything, from colors to base/idle functions being called for each profile, those should be configurable via a #define compiler uhh, whatever those are. Only thing i can think of as being hardcoded color wise is the xfactor button color, its red. I forgot to add a define for that.
I also moved the pollSwitches function into the kaimana class since I was using it as well for my marvel profile and menu etc. It now returns the switch activity uint instead of the active LED int. That uint is passed to each base profile base function. I could see adding a second parameter to the base functions to handle color palette arrays but I didn’t start down that road yet. I also added a kaimana class function to test the status of an LED in case you need to do that outside of the pollSwitches function.
I started making history changes because of the debounce issue i described above but didn’t finish that either. So the only real history improvement is that it doesn’t iterate through the entire array every time an item is added, you get the hold test function, and the time stamps are with the history which might prove useful if debounce on history is ever attempted.

edit to add:
Current beta folder, changelog in there

Yep sounds good!

Bottom left in your diagram but it really does not matter as they are all tied together on the Kaimana.

Going to post a diagram of how integrate Arc Eye’s 2 this weekend, then hopefully beakersoft will do an install video!