<< return to Pixycam.com

Pixy data returning slower than Arduino scan time?

Pixy Software
#1

Hi,

I notice that when I use @Serial.println(blocks);@ after getting the blocks, I get…

000000000000010000000000000100000000000001

So, basically, every 13th or 14th scan, it will return the correct “1.” The object being detected is right in front of the Pixy and when I use PixyMon, I can see that the Pixy is constantly detecting the object at all times, so it is not an issue of the Pixy not correctly detecting the object. I believe this is an issue because the Arduino is scanning much quicker than the Pixy is returning the data. I am using I2C communication. This presents a problem because I am turning an LED on the PlayStation controller depending on if it sees an object. So, it really slows down the code if it’s constantly turning on and off the LED even though the object clearly can be detected. Just in case, here is my code:

@uint16_t blocks = pixy.getBlocks(); // returns number of blocks
int i = 0; // if there are “blocks,” there is always one color code that starts at 0@

Serial.println(blocks);

// determine if the Pixy can detect any color signatures
//if (isTrackingInitialized) {
	if (blocks) {
		if (blocks == 2) {
			CS1Detected = true;
			CS2Detected = true;
		}
		else if (pixy.blocks[i].signature == CS1) {
			CS1Detected = true;
			CS2Detected = false;
		}
		else {
			CS1Detected = false;
			CS2Detected = true;
		}
	}
	else {
		CS1Detected = false;
		CS2Detected = false;
	//}
}


//if the Pixy can determine any color signatures, set LEDs to alert the user
if (CS1Detected) {
	if (!isLED4On) { PS3.setLedOn(LED4); }
	isLED4On = true;
}
else {
	if (isLED4On) { PS3.setLedOff(LED4); }
	isLED4On = false;
}

if (CS2Detected) {
	PS3.setLedOn(LED3);
	isLED3On = true;
}
else {
	if (isLED3On) { PS3.setLedOff(LED3); }
	isLED3On = false;
}@

Is there anyway to get a constant stream of “1” or “2” printing (depending on if I have 1 or 2 color codes in sight) or not?

#2

Hello Josh,
Pixy will stream the detected blocks until it has no more blocks to stream for that particular frame. What you are seeing with the 0’s is Pixy indicating that there is no more new data for that frame. A simple way around this is to sleep for 20ms (or do some other processing), which is a frame period, and you will be guaranteed that the next call to getBlocks will return new data (because old data is always tossed). Sorry about that-- this is a limitation that needs to be addressed in the API.

Edward