Pixy LabVIEW doesn't identify all signatures

Technical Programming
1

Greeting Everyone,
Our team(1577) is currently trying to use pixy camera to identify objects using color processing.
However we have encountered a problem, The pixymon program recognizes all the signatures just fine. but when we run it using labVIEW some objects are not presented.
We noticed that the brighter the object it is more likely to be presented in labVIEW.
We suspect that the labVIEW block filters out some signatures.

Can anyone shed more light on this problem?

2

I’m not sure what the pixymon does but are you sure the brightness and exposure of the cameras are not different when they are running from the program vs pixymon (ie the pixymon program auto adjusts exposure/brightness)?

3

We cancelled the auto exposure & brightness, and also cancelled the overwrite that LabVIEW does to the pixy’s settings.

Still looking for a possible reason and a solution… /:

4

We don’t do LabView, but we have used the Pixy for 2 years and actually had 2 on our robot last year.

I’m wondering what interface are you using for the Pixy?

  • Analog/Digital
  • I2C
    *]SPI
5

Good point, I really forgot to mention…
We are using I2C.

6

OK. We used I2C last year, but we program in C++. The point here is that I know that it will report multiple targets to the I2C interface, as we have seen them. What I2C address did you set your pixy to and did you provide that address to the LabView I2C interface?

Not sure what else I can offer here as I don’t know how the LabView I2C interface is implemented, but we did need to add a significant amount of code to decode the contents of the I2C packets beyond what the C++ I2C WPILib class provided. Maybe someone with LabView experience can chime in here and help with that level of information. Good Luck!

7

Have someone encounter in a checksum problem with the pixy? If so, how you get over it?
We suspect that checksum error can explain the decrease in objects we are getting in LabVIEW, in compare to what we got working direct with Pixymon.

8

Which LabVIEW library are you using for PIXY? I found one or two on GitHub and one on the NI site, https://forums.ni.com/t5/FIRST-Robotics-Competition/FRC-2017-Example-VIs-for-using-a-PIXY-Camera-with-the-roboRIO/ta-p/3594709

The Checksum error definitely occurred for me as well. But my cable was not much to speak of. Also, I think that the USB interface is the highest rate, probably includes the longest lists of blobs and probably has the fewest errors. SPI would also be faster than I2C. I’d think that I2C should be fine for most FRC uses, though.

The majority of the calibration is stored on the PIXY itself, so you should be able to use PIXYMon for that and Apply changes and connect to the roboRIO. The brightness and bus speed are the only things that I can think of that would impact the target list.

Greg McKaskle

9

We are using the one you have shared, can you also share the two Github links?

If you have a library that support the usb inteface it will be great (in the NI suite there are only spi and i2c).

10

I guess I spoke too soon. One requires an Arduino, so that leaves this one

I do not have a libpixyUSB compiled for the roboRIO. The source code is available on the cmucam site, but I decided to also do only I2C and SPI. Porting the USB code didn’t seem worth it for the project I was doing.

Backing up a few steps, can you detail the issues you see with the VIs? Perhaps post some images or some data?

Greg McKaskle

11

The main issue is that for some reason the smallest object detected by the pixy will allwas be flickering, even if it takes up half the screen . We observed that even when it should be constant, the data coming from the pixy does not send a constant hex number of AA55 which triggers the update of the x and y position.

12

I’m back at home and have a cable and I verified the behavior that you described and discovered two things that should change.

  1. The code has a sleep call of 10ms when it gets an invalid checksum. Because the typical frames are only 20ms apart, this delay to avoid hogging the CPU when framing is bad turned out to be way too big and the code worked better without it.
  2. The second issue was a misunderstanding of the PIXY porting guide’s documentation. When the guide indicated that the PIXY would return zeros when nothing was available, that was interpreted to mean “zeroes for an entire object”. But the PIXY can insert zeroes for any word. It turns out that it commonly inserts zeroes this after the smallest object and before sending the AA55 frame terminator. This caused the final object to look corrupt if the zero words are not filtered.

This is now pretty obvious when reading the C code in the porting guide, but not so obvious when the LV code was written based on the doc. And it worked just well enough to not notice the error.

While making this change, it was also easier to read two bytes at a time and to look for 0x55AA to identify a byte synch issue. I can email the VIs if you need them soon. I will give the to the appropriate folks to post on the NI site, but because of US holidays, I’m not sure when they will get up - probably not until the 3rd or so.

If you want the VIs emailed, PM with an email.

Thanks for reporting the issue.
Greg McKaskle

13