Limelight giving an incorrect tx value of zero

[pfreivald]

So we have a frustrating issue that’s messing up some good portion of our shots–when we read the tx value from the network table, we expect it to be zero when the target is centered (or within a calibrated center); but maybe once every 5-6 times we shoot, the limelight will either

(A) see the target and arbitrarily assign a tx value of zero even though we’re off by 3, 5, even 15 degrees. [See picture below. The robot immediately moved to the next step in our “Shoot Command Group” because according to the Limelight, this was tx = 0.0, when it clearly was not.]

or (B) we can be targeting and the error (which is just a print of the tx value) suddenly drops to zero. [See chart below. Our value goes from -6.andchange to 0.0 without the robot having moved a whisker.]

Right now we have our targeting command on an IsFinished() that returns Math.abs(tx) <= Constants.deadband (currently set at two pixels), so the moment this happens, our robot shoots, even though we’re not properly aimed.

I believe our code is fine such as it is, in that it works ~80% of the time; it’s the network value that suddenly drops to (or starts at) 0.0 for unknown reasons that is causing this behavior. Our LEDs aren’t going off, lighting conditions aren’t changing, etc.

So, two questions:

1. Is there a hardware fix that can keep this from happening?
2. If the answer to 1. is “no,” then is there an easy software fix to, say, grab an average (or even better, average-drop-the-lowest) tx value over several loops to see if we can jump past it?

Thank you very much!

[aidangoettsch]

Are you logging tV when this happens? Is the target becoming invalid for a frame or two and then coming back?

[pfreivald]

We have not been logging tV – the only value we’re using is tx.

I’m not certain whether or not the target is becoming invalid for a frame or two; the command group moves on once tx hits our deadband range. Earlier we set up a counter in execute that said

if (tx <= deadband) {
counter = counter + 1
}

and while we would log no tx values of 0.0 for some shots and the command wouldn’t finish, the counter would still climb.

[aidangoettsch]

I think using tV would solve your issue. I’m pretty sure that the limelight returns 0 for tX and tY when it doesn’t have a valid target. You could change isFinished to return tx <= deadband && tv != 0.0;.

[pfreivald]

I’ll give that a try, thanks!

[jasenj1]

How are you getting tx?

Here’s how we get it:
NetworkTableInstance.getDefault().getTable(name).getEntry(“tx”).getDouble(0);

The parameter passed to .getDouble() is the default value if no value is found/exists.
See the docs.

In floating point numbers, EXACTLY 0.0 is extremely unlikely, so do a check for it and throw out any readings that are exactly 0. Another option would be to pass a different value to getDouble such as Double.MAX_VALUE or Double.NaN.

[pfreivald]

Worked like a charm, thank you!