<< return to Pixycam.com

Performance question...

Pixy Software
#1

I have a question about expectations around how quickly i get a detected block from when it happens live. If I have a nice bright red ball sitting still and Pixy2 is locked on it, if the ball moves it appears to be approx 100ms before i get the new block via usb. You don’t notice the lag using PixyMon because the frames are displayed around 120ms to 150ms after live as well, so of course the drawn detection rect is flawlessly with the ball.

Question 1 is if the 100ms (-ish) delay i’m seeing is expected or not. Then depending on the answer to that, my second question is if there are potential firmware changes that could be made (if i’m willing to forgo other features or something since performance virtually always involves tradeoffs).

Thanks!

#2

Hi stallent,

could you say more about the interface you’re using? Is it libpixyusb2?

This is a bit beyond my knowledge, maybe @edge can chime in here…

Thanks,
Jesse

#3

So i’ve tried several ways. Initial test was simply using PixyMon on OS X. Then i also tried on an Arduino Uno and then last but not least, also using a Raspberry Pi 3 B+ with libpixyusb2. I only tried the get_blocks_cpp_demo on the Pi, though. Not sure if there is a better/faster to way to test. FWIW, all three seemed to approximately exhibit that same lag compared to live.

Thanks!

#4

Hi Stephen,
You are talking about 100ms latency with the USB interface. It should be closer to 40-50ms, but I’m wondering how you measured this. Can you describe?

PixyMon will slow Pixy down by at least 1/2 if you are displaying video and blocks.

Edward

#5

Ultimately I’m needing to get detected rects into an OS X app but haven’t been able to get libpixyusb2 compiling for Mac yet, so first try was via an Arduino Uno. The Pixy2 would be focused at my Mac’s screen. Press button in my app to turn a box red, red gets detected and sent via serial port back to mac app. Yes, i know that adds the latency of the arduino->osx but only sending back mid_x and mid_y at a pretty high baud so hopefully thats not adding much. I wondered if the slow Uno was part of problem so tried a Due but seems to be compatibility issues as the pixy arduino lib wouldn’t build for Due.

Next, i tried a Rasperry Pi. Don’t laugh at my super unscientific method here… Basically used a slow mo camera running at 240fps to capture when the objected moved in real life and when the console wrote out the updated rects. Once captured, you can just count frames between motion and console output.

If there is a better/faster way to get the detections into an OS X app i’d be happy to take a diff approach. If i’m able to get closer to the 50ms you are saying should be what i see then the viability of this solution goes waaaayyy up.

Thanks!

#6

Hi Stephen,
Thanks for the heads-up — we’ll need to test the Due with the latest Arduino library and fix any issues.

If your goal is to get info into your Mac as fast as possible, getting libpixyusb2 working on Mac would be your best bet. We don’t target Mac for libpixyusb, but it shouldn’t be difficult to get it working.

What errors are you getting compiling libpixyusb2 on MacOS? I’m guessing it has something to do with libusb installation and finding the libusb header.

This page:

https://docs.pixycam.com/wiki/doku.php?id=wiki:v2:building_pixymon

describes getting libusb onto your Mac, namely
.
sudo port install libusb

Don’t bother installing qt5…

After you get libusb installed, you may still need to contend with the header path… let me know how it goes.

Edward

#7

alright, yeah, after fighting a few headers i was able to get libpixy2.a built. Of course none of the demos want to compile for pathing issues, as well. Rabbit hole of source mods! I’ll probably just try porting the get_blocks_cpp code into my OSX app and link libpixy2.a in. I’ll let you know how it goes.

#8

HI Stephen,
Glad you got it compiling – let us know what kind of mods you had to make :slight_smile:

I would’ve expected the examples to just compile once you got libpixyusb2 built – what kind of error(s) are you getting?

Edward

#9

to get libpixyusb2 to build i had to add conditional check so libpixyusb.h used #include <stdlib.h> instead of #include <malloc.h>. Also had to modify the makefile to update the path for libusb (was in different spot on my system after installing via macports) as well as add an include /common/inc for something. I can’t remember off the top of my head what was in there that wasn’t found. Also had to remove the -o from the ar command. Once i did all that it would build.

In attempting to build the get_blocks_cpp_demo its failing because of strncpy used in TPixy2.h Haven’t worked around that yet (lack of time).

Attempted to link libpixyusb2 directly into my OS X application but its only 32bit and Xcode does everything in its power nowadays to not allow 32bit only so with no x86_64 segment Xcode just whines and cries and then falls over.

I’m sure the above things can be worked around but a bit beyond my skills to figure out easily.

#10

Hi Stephen,
Thanks for the information. We’ll look into massaging the code to make it more of a common denominator.

I share your frustration regarding OSX and 32-bit deprecation. It’s thrown us for a loop as well.

Edward