How to prevent the oscillation when using Limelight to get distance

l have run into a weird problem when testing my robot recently. l find that the distance to the target we get via Limelight is oscillating and the error is around 0.1. For instance, when l stop my robot at a fixed point and switch on the Limelight, the distance l get from the Limelight seems to oscillate between 2.7 and 2.8 ( it’s arbitrary).

So, how do teams using Limelight to get distance to the target prevent such oscillation?

And here is my original code.

  public double getRobotToTargetDistance() {
		return (Constants.LL_UPPER_HUB_HEIGHT - Constants.LL_MOUNT_HEIGHT)
             / Math.tan(Math.toRadians(Constants.LL_MOUNT_ANGLE + Get_ty()));

Short answer: you can’t prevent oscillation. The vision system is susceptible to visual noise which changes the detection of the target and that will show up as noise in the reported value. What you can do is filter it if the noise is an issue to the rest of your controls.


You can use the wpilib Rolling averagefilter to smooth the result a little bit. You may also need to tune the limelight more as it is likely selecting and deselecting points on the target and changing the result.

Another option is the Kalman filter from wpi (the pose estimator classes)

Thanks for all the replies! l also wonder whether you have the complete robot code which has used these filters on your robot?

Besides, l think the filter is too complicated and l don’t know the stability of it, so l would like more teams to share their solutions!

I have code where we use a median filter(wouldn’t recommend for this), although it’s an ultrasonic sensor you should be able to use the limelight instead. Also, you can simply swapt out the median filter with the rolling average filter(probably a better filter for this application) or one of the other filters(except kalman maybe I think that one has a different structure). Code

1 Like

What’s the magnitude of the oscillation in real units?

Around 0.1 meter (l don’t know if this is what you want :joy: )

0.1m variation for a 1.2m diameter target doesn’t seem like much.

Also I’m not sure how you’re calculating your shot angle, but does it help to convert the limelight reading to distance first? We cut out the math in the middle by building empirical curves between limelight reading and flywheel speed / hood angle through testing. A bit of jitter didn’t affect the (smooth) curves much.

PARTsOS11/ at controlsIntoCommands · 3492PARTs/PARTsOS11 (
Hi, what is this line mean? If l use Limelight ,should this line be like below?

  public double getRobotToTargetDistance() {
		return (Constants.LL_UPPER_HUB_HEIGHT - Constants.LL_MOUNT_HEIGHT)
             / Math.tan(Math.toRadians(Constants.LL_MOUNT_ANGLE + Get_ty()));

My team found that .05 meter error (from the average or actual) was irrelevant. Have you found that actually effects your shooter performance?

If you really want to tighten the measurement so much, then you might be able to tune the LL to give a stronger visual signal. 2.7 m is getting close to the target that it is starting to become small (target is small too close and too far) but my team still could see the target at less than 1 m (where the robot nearly touched the hub). Mount the LL as far back and as high as possible. Use bright lights when that close. Brighten the image with the various LL controls (tuning the LL). Try different camera resolutions.

Maybe your flywheels are vibrating and then the camera vibrates. (That could also be the cause of your inability to tune the flywheels’ velocity to your satisfaction and you hadn’t tracked down that possible problem as far as I could tell in your other threads.)

Since you have 16 motors on your 16 circuit breakers and had raised that issue in another thread, one does have to wonder what you plugged the LL into for power. Is it appropriate power and legal? Did you remove a motor so the LL can be plugged into an unregulated circuit on the PDP with no motor on its breaker?

1 Like

That may be the point! l will let my team mate check it! But since our Limelight isn’t wired on the shooter, l don’t think the vibration of flywheels will cause the oscilliation of limelight, but l wlil have a check at it.

Edit: l don’t think it is the problem of the shooter’s vibration since when l don’t enable the shooter and just let the robot move, the distance l get via Limelight is also changing with a 0.1 oscilliation.

We just wire it with our hood motor in parallel connection, and we haven’t found any problems since then.

According to my debug process, the main oscilliation is in Limelight’s get_ty(). l guess that the target image l get in Limelight is changing, which will cause the ty to change at a small magnitude. So, talking about limelight settings, which one should l set to make the target image stable?

Are you using smart target contour filter? If so, what is your range? I noticed that it oscillated with 2-4, but was stable with 2-3.

I don’t remember using the smart target contour filter. Since l won’t have time to have an access to my robot from now on, can you take a snap shot of your smart target contour filter settings in the Limelight? l will let my team mate to test it. Thanks!

Coincidentally I don’t currently have access to our limelight, as our next meeting is Monday.

Here is the pipeline we used for Carver, that served us quite well. You can see on lines 39-40 that our smart target is set to 2-3.

From the limelight website, is what it should look like:


1 Like

There are CD threads about Robot Inspectors and inspections. RI should find this rule violation and prevent you from competing (maybe yours won’t spot it).

I coach my team to meet all rules before we get to the competition. (There are CD threads about ethics, too.)

R621 *Protect circuits with appropriate circuit breakers. Each branch circuit must be protected by 1 and only 1 circuit breaker or fuse on the PDP/PDH per Table 9-3. No other electrical load can be connected to the breaker or fuse supplying this circuit.
legal breaker loads

My independent project (the students didn’t have the time for high risk, low value experiments) was to try for 5 on our own RPi code before our first competition. Trying to tease out 5 was a fun and learning experience that was TOTALLY USELESS so we used 2-3 Then for our second competition we changed to LL and used its 2-3 objects.

1 Like

What you would do is create a rolling average filter object and in the subsystem’s periodic method you would call rollingaverage.calculate and give the getRobotToTargetDistance() as the parameter. Then you can use the value of the rolling average filter and it should make the data a little less jittery, but some jitter is unavoidable.(essentially the code I linked does this but with an ultrasonic filter)

1 Like

Thanks for your kind advice! We will buy a PDH in the next few months to solve this problem.

1 Like