<< return to Pixycam.com

Timestamp or unique ID in each block of PIXY object being recognized and/or ability to trigger acquision

Pixy Software
#1

First of all, Pixy is a clever idea and feel it fits my needs very well. I look forward to face detection later but as of now I am on the 1.0.2 fairly new firmware so am rather current.

My Pixy is running over USB using a modified version of your libpixymon demo program.
This version runs as your code runs but grabs my own System V semaphore then dumps the blocks to my own shared memory segment.
I then have my own code in a ROS (Robot Operating System) ‘node’ (process) that acquires the lock and reads the samples.

This all works well BUT I get multiple frame of data each time and have no reference to sort out what I know about already VS new sets of blocks.

What I wish to do is acquire a new run of samples far slower than you run like every 100ms or maybe 50ms and be able to correlate the blocks I read to know what time they are from. The ‘correct’ way to do all this is I guess to integrate the USB demo code into my ROS node (process) and I realize my approach is a bit of a ‘hack’ with the shared memory.

BUT I wondered why there seems to be no pixy-centric unique 32 bit number or something that indicates what sample frame the set of blocks comes from. It would be acceptable for this to be an unsigned value that rolls back to 1 as with 32 bits (or even 16 bits) that is a HUGE time between rollovers and logic to determine a rollover happened is then rather easy modulo math. If such an index existed in your ‘block’ structure in the Pixy Demo OR I could put it in myself if I knew how to get some sort of frame number from PIXY.

If I had such an index that said ‘This set of blocks is from frame 1234’ then later as I read again I could see ‘this set of blocks comes from frame 1280’ and have a way to avoid reading duplicate blocks which it seems to do at this time.

Any thoughts on this OR a way to ‘trigger’ pixy to do another run myself so then I could KNOW for sure what time the frame was analyzed. This ability would have to be over USB for my system.

The issue is total free-run without a timestamp or index makes it non trivial to filter out duplicate packets from set of blocks to next set of blocks.

I see deep down that the Blobs class increments and thus maintains in terms of bumping on each blob the m_blobReadIndex and m_ccBlobReadIndex and then there seems to be a microsecond timestamp also way down at the blobs.cpp level of acquisition although that is a bit more illusive I think it may get stuffed into the data returned from Blobs::getBlocks() and Blobs::getCCBlocks but that starts to get old-skewl fortran array uint16 data stuff and I gave up so far at that point but may revisit if no reply to this query. Either of these (index or usecClock) if they made there way back up to the higher level ‘Block’ structures would do the trick and I feel is a fairly important thing for Pixy to support to be a ‘pro’ device and not a toy.

I’m out of gas tonight in more reverse engineering but I bet you guys know how the PixyInterpreter thread that is instantiated goes about translating Blobs to Blocks for higher level code consumption. This would be a nice addition (please).

Thanks for listening.
Mark Johnston

#2

Hi Mark,

Thanks for the ideas. I’ll bring up the idea and see what kind of response it gets. My initial thought is this problem isn’t too common, so I’m not sure its worth slowing down the transfer rate by adding more data. But its still worth looking in to and maybe there are more people wanting this than I realize.

Thanks.

Scott

#3

I complicated the real need by getting into specifics of what I have today and suggesting a couple ways to solve the problem. Let me back up and simplify the question.

The issue is not so much an exact timestamp of the frame or a frame index in each block that is returned although that would be nice it is maybe overkill for what I need (and I suspect everyone needs).

What is important is that on any given fetch of blocks that I know that all of the blocks are from the SAME frame that was analyzed or else it is close to impossible to ‘see’ without double vision. If the code in the hello_pixy cpp program that is in pixyinterpreter.cpp that calls add_color_code_blocks() can be assured to me that the resultant translated blobs from that one call are all unique within the very same frame that was analyzed then I think I can make up my own scheme.

I need some way to be assured that the blocks I get from calls to translate blobs to blocks are all from the very same frame and in no way may be duplicating the same object because of the data is from 2 or more frames.

Is that how it works at the call to add_color_code_blocks()? Because the very same block between two separate frames can vary a little bit so it is impossible without complex recognition software ABOVE pixy to weed out duplicates.

I hope the need is clearer in this message.

The incrementing frame number or the microsecond clock ideas were just suggestions on ways that higher level code could sort out and group all the blocks with the same index as being from one unique frame. That was only a thought to help solve the issue. Don’t worry about all that shared memory talk and so on.

Thanks,
mark