Hello, our team is attempting to implement a limelight into our robot for the next season. When the robot is positioned in front of the reflective tape, the limelight fails to successfully detect it as a target. The “tracking rectangle” that appears around the target is extremely jittery and occasionally nonexistent, no matter the settings that we try. I have a picture attached below if it is of any help. We would appreciate any help with getting this problem sorted out. Thanks!
Make sure to adjust the hsv values to match the reflection from the tape.
Change “video feed” to “threshold” to check the quality of your color filtering. If the threshold feed shows a solid white box, your filtering is not the problem and you will need to open up the parameters on the contour filtering page.
Also, I recommend updating your Limelight image. Everything is better in the 2019 software!
These are great suggestions and I will elaborate a bit on the matter.
(1) We used the “Eyedropper” function to choose the reflection of the tape. This automatically changed the HSV values for us and did not register a valid target (tv:0). We adjusted the values then manually to no avail.
(2) When we changed the feed to threshold, we did get a white rectangle, but Limelight continued to not register this as a valid target (tv:0).
(3) Amusingly in a frustrating manner, we adjusted the value slide bar such that the “glow” on the edges of the tape then registered as a valid target, but then when we adjusted the slide bar values to eliminate the glow, we went back to no valid target.
So the program will register a target, but just not our rectangle.
For reference, we opened up all the Contour filtering being that in threshold only the white rectangle was on the screen. All the bars were set to the lowest minimum and highest maximum and still nothing.
We will be sure to update the image ASAP and see if that helps.
If you see the white pixels passing the hsv threshold properly then the issue is the contour filtering. Make sure you are in single target mode and don’t have a direction filter.
Thank you Brandon for the recommendation to update the image. Did that and now there is a valid target as seen here, but there is another roadblock occurring.
When we use the sample code from your Limelightvision.io website (https://www.mediafire.com/file/f35w3wllbmj9yt7/DeepSpaceLabviewExample.zip/file/), we are using the Limelight Differential VI to read the values coming from Limelight.
At the same time as the Limelight is reading the values seen above, we are seeing the following in the program:
This seems to mean that according to LabVIEW the Limelight is reading all zeros when we know from simultaneously seeing the live feed that this is not the case.
Any help or advice would be appreciated. Thanks!
Do you have the network table start server block anywhere in the code? And is the code being run inside a while true loop?
For the first question, are you referring to this:
If so, then yes, but we were not certain where to place this. So in that code given via the Limelight website we inserted that into the Begin.VI, Teleop.VI and the Limelight_Differential.VI all in an attempt to cover our bases. In the image of my last post, I had disabled that block just to see if there was an issue of redundancy of reading values which was causing the issue.
For the second question, that code is a sub VI being called up in Teleop.VI when button 0 is pressed. So I think that would qualify as a while true loop, yes?
We feel like we are just missing a step somewhere in the communication between Limelight and the roboRIO via the LabVIEW code.
Some more quick checks:
The text in your code for the network table entry looked a little weird. Just make sure it is /limelight/ty or /limelight/tx, etc. Also in our code we had the NT server implementation vi outside the while loop but I’m not sure if it will work inside. I also sent you some basic sample code in your pm’s.
Thank you for the help, but we continue to have the same struggle.
We can see a valid target via the Limelight web interface with non-zero values for tx, ty, ta, and tl, but when we execute LabVIEW programming, we read all zeros.
Anyone with advice would be appreciated.
Why are you declaring the limelight network tables location as /limelight* ? I would assume that this will always return a zero since it is not a valid location due to the *. If you did not rename your limelight in the settings page, it should default as just limelight.
On the quickstart example, it looks a bit different: https://limelightvision.io/pages/getting-started-with-limelight
The API page in the documentation also tells you what other values you can read from what Limelight publishes if you’re interested in that as well: http://docs.limelightvision.io/en/latest/networktables_api.html
jdao, I did not change the name of the location and/or variable from the example you provided (NB: the example you provided has “limelight/tx” in the box, when the updated samples are “/limelight/tx”. Not sure if that makes a difference.)
In the pink boxes I have it as provided with “/limelight/tx”, for example. However, when I choose to highlight the process in LabVIEW (lightbulb icon), then this is what happens when I run the code. Those new pink boxes show up with the “*”.
Note that when I do not highlight the process, but instead run the code continuously, then when I probe the line coming from the pink box, I do get “/limelight/tx” as expected, but still no non-zero reading.
Could there be a reason why the “*” pops up as it does? I do not know.
Maybe it means that limelight isn’t properly publishing its values to the network tables. Have you set your team number in limelight? Have you given it a static IP?
If the limelight has a static IP, can you try accessing the web interface with that instead of using limelight.local?
On your PC run the OutlineViewer utility. You may need to install the VSCode software since I know it to be installed in the FRC2019/Tools Directory.
This tool is a great view to everything being published to the NT. It will point you to a code issue or LimeLight one.
Check the frc shuffleboard to see if the values are being added to the networktables.
As an update, though I do not know the final fix, it is fixed.
I re-imaged the roboRIO and also reconfigured the radio just to eliminate other simple fixes. As a possible error, the radio configuration tool gave me an error stating I needed to update the firmware on my radio. Maybe it was just an old radio that worked enough to drive and see Limelight, but not new enough to read values??
Well, that fixed it. The values are being read loud and clear now. Thank you all for helping along the way!! Love the support from the FRC community.