Cone Causing Limelight Target Jitter

We have tuned the color threshold on our Limelight for the yellow cone so it’s pretty tight. However, we still are getting LOTS of jitter between 2 positions.

If we set the Output Targeting Region to “bottom”, we can see that it’s jumping randomly between 2 possible positions. Half of the time, it thinks the long edge of the cone/object (blue rectangle) is the bottom. We thought that adjusting the W/H ratio would solve it, but that actually just made the Limelight not register the cone if it was on its side. How can we make the Limelight stop thinking the edge of the cone is the edge of a rectangle?

Any other suggestions? Can anyone shed some light on this (so to speak)?

Thanks for your time.

1 Like

Could you post photos of what the detection looks like as well as current limelight settings?


Strange how the fist image loose the entire right section of the base. could it be seeing this as two blobs at times? What are the the erosion and dilation setting? Bosting the Dilation could weld them together.

Good eye! Took me a minute to notice the bounding box wasn’t - even after you pointed it out. Blur may also help the OP and maybe the HSV is a bit too tight. That may cause two blobs if a tiny line of “imperfection” wasn’t smoothed out. That would be hidden behind the bounding box outline.

Limelight doesn’t have a user accessible blur adjustment. The second image does show a dark line shadow.

I’m curious if the op used the grouped targets like we used last year and set the range to 1 - 2 targets if this jitter would smooth. Though when it was just a single blob any other noise would get added. If that’s the case the outliers filter could help.

I believe the blue rectangle here is the minimum area rectangle, or the rotated rectangle which bounds the three red points using the smallest area. The rotation of this rectangle can jump around a lot as you see for small corner point movements. The yellow bounding rectangle is also not great as the center does not always line up well to the “center” of the contour.

I don’t think you can do much about that from the web interface, you might have better luck finding the average of the raw corners and finding yaw/pitch with that.

Thank you, everyone, for your replies.

@cpapplefamily We’ve tweaked the color threshold so there is no longer a dark line shadow. I’d like to try your advice at practice today, but I don’t see any erosion or dilation settings–Aha, I see there is a software update available that would open up new possibilities for tweaking settings… Also, when you say “outliers filter”, are you talking about the “Smart Speckle Rejection”?

@Quake Unfortunately, I don’t think the Limelight can output the coordinates for the raw (red) corners. I would love to use the yellow rectangle, because it does not jitter. However, as far as I can tell, the Limelight can’t output any coordinates of the yellow rectangle either.

I’m not familiar with the current limelight interface, but I think you can enable raw corners. It mentions “raw contours” there but I believe it means “raw corners”

That’s worth experimenting with, definitely. Thanks for the links. You’ve drawn my attention to the fact that the Limelight can actually send way more data than just information about the target.

Another idea we might try today is using separate pipelines for a cone that’s tipped vs. upright, and then using the W/H ratio to filter out the offending target shape. We’ll keep you posted on how that works out. Edit: I’m not too confident about that, because the jitter will persist. It will probably think there’s no target half the time instead of a tilted target. We’ll still try it though.

Sorry for the late response, but i’ve been looking into this myself. I believe “thor” and “tvert” give the width and height of the yellow box. You can also find the equivalent of the yellow bounding box by finding the maximum and minimum Xs and Ys of the corners like this:

var corners = tcornxy.get();
if(corners.length < 2) return;
double minX = corners[0], 
       minY = corners[1], 
       maxX = corners[0],
       maxY = corners[1];
for(int i = 2; i < corners.length; i+=2){
   var x = corners[i];
   var y = corners[i+1];
   if(x < minX) minX = x;
   if(x > maxX) maxX = x;
   if(y < minY) minY = y;
   if(y > maxY) maxY = y;

and find the center by averaging the max and min. Also, the option you want is “send raw corners” in the output tab. There is also a “send raw contours” option but that does something different.

SOLUTION: On the “3D (Experimental)” tab, we set “Contour Simplification” to “2” and the results are as smooth as butter!

BIG THANKS to Brandon_Hjelstrom (co-creator of Limelight) for the suggestion.

Hope this is helpful to other teams.

@Phlogiston Thank you for that code. We will keep it in mind for the future.


Update: Unfortunately, the problem sometimes still occurs–much less often than before, but still about 1/4 of the time. Screenshots below:

Can you try setting corner simplification to zero and disable send raw corners?

I actually don’t have an option to set corner simplification to zero. “2” is the lowest it will go.

We tried disabling raw corners, and it still jitters.

Working on an update that will allow you to select the center of the unrotated box which will never jitter.


This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.