hello,
I just received my Pixy and have 1 crucial question about the Sketch hello_world:
which is the order of appearance of pixy blocks ?
the most significant sorting level is probably the color signature.
but:
what about color signatures mixed with color codes (mode “enabled”)? which come first?
which is the next sorting level: x? y? width? height? area-size (width*height)?
Hello,
The detected blocks are sorted by signature with the lower signatures coming first, that’s correct. Within each signature, the blocks are sorted by area (width * height). The color coded blocks come last, and their order isn’t sorted in any particular way.
Hope this helps!
Edward
thank you for your reply!
so given I have 3 single colors and 4 color codes:
But if now the blocks by 4 different color codes all come randomly unsorted,
any answers?
Could you say more about what you’re trying to do with Pixy?
You could write some code to determine which blocks are biggest within a moving window of time…
Hope this helps,
Jesse
I want to put several different and perhaps arbitrarily or randomly identical color code “traffic signs” in the house and in the garden.
perhaps a series of 1-3-4 color code leads from the living room to the charging station,
some 1-3-5 lead from living room to the garden
some 1-3-6 lead from living room to the kitchen
endpoints are labelled by specific 2-color-codes. e.g. 2-3, 2-4, 2-5, …
so the mobile robot has to distinguish which one of identical color codes is the biggest (closest) and which is the next smaller, and which is the smallest, most distant, coming after that.
Following the series from biggest (closest) to smallest (most distant) will lead the way from A to B.
Hello,
There seem to be some confusion about when the blocks are reported. All blocks (regular and color-coded) are reported on a frame-by-frame basis. Blocks will not be reported as they are detected (for example, one by one), but they will be reported for the complete frame. This addresses your concern about knowing when a certain color code is present to the end (of the frame).
Hope this helps.
Edward
sorry, your explanation is totally confusing, so again:
the single-color “blocks” are reportet first (e.g., like in the hello_world.ino sketch),
signature 1 by descending size
signature 2 by descending size
and so on.
@ sprintf(buf, “Detected %d:\n”, blocks);
Serial.print(buf);
for (j=0; j<blocks; j++)
{
sprintf(buf, " block %d: ", j);
Serial.print(buf);
signature = pixy.blocks[j].signature; //get object’s signature
int x = pixy.blocks[j].x; //get x position
int y = pixy.blocks[j].y; //get y position
int width = pixy.blocks[j].width; //get width
int height = pixy.blocks[j].height; //get height
int angle = pixy.blocks[j].angle; //get height
pixy.blocks[j].print();
}
@
now given I have defined triple-color codes
1-3-4 (e.g., 3 blobs detected )
1-3-5 (e.g., 3 blobs detected )
1-3-6 (e.g., 3 blobs detected )
plus double-color codes
2-3 (e.g., 3 blobs detected )
2-4 (e.g., 3 blobs detected )
2-5 (e.g., 3 blobs detected )
in which order will they be reported in the program snippet above, both with respect to their color codes and to their sizes?
I think what Edward is trying to say is, using the order in which blocks are reported is not a reliable method for determining which objects are largest. You should rely on the width & height information that Pixy provides, and write a function that (for example) stores the largest value for a particular time window, and then compares incoming object sizes to that, to determine which is largest.
Hope this helps!
Jesse
it’s not about what I rely on - my question is the order of appearance by Pixy Lib design.
the single-color blobs all come one after the other, smallest signature number first, and then all by the same color by descending area size (== biggest area size first).
So again, which is the ultimate answer about how multiple-color-signature blobs will appear by design, for the following arbitrary setup specifically?
all signature 1 blobs by descending size
all signature 2 blobs by descending size
and so on.
@ sprintf(buf, “Detected %d:\n”, blocks);
Serial.print(buf);
for (j=0; j<blocks; j++) {
sprintf(buf, " block %d: ", j);
Serial.print(buf);
signature = pixy.blocks[j].signature; //get object’s signature
int x = pixy.blocks[j].x; //get x position
int y = pixy.blocks[j].y; //get y position
int width = pixy.blocks[j].width; //get width
int height = pixy.blocks[j].height; //get height
int angle = pixy.blocks[j].angle; //get height
pixy.blocks[j].print();
}
@
now given I have defined triple-color codes
1-3-4 (e.g., 3 blobs detected )
1-3-5 (e.g., 3 blobs detected )
1-3-6 (e.g., 3 blobs detected )
plus double-color codes
2-3 (e.g., 3 blobs detected )
2-4 (e.g., 3 blobs detected )
2-5 (e.g., 3 blobs detected )
in which order will they be reported in the program snippet above BY LIB DESIGN, both with respect to their color codes and to their sizes?
Edward already answered your question above.
“The detected blocks are sorted by signature with the lower signatures coming first, that’s correct. Within each signature, the blocks are sorted by area (width * height). The color coded blocks come last, and their order isn’t sorted in any particular way.”
Hope this helps,
Jesse
if that means that the multi-color-blobs are not even sorted by signature codes then I’m lost in the tube world:
I have no idea how to sort all the perhaps dozens of different random blobs of random set size and random signature subset sizes and different area sizes by my own, in order make them appear just like single-color blobs.
Hehe, I giggled at “lost in the tube world.”
Sorry for the confusion. Color codes are more complicated. They do have an ID though, which you should be able to identify and sort them by.
Here’s more info: http://cmucam.org/projects/cmucam5/wiki/Using_Color_Codes#How-color-codes-are-reported
And more info on the general serial protocol: https://docs.pixycam.com/wiki/doku.php?id=wiki:v1:Porting_Guide#Object-block-format
It sounds like what you want is to write some code that will filter the color code blocks by ID, and then sort each ID by size. This shouldn’t be too hard to implement…assuming you have some experience coding.
Unfortunately I don’t have the expertise to provide code samples, so you are on your own as far as programming the actual thing goes. Sorry!
Best of luck,
Jesse
finally solved by a proprietary shellsort implementation, thank you!
Hooray!
French,
that’s a pretty pointless answer. Please keep at least a trace of brain activity in your posts.
Please don’t insult me, or anyone else posting here. Edward and myself run the customer support, and we’ve been working to answer your questions in good faith. Consider this a warning - I won’t give you a second one.
Thanks,
Jesse