<< return to Pixycam.com

decoding pixy serial protocol over UART

Pixy Software
#1

as far as i can work out, the attachment shows my interpretation of how to decode the pixy protocol, is it correct?

I would recommend alternate versions of the firmware with an improved protocol.
some ideas could be:
signify start of frame
number of objects in packet (taking account into the number that can be sent using the set baud rate)
repeat n times
_checksum
_object ID
_x
_y
_width
_height

or alternately, more like the current protocol, if the frame sync and object sync values were changed so they did not have identical values
signify start of frame
repeat n times
_signify start of object
_checksum
_object ID
_x
_y
_width
_height
signify end of frame

I personally think it is not the best protocol design at the moment because it is indistinguishable between frame and object sync, and I must read it to know, that mans I may be checking for a frame sync and accidentally get checksum data in there (because it was an object sync previously) which then means I need to indicate to the packet decoder if i should pass the checksum data to it or do a read for it, which is messy. It is also messy determining if it is the last object in the frame as the only way to do this is to count the (same value) syncs which means I have already read them just to determine that, and thus can not jump directly back to start unless dropping frames in the decode is acceptable.

Actually i seem to have gotten the no detections part wrong in the attached diagram, it is not documented anywhere. but it would seem it outputs 2 syncs, followed by checksum, signature, x, and then the rest of the values are 0, and all following frames are just a bunch of 0s with no syncs, which ads more handling complexity, A suggestion might be:
signify start of frame
_signify start of object
_checksum
_object ID=0
_x=0
_y=0
_width=0
_height=0
signify end of frame

#2

Thanks for the feedback, Avi. We’re always looking to improve on Pixy, so we’ll keep your suggestions in mind.

Scott

#3

update, now the no detection 0s come after the full last packet, and to distinguish it from null padding i count if there are 33 or more (if there is a better way let me know)

#4

I am using SPI (between Pixy and PIC2550) and seemingly decoding the protocol correctly. I accurately get checksum, signature number, x, y, width, height. I see the tracked signature in PixyMon, and its position and shape match the data I get. My problem is that as soon as there is more than one signature visible I only get data for whatever the lowest number signature is. I’ve captured the stream and examined it byte by byte, and I have also written my monitor program in such a way that each signature’s data has its own display area so there is no overlapping, but still only one tracked object is received if there are more than one in the frame.

After 2 sync words I always get 6 words and they always accurately depict what I see, so I don’t think I am missing any data. Are you having any luck with data from multiple signatures in the frame at one time? Is there some timing convention for how quickly I should poll the Pixy? I’ve tried delays but they’re not making any difference. Thanks.

#5

yes i get multiple objects per frame.
2 syncs, 6 bytes, followed by n-1 lots of 1 sync, 6 bytes. then zero pad (or something, undocumented).
0 continually with no syncs if no detections.