Double Limelight Problem

Hello everyone,

Team 316 experienced a very unique issue i havent seen in a few years.

Going into our district championship we added a 2nd limelight onto the robot. (Information is important for later)

When we arrived we expereinced constant connection issues to the field almost every match. Whenever we noticed the robot would not connect to the field we would simply power cycle it and furing the next boot it would connect just fine.

This carried on throughout the event where we would power cycle a 2nd time when loading on the field and we woukd be good to go.

However in the playoffs this quick fix of power cycling stopped working. The robot would not connect to the field for several minutes. Im thankful to the FMA FTA’s who gave us time to troubleshoot and ultimately we power cycled a 3rd time and it was fine.

All of this to say I vaguely recall when the limekight was first released teams encountering similar problems when they utilized more then one on their robot.

I cannot field any threads via searching but from my limited memory of the issue i recall some people saying the limelights would conflict with eachother and somehow that prevented connection.

In our final match of the eliminations we were advised to power on the robot, wait for the radio, and rio to fully boot before connecting our druverstation laptop.

This seemed to fix it and we cinnected immediately.

Going into worlds we want to seek advice incase we encouter this issue again. Has anyone else experienced this?

To give some context we have the limelight 3’s and they are powered via POE through the Rev mini power module. They they go to a brainbox switch on the robot.

The wiring and electrical components on our robot seem fine. This doesnt appear to be a wiring issue as we never drop comms, have this issue on the practice field, or have seen it other then when we have 2x limelights on the robot.

1 Like

I don’t have the expertise to respond to the networking portion of this question, but I would like to point out that the Limelight should not be powered via the 18V output of the REV Radio Power Module. If you are instead using the passive PoE injector cables with regulated 12V or raw battery voltage, perhaps change your wording?

Clarified to be a Mini Power Module below.

2 Likes

my recommendation is to get rid of the brainbox switch and don’t power the limelight through poe. our brainbox switch that we got this year was faulty and would randomly disconnect during matches

Because the new radio will be used at Worlds, this would be a good opportunity to redo this. The Vivid radio can take in unregulated power and distribute it to other devices via PoE, so the RPM and switch can be eliminated entirely.

Sorry, i should have clarified. The limelight is being powered via the Rev Mini Power Module NOT the radio power module.

1 Like

I have heard about this issue with the brainbox switch, however this wouldnt be the issue to our problem. This is primarily because the radio is only connected to the switch via the 2nd port.

If the switch was dropping randomly it would only effect the limelights and not the connection to the field.

Did this only start happening after you connected the second limelight?

I know 319 was having something like this happen when in our code it wouldn’t wait to deploy our code into the robot before the rio was booted. Specifically the code that our one limelight used. We fixed it by a simple check in our startCompetition() in our drive base.

Before fixing this we just power cycled the robot or rebooted the rio. Do you know if you had Comms and No Robot Code? Because that would make that way closer to our issue.

To piggy back off this.

319 had issues about not having enough protection in our code to prevent crashes before the driver station connected / near boot time.

  1. when we queried the driver station for alliance color before we were connected to FMS /DS ( which I know is likely unrelated to your issues)

  2. when we queried the limelight’s NT for the number of apriltags in the botpose_wpiblue ( buffer index [7] i believe) . When the NT entry was empty.

Adding quick checks for if Driver station was present, or if the buffer being queried was of a certain size resolved our issues of robot code crashing occasionally at boot.

Yes it only started hapoening after adding the 2nd limelight.

I believe it was an error that said

“No rio” on the driverstation

Have you shared your code? Did I miss it?

Was your code running the entire time? What do you see on NT?

Can you access one or both of the LL via webUI?

Why are you using the 2nd port on the radio? I’ve seen that 2nd radio port do lots of things that don’t make any sense.

My team used multiple limelight 3’s without a network/connectivity issues all season long. Each limelight was assigned a static IP address, each was given a unique name, and our network was setup with each device (RIO, Limelight Front, Limelight Back) were plugged into a network switch and then one patch cable from the switch went to the radio.

I will have to confirm we have all these things set from our programming team.

I have heard minor things about the 2nd port of the radio, however ive also read recent issues about the brainbox switches occasionally dropping mid match.

Ultimately we chose to go with the radio tied directly to the rio, vs through a switch and possibly risk dropping in a match.

We did not encounter this issue at any point all season except when we had the 2nd limelight cconnected.

How are your limelight’s IP addresses configured?

Which image are you on?

Our Limelights are configured through static IP Addresses, 10.3.16.11 and 10.3.16.12. I believe the first one is image 2024.2.2 and the second one is 2024.3.4. We are most likely going to upgrade to 2024.5.0 once we open the crate at Worlds.

1 Like