We’re looking at connecting a couple separate LED strips to our robot for indicators (and fun) and we want to control the separately. However whenever I try to add 2 LED subsystems to control LEDs via PWM, the robot code crashes. When I opened the WPIlib AddressableLED class, i see
* A class for driving addressable LEDs, such as WS2812s and NeoPixels.
* <p>Only 1 LED driver is currently supported by the roboRIO.
I just want to confirm that this means when controlled by rio PWM, we can only define 1 AddressableLED object?
I believe that is correct. However, you can string multiple addressable LED strips together into one long string by wiring the output end of the first string into the input of the second. If each string has 10 LEDs then the first string will be at index 0 - 9 and the second string will be from 10 - 19. The robot doesn’t know or care how many segments you cut the strip into.
You can still do that, just may need to be a little crafty.
Take the last LED of strip 1, and wire that to the first LED of strip 2. Last of 2 to first of 3 and so on. I don’t know how many lights are supported, but I’m sure you could do 100 pretty easy.
Then in your code, segment each strip by what LED number they are. Strip 1 may contain LEDs 0-19, then strip 2 could be 20-29 for example. Then you can run each of those segments independent of each other.
Ya we’ll probably have to do that if we want to go down this path, we’ll just redesign the subsystem to not only include the port but the rang of LEDs so we can have multiple subsystems and multiple commands without interrupting eachother.
Keep in mind that you can only define a single AddressableLED object in your code talking to a port, and it will be responsible for managing the entire string. Your subsystems can set flags or populate an array of RGB colors to hand off to it, but you can’t have multiple objects in code trying to talk to the same string.
Depending on how complex your lighting sequences are, you may find it easier to have the string operate as its own subsystem, and use simple flags/states to command different light patterns.
OP could consider using Java PriorityQueue to store LED commands from the various subsystems that use them. Then in Robot’s periodic, run last, after running scheduled commands and subsystems process the LED command at the top of the PriorityQueue.
We ran into this last year at the last minute trying to merge two students code together… One built a scrolling LED sign for sharing our sponsor names and the other built a subsystem to communicate robot state such as whether it can see the target, etc.
Last minute I created this class to string them togethers. It could be easily be more generalized for more virtual LEDs strips.