So after looking through different ways to control LEDs, I learned that you can control LEDs directly from the roboRIO, but I also found that many other teams use controllers like the blinkin and the CANdle. Which way is better and why?
1 Like
this year we used canifier by ctr, but we bought rev blinkin led because the canifier work on 12v And it drains the battery fast.
i know you also can controller them with pwm (with addressable led strip -“not regular”)
everything has been re-stated or corrected in this thread, so editing post because i dont wanna accidentally spread mis-information by being stupid
2 Likes
It is so easy to use addressable LED strips directly with the Rio that the other options don’t really make a lot of sense to me. Wire SIG and GND to a PWM port, and +V and GND to a sufficient power source, add a few lines of code, and then your programmers have complete control over the light patterns.
I think the CANdle and similar controllers do include voltage regulation, so they can be simpler to use from an electrical standpoint. But they are not really any easier to program, and then you have less flexibility with the variety of light patterns you can generate.
Regardless of how you control them, keeping the total number of LEDs low will always make it easier to stay inside your power budget.
3 Likes
PWM control from the roborio, power from a small 5v converter purchased off of amazon. Just took a little soldering, but way cheaper than CTRE/REV controllers and just as easy to work with imo.
1 Like
But no output in disabled 
is that one of the main draws of using a CANdle or canifier?
As others have said, the WPILib LED library works no problem, is probably the easiest method, and is definitely the cheapest.
We actually found some LEDs that were marketed as 5V but could handle a 6V input. So we just plugged them straight into the roboRIO PWM port. 2.2A @ 6V is enough to power a handful of LEDs, there’s no risk of killing the +5V rail if something shorts, and it means we didn’t have to worry about splitting the different power and signal sources. This relies on 6V not burning your LEDs though, so YMMV.
3 Likes
Partially, but PWM/typical motor controllers will be limited to enable only.
As mentioned, you can use the CANdle or control off the roboRIO. Really just depends on your preference. They each have their pros and cons.
1 Like
You can output to AddressableLED when disabled. My team did it—our robot matches our alliance color when disabled, with moving lights.
3 Likes
Yes, normal PWM control or via a motor controller will not work in disabled.
1 Like
There are many options here. Personally, I like using SPI LED strips (such as adafruit DotStars). Blinkin will do addressable LEDs, but has been out of stock for some time. It really all depends on what you want to do, how much you want things to be turn-key vs. how much you want an electrical/programming mini-project, etc.
tbh i’m kinda wanting a programming project for practice for me and other coders
The CANdle can definitely control both addressable and RGB(W) strips, so you can just cross out your whole first sentence.
1 Like
4419-LED Strip onBoard Robot Summary.pdf (495.8 KB)
We created a brief summary to illustrate how to utilize the WPILib addressable LED function.
The electrical connections for the SPI LED strips are not bad, but this needs to happen before there’s much to try out as far as programming.
There are four wires to connect on the end of one of these LED strips. One is +5V, one is GND, and two are for SPI. So you need a +5V supply. If you are testing on some kind of bench setup, this could be an AC adaptor. But, if you are testing on a robot (or on a bench that’s battery powered), you will need a +12V to +5V converter. How much current you need depends on how many LEDs to plan to use (and also things like how bright you turn them on all at once). If you are just trying out some code, you probably have something lying around (if not already on your bench or robot) that has enough current to get you going.
To get started, the easiest thing to do is to get the +5V from the roboRIO, but you can only use 1A this way (conservatively, about 15 LEDs, at full brightness).
This page has details on hooking these up. The roboRIO has SPI on a dedicated 10-pin connector, and also on the MXP expansion port. Note that the roboRIO SPI pins are 3.3V, and the LEDs are spec’ed for 5V SPI. I can confirm that if you hook things up in a way that follows the bottom picture on the page linked above (with the extra IC for level shifting from 3.3V to 5V), things work well.
On the roboRIO, you can use these pins:
1 - GND (the upside-down tree symbol)
3 - SCLK (SPI clock signal, connect to “CI” on LED strip)
5 - MOSI (SPI data signal from the roboRIO, connect to “DI” on LED strip)
6 - +5V (only use if you don’t have another +5V source and respect the current limit)
* - You may also want to use one or more of the CS0/CS1/CS2/CS3 signals
I would recommend using one of the CS signals, and if you want multiple strips, using one for each strip. But, you can get away with just ignoring these unless you are doing other things with the SPI pins on this connector. You can get the three signals you must have (GND, clock, and data) from the roboRIO with a PWM-style connector, so that’s easy. The level shifting wiring is easy to prototype, especially if you have a small breadboard around (was in KoP some years and can get from adafruit or elsewhere if you don’t have one).
There’s very little code to get going, and you have total control of the LED colors and patterns. Of course, if you get fancy with these, you will need a bit more code.
1 Like
For teams that use AddressableLED, what kind of effect does doing moving patterns (like fire or waves) have on the RIO’s 20ms loop? Is it something to be concerned about when choosing what method of LED control to use, or is it generally a non issue?
The way that we programmed our LEDs, there are N calls (1 per LED) to set color every time our LED system’s periodic() method gets called, regardless of whether patterns are static or moving. I didn’t see any significant effect on the robot loop caused by said LEDs.
At a lower level, I’ve read that the serial control signal sent out to the LED strips from the PWM port is generated in the FPGA, so is effectively running in hardware and should have little/no impact on Rio computational bandwidth.
@Thad_House could confirm or rebut this.
1 Like
That is correct. The code just puts the data in a memory buffer; the FPGA handles all the signaling from there.
2 Likes