Programming LEDS, CANdle vs RIO vs Ardunio

Technical Electrical
,
1

I want to add LEDs to our robot, but after looking online I solidified it between these 3 and was wondering about anyone personal experiences regarding these (especially in a programming stance). I really like the ease of use and the prebuilt animations of the CANdle, but is it worth the price tag? A few teams have told me that a CANdle’s functions can be replicated using just the RIO, but its harder, I wans’t able to find code examples of this online however.

2

The wpilib documention for the Addressable LED is a good starting place

This topic I posted on a couple of seasons ago has links our sample code and how to use led in simulation

2 Likes
3

Don’t forget the REV Blinkin as another option.

2 Likes
4

How many LEDs do you want to add and do you want them to react to anything the robot is doing?

While there are other types of LED lightning options given your questions, I am assuming you are going for 5V addressable LEDs.

With that assumption, if you are only want to light up a few LEDs the RoboRio can be a good option. You can wire up a full string to the RoboRio but it alone won’t be able to provide enough power (Amps) so you would need a secondary power supply and a secondary power supply wired up incorrectly can be dangerous to your RoboRio so I wouldn’t recommend it with the other options available.

If you are looking to hook up a normal amount of light both the REV Blinkin and the CANdle are good options as they already come with the power supply needed to run a normal amount of LEDs (5A from the blinkin and 6A from the CANdle). Personally I would go with a CANdle over a Blinkin as it has more options on what your lights would look like, but if blinkin has the light modes you want it would let you save a few bucks.

Finally if you want enough lights to blind people or just want a electrical/programing project an Arduino with a power supply is the way to go.

5

We’ve done them all… We’ll use the CANdle until a new option hits the market.

Simplest to wire and code while giving the option of individually addressing the LEDs.

6

We use an arduino with separate power supply.

  • It can be easily programmed and tested without a roborio
  • no additional traffic on the CAN bus
  • no additional power or programming load on the roborio other than a few digital outputs
  • digital output from roborio to arduino is easy and a nice programming/hardare exercise for new students just learning the basics.
  • well supported
7

We used Rev Blinkin for the last two years and experienced a known issue where it switches between 5 and 12 v on a power cycle. We will be switching to candle for a better plug and play option.

1 Like
8

We’ve had the same issue for FTC and FRC. We assumed it was something pressing the button during movement. We were actually planning on using the pwm ports directly. But we also are testing the CANDL.

9

This topic comes up frequently on this forum; you will find many other posts with good information. I summarized my thoughts on the topic quite recently in this post, so I won’t repeat the details here. The TL;DR is: for my team, the Rio is the clear winner (least cost, most flexible, easy to use).

1 Like
10

We have used custom circuits for a couple years (Arduinos, LightDrive), but for the offseason events this season, we switched to using the Rio directly. It was really easy to use.

Advantages:

  • The lights are programmed with the robot, so updating for strategy/indications are cake. (otherwise, you have to send commands over SPI/I2C/Serial, and you just doubled your work)
  • Because the AddressableLED uses the ASIC to send the W2812B pulses, there is very little loop time hit. My measurements put it at ~0.1ms loop time hit to drive 74 LEDs.
  • Edit: You can run the AddressableLED in simulation for testing purposes, which I don’t think the other solutions support.
  • CANdle uses CAN bandwidth, and we were at around 80% usage without lights, so we didn’t want to take the risk with CANdle.
  • With the Rev Blinkin, it’s control is a PWM signal. FRC locks the PWM ports while disabled, so you can’t switch patterns while disabled. (I have never used it, but when we used the LightDrive in PWM mode, I ran into this)
  • Neat trick, when the LEDs light, you know you can connect to the robot Wifi then, as the boot time of the Rio is right around the Radio boot time (I think the Rio waits till it gets an IP before it starts your robot code). If your pattern changes every loop, you can see when the Rio falls behind in loop time too. (as your pattern stops) :wink:

Notes:

  • The AddressableLED class only supports 1 LED string (as of 2023, [Edit] and 2024). Now, you can daisy chain strips together around your robot to get more lights. Also, you can use a Y cable to address 2 strips with the same commands (we actually double Y cable our leds for 4 strips of identical commands for left/right side, and front/rear side of our arm).
  • The practical limits are ~500 LEDs to update at 50Hz (the 20ms looptime), and ~20mA per LED to drive with a max of 60mA/LED if they are white.
  • You will want to trim out the power wire from the Rio PWM cable and splice in a 12-5V converter like this to power the strip. The Rio only has 2A of power and it’s 6V (it will work, we did testing with a 10 LED strip directly to the Rio and nothing blew up for a couple hours, just really bright).
  • We made the LEDs a subsystem so you could schedule commands to run on it. It made it pretty easy to switch between commands, fire commands when needed, and set a default pattern during a match vs disabled. (We actually had 2 subsystems, one for the arm length, and one for a strip in front, the arm ones were the master, and the front strip just manipulated a section of the strip, but since it was a separate subsystem, you could have 2 patterns running at the same time)
  • This year, we had 4x strips of 47 LEDs down our arms and 27 in the front for 215 total (only 74 actually addressed though).
11

I just saw the part in the Chief Delphi post that you can run the Addressable LEDs in simulation, and that’s amazing! It made my day seeing our LEDs work for testing code.

You just have to go to Hardware->Addressable LEDs, and bam, there is your LED strip running. Another reason to use the WpiLib solution.

1 Like
12

The costs actually don’t go up much at all as you add more LEDs. You can drive over 5000 LED’s with the RIO, and can do so with basically no CPU cost (And yes I’ve tested this).

This is still an FPGA Limitation in 2024.

13

I was basing my estimate on the W2812B spec of 800kbps data rate. At 24 bits per LED, and running at 50Hz, you get about 500 LEDs that you can address before you saturate the bus. You could slow down your transmission rate to address all you want, just the “frame rate” would be slower.

14

Ah, you’re right. I’m off by a factor of 8 in my calculations. Sorry.

But yeah if you don’t care about update rate it can drive over 5000 in one go.

15

Hi

Just to clarify, when you say you used Rio directly, do you mean the AddressableLED API that you mention later?

You say that the Blinkin is locked while disabled since it uses a PWM pin (I agree), but doesn’t AddressableLED also require using a PWM pin (as per the API)?

What am I missing here ?

Phil.

16

The AddressableLED uses the PWM pins, but because it’s in the FPGA it’s bypasses the disabled lock and just works. This is ok because the signal is massively different from what a motor controller expects.

The Blinkin looks for the same signal a motor controller looks for. And those signals are blocked by the FPGA except when enabled.

2 Likes
17

Cool. Thanks for the clarification.