<< return to Pixycam.com

Firmware update for FTC - Rev Hub / Modern Robotics CDIM

Hi there, is there any chance that you can merge the pull request so this becomes the official version? FTC is disallowing use of the update since it isn’t “official Pixy”. Also, are you open to considering additional custom algorithms?

Here was the link to the FTC forum question ref Pixycam…

Hello,
This is an interesting requirement. I wonder if we have an FTC version as a branch, or just posted in the downloads section if that would be sufficient?

Edward

I was able to run Pixy at our state competition last year using this code as it was made public and was posted to the Pixy Forum, this year I plan to add java blocks support and add code to support new line following for Pixy 2. Been on the road for the last month but soon as I make it back home and start meeting with the team I will start working on it.

Andrewiski
Team 6494

Andrewiski, you may want to revisit legality of use. While most of the inspectors wouldn’t even know what to ask about the cam or its internals, the GDC, when asked if the Pixycam was legal, responded as follows:

Yesterday, 01:47 PM
Originally posted by FTC4634

Subject: Intelligent Sensors & User Programmable Devices re: Pixy/Pixy2

_Question: Can the GDC please clarify the ruling that the Pixy/Pix2 are allowed “As long as they remain non-user programmable”?_
makes no mention that sensors cannot be user-programmable
Assuming the above was an accidental omission, that makes the Pixy/Pixy2 totally useless, since they must be programmed through PixyMon in order to be useful.
If PixyMon is simply counted as an exception to “programming” it, then does that mean that we cannot use the user-created FTC firmware recommended by the manufacturer on the FIRST Robotics support page which enables better compatibility with the MR CDIM / REV Expansion Hub?

Answer:
disallows “other electronics” and provides as a partial list of examples a series of user programmable devices. Intelligent sensors fall into this same category if they include user programming capability.
PixyMon is a configuration tool, not a programming tool and is allowed to be used to configure the Pixy/Pixy2 modules.
Loading user-modified or third-party firmware onto any module would be a disallowed modification of the module ()

Hence, the reason for our post / request of Pixy to make an FTC version an official version downloadable from the Pixy site, or make the FTC version the “official version”. Also, we had developed some other filtering algorithms which would be useful, but are at the moment considered illegal as if they were “programming” the pixycam. sigh.

Can you describe the filtering algorithms? We’re always considering new features for possible inclusion in future firmware versions.

We can provide (redistribute?) a FTC version on the firmware on our website. We don’t have FTC hardware for testing/QA, but we’re open to posting versions that are provided to us in the downloads section. I’m not sure if there is a generally agreed upon version that is best, or if there are a couple versions FTC users would want provided, but we’re happy to help as we’re all fans of FIRST :slight_smile:

Edward

Well, the particular algorithm we created that we’d like to use this year is similar in functionality to Blobs::getMaxBlob() except that rather than returing the blob with the largest area, it returns the blob with the highest (lowest-in-frame) Y-value of the top edge that also passes a minimum area filter.

While that specific algorithm might not be useful to a large range of users, adding multiple different flavors of it (such as highest-in-frame Y and left-most-in-frame X, [and being able to choose which bound is used for comparison] etc.) could prove to be useful for many people.

We also modified the DAC code to call our own function rather than Blobs::getMaxBlob(), and also created our own I2C protocol that is similar to the Lego protocol except that it only has one register which returns the blob selected by our filtering algorthim.

What I would suggest is as follows:

  1. Add multiple different flavors of our algorithm to Blobs.cpp
  2. Modify PixyMon to allow changing the algorithm used to select which blob is returned over the DAC
  3. Adding the FTC protocol created by Andrewiski to the firmware, with an additional register that simply returns a single blob selected by your choice of one of the filtering algorithm flavors which would also be set through PixyMon.

P.S. what color space does the Pixy currently use for color thresholding? HSV? LAB? YCbCr?

Thanks!

Michael
Team 4634

Hi Michael,
Thank you very much for the information. I will add it to the features document and present to our engineers.

Pixy uses an opponent color space – blue-green and red-green. It divides by intensity (red+green+blue) before it’s final threshold operation to be more lighting-robust.

Edward