PhotonVision V2022.1.5

PhotonVision V2022.1.5 is out, now with hue inversion support, outlier rejection and picam red/blue gain sliders, as well as a slew of other bug fixes. Full release notes are on our GitHub. Here’s some quick video teasers (full resolution on Github):

As always, please drop by our Discord with any questions/comments/suggestions!


Hardware specific Pi images are also now available:




Just to add some more context to this release:

  • The hue inversion feature is designed for detecting the red balls as the red hue wraps around from max to min hue. Hue inversion is GPU-accelerated on the Pi 3 along with the other thresholding and color conversion.
  • Outlier rejection is to deal with the fact that you need to detect many targets that are small and the size of e.g. ceiling lights in the frame.
  • Separated AWB gain sliders allow users a bit more control over the colors that are captured than the single “smart” AWB gain slider we had before.

We also fixed the following bugs:

  • MMAL silently (and seemingly erroneously) selected the broken 640x480 video mode when we asked for 960x720 on the OV5647 sensor (Pi Camera v1). This resulted in the strange color issue people saw when they covered the camera at only the 960x720 resolution. This has been fixed by forcibly requesting the correct video mode.
  • There was a small miscalculation in the FOV multiplier at 1280x720 on the OV5647 (this was my mistake). The multiplier has been fixed, so people should have correct pitches and yaws on this sensor and resolution,
  • On some network environments, the roboRIO discovery feature added in 2022.1.4 blocks and prevents the settings saving task from running. This has been fixed by moving discovery and settings saving to different threads.

Additionally, if you happen to be using the infrared SnakeEyes board, and are keying based on the red hue of the retroreflective target, you’ll wanna pick up this release for that same filtering reason.

Hi. We upgraded to v2022.1.5 on our limelight 2 today and found that the pitch angles are now wrong (too small by a substantial amount). They are now consistent between 960 and 1280 resolutions but both give wrong pitch :frowning:

Very interesting. This is because 960x720 and 1280x720 are both now (after the 960x720 firmware issue workaround) using sensor mode 5 and cropping. On sensor mode 5, the resolution that covers the entire FOV of the camera is 1296x972. We crop down from that to either 1280x720 or 960x720. This changes the effective FOV of these video modes, which we account for. Clearly there’s some issue with how we’re accounting for this change in FOV. I will take a look at this on Saturday or Sunday and try my best to resolve it before the end of the weekend (I have a bit of time, but no promises).

One question for you: is the yaw still seemingly ok?

I can’t say whether yaw is incorrect. We didn’t really notice. We are at a regional event and didn’t have a chance to load or try v1.5 prior to arriving. We just loaded it this morning for on-field pipeline calibration but didn’t notice the pitch issue then. We only noticed a problem (badly overshooting) once we played a practice match. Then it took quite a while to isolate the problem to the new PV software and then we just immediately reverted to the prior release…

1 Like

Oh dear… I’m really sorry about that. I tested the pitch with this change but I don’t really have a great set up for making sure it’s totally accurate (I’m not even in possession of a real vision target). Good luck at your regional.

Thanks and NP. We knew there was a risk updating at the last minute. We should have validated the pitch / distance during on-field calibration time, so that’s on us. FWIW, the v1.5 vison pipeline updates seem nice and we look forward to using the latest version once this issue is fixed…

1 Like

Update: I have a couple of ideas for where things are going wrong, but I’m currently a bit bogged down with school. My spring break is next week so worst case I don’t have something done until that time.

Okay. I hope it doesn’t consume your spring break, but if you do get it working in the next two weeks we’ll be excited to have it for our 2nd regional and will definitely try it again. Thanks!

I’m not sure what the issue is, but I flashed a limelight with the gloworm image and attached an ELP USB camera. The ELP camera shows up in the dropdown but does not work when selected. The limelight camera has a purple hue and the exposure cannot be raised to what would be needed to track cargo with it. So for now, my team is going to stick with the official limelight software. However, from what I’ve seen on your website and documentation, this looks really cool, and I look forward to maybe using it next year.

Two notes that may be helpful to other people reading this:

  1. The purple hue will go away if you adjust the white balance sliders under “input”.
  2. We currently limit exposure so that it doesn’t go so high that it reduces FPS. Currently you can unlock a higher exposure by selecting a higher resolution. In a future release we’ll look at allowing higher exposure and warning you if you go so high that it reduces FPS.
  3. Not sure about the ELP camera. Those generally work; most of our incompatibilities come from cscore setting properties that are unsupported by the camera… If you are able to send logs we could probably see what’s going on and add an internal quirk for that camera.