Using Adafruit DotStar LED strips with Raspberry Pi, or remotely controlling Raspberry Pi from anywhere!
I recently started playing with raspberry pi again and wanted to build an application which would allow me to remotely control physical things attached to the Raspberry Pi from anywhere on any device that has internet connection and web browser.
In my opinion, getting this communication infrastructure setup is a major break through when building things for raspbery pi since it allows so much freedom and re-use in many applications. As long as you and the raspberry pi have an internet connection, you can control it remotely and it could be a robot, or home automation system, sensor system, or in my case some LEDs.
Most projects communicate directly to the raspberry pi through physical buttons using GPIO or perhaps Blue Tooth, and these have advantages like inherent security based on proximity to the device but they are a not as fun and flexible in my opinion. What if you’re away from home but still want to talk to the device? What if you want multiple people to communicate simultaneously? Or perhaps multiple people in different locations get feedback from the device? Luckily we have a reliable way to communicate all over the world, it’s called the internet, lets use it!
In my case I didn’t care much about what the raspberry pi did as long as it was controlled remotely so I thought a simple fun project that has a lot of immediate feedback is lights. I found these awesome LED strips from Adafruit: https://github.com/adafruit/Adafruit_DotStar they can control each individual LED and communicate over SPI bus. They also come with nice JST connectors.
Library which takes a queue of colors and an instance of LED strip. It animates from color to color using the transition specified and sends the current color to the LED strip.
Application which connects to firebase server, watches /colors reference for changes, and syncrhonizes changes with instance of ColorQueue which animates colors on an LED strip.
REST API for communication with Firebase server and adding color data. The color data in firebase would then be watched by another application such as ColorQueue-Firebase which would transfer the color data to a physical LED strip.
Web Application which provides interface to send requests to ColorQueueApi.
The first place to start is to just get the Raspberry PI communicating with the LED strip, controlling basic things like setting an LED to a color. Technically you could use any LED strip, but I would recommend the ones from Adafruit. They have been putting a lot of effort into building not just great hardware but an entire platform for wearables and LEDs. They don’t just resell hardware they build custom hardware that’s easy and reliable to use along with libraries and tutorials to get started.
This library is one step higher level than the DotStar library. It understands how to go through an array/queue of colors and transition between them passing the color information to the LED strip. This library uses the Penner easing functions such as “linear”, “easeIn”, “easeOut” to calculate the next color to send to the LED strip. Learn more about penner functions here:
Again, this library does not have a hard dependency on DotStar, you give any object that implements the ILedStrip interface:
This application is one level higher than the ColorQueue. Its responsibility to is to connect a database over the internet, read the data, and anytime it changes synchronize the changes to the queue of colors in the ColorQueue library. Then of course the colorqueue library will see these changes and affect the output of colors on the physical LEDs.
If you’re not familiar with Firebase, it’s a distributed document database that automatically synchronizes changes over web socket communication which makes it great for applications which need real-time updates across various clients. Also, document databases are schema-less and allow you to directly send up JSON. This makes them flexible and great for prototyping because as your design changes you don’t have to the overhead of updating the table schema and migrating data. You just push your data and it will be saved. They also have some of the best documentation in the business and have other built-in things such as server side validation, authentication and hosting if you’re interested. It’s part of a new type of service coming up in the industry which is Back-End as a service. You the developer just focus on the UX and application and let Firebase handle the data. That being said, it’s easy to think of using Firebase for everything. You need to make sure your application requires the real time updates and web sockets or there might be better alternatives. In my case Firebase worked great and was able to get setup and running with in a day.
The application provides a simple REST API for communication with Firebase server which is holding the color data. The API can add/remove or clear all colors. The color data in Frebase would then be watched by another application such as ColorQueue-Firebase I mentioned above. This extra API layer isn’t strictly needed as the web applications could directly communicate with Firebase, but having this custom server means I can have it communicate to Firebase using a secret ID and then setup firebase to only allow write operations if they are from this server. This prevents other people from sending request to my server to post whatever data they want.
Finally we get to the fun part. The web application.
This is where you get to design the controls for interacting with the Raspberry Pi. If you were controlling a robot you might have some webcam output, and some buttons to press for changing robot modes and accepting keyboard input etc. In my case it’s just simply a list of colors showing what’s in the queue.
At the bottom you can pick from pre-defined rainbow colors or enter your own custom color:
Ideally, there would be feedback on the website so all of the users could see what color the LED strip is currently at, but for me I’m usually sitting right next to it and I was a little too lazy to figure out how to add that back in.
Here is another close up of the custom board used to communicate with the Raspberry Pi. It is just a 5V DC barrel jack connected to a 1000 uF capacitor (recommended by the tutorial, to prevent voltages spikes from hurting LEDs) to the 3v-to-5v logic shifter. The power is passed through to the LED strip and the MOSI and CLK pins from the Raspberry Pi are connected through logic shifter into the LED strips’ own data and clock pins. It’s important to note that the Raspberry Pi is still getting power through the USB port. They only share a common ground but their 5V are not connected. I’m not an export on this part, but from what I read, Raspberry Pi is not setup with the right protections to be powered through the GPIO port like other boards such as Arduino are so it’s best to always power it through USB and keep it isolated from other power sources.
Using a database as a common place of shared memory between the Raspberry Pi and remote application allows you to decouple the two and opens possibilities to many new types of applications. You could have a team of robots all looking at the same data online and multiple users logging in online each taking over control of one of the robots to simulate a robot soccer game or perhaps recreation StarCraft in real life which would be one of my ultimate Raspberry Pi projects. Maybe with the help of this walk through one of you can help build the next cool raspberry pi project. Let me know what type of application you would build with this type of technology in the comments!