Smaller blocks often not Returned

Added by Dave Coleman about 1 month ago

I've built a line following (blob following) application running on Arduino and using Pixy via I2C. I divide the Pixy field of view into a 3x3 grid and assign blocks found to one of the quadrants (high, medium, low and left, center, right). This is used for speed control and steering.

Viewing the scene via PixyMon, blobs in the distance, midrange, and near are identified and appear with their signature. Leaving the camera in the same position, the Arduino however, 9 times out of 10 (approx) reports only the large area nearby blob. Only occasionally it includes in its set of blocks the far and midrange. I know it returns the blocks in sequence by signature, then block size. But it baffles me why the smaller blocks most of the time are omitted. Obviously the smaller (farther away) blobs are of interest to me.

Attached are a picture of the Pixymon view and of a log from the Arduino. If necessary I can supply some code. But perhaps there is some inherent quirk that causes this. Please advise.

IMG_20170906_081226.jpg - Arduino log of Pixy blocks. (2.6 MB)

IMG_20170906_080706.jpg - What Pixymon sees. (2.4 MB)


Replies (6)

RE: Smaller blocks often not Returned - Added by Jesse French about 1 month ago

Hi Dave! Sounds like a smart approach. Off-hand, I'd guess this is a bus speed limitation. Try increasing the baudrate in PixyMon and see if this solves your problem.

Is there a reason you're not using SPI via the included Arduino cable? It's typically faster than I2C.

Cheers,
Jesse

RE: Smaller blocks often not Returned - Added by Dave Coleman 29 days ago

Back from Travels... The reason I went with SPI is from a previous use of the Pixy where I was logging to an SD card using SPI and I wanted to avoid tangles there. I could change to SPI now if that indeed is the problem...

But doesn't it seem like if I was not sending data fast enough across the bus that the Read would still get the entire frame (all blocks), but that the buffer would overflow on the Pixy side? Is it possible the Arduino Mega isn't reading fast enough and that by the time it gets to the next read the buffer has been overwritten or some variation on that. I've observed that the first two reads get all the blocks, after which only the largest block is present for most of the reads.

For your amusement, the problem was avoided partly by putting a popsicle stick in front of the camera to block the near center. Another approach that seemed to work was to shine a headlight on the near center and wash out the color. I'd still like to get all the blocks in the frame.

RE: Smaller blocks often not Returned - Added by Jesse French 29 days ago

Hey Dave,

yes, I suspect that's what's happening - basically a buffer overflow on the Pixy side. When this happens (i.e. when serial speed is not fast enough to get all blocks before the next frame) the unsent object blocks from the previous frame are tossed and the new object blocks from the new frame are sent instead. This way, the most recent information is prioritized and always sent. And since the objects are sorted by size, the larger the object, the more priority it gets also.

Have you tried increasing the baudrate in PixyMon? Let me know if this (or switching to SPI) solves the issue.

Thanks,
Jesse

RE: Smaller blocks often not Returned - Added by Dave Coleman 29 days ago

Just tried speeding up I2C from "slow" to "fast" by modifying the Arduino Wire library twi.h to specify #define TWI_FREQ 400000L instead of 100000L.

Worked like a champ! I got two blocks most of the time, improving performance and line tracking very nicely.

No more popsicle sticks. Thanks very much Jesse.

Dave

RE: Smaller blocks often not Returned - Added by Jesse French 29 days ago

Hooray! Glad it worked :D let us know if you need anything else!

Best,
Jesse

RE: Smaller blocks often not Returned - Added by Dave Coleman 29 days ago

Just thought I'd share this. Flushed with success, I upped the speed even more using TWI_FREQ 800000L. Now I get all three blocks! Yay! I think I'll stop at that.

Dave

(1-6/6)