<< return to Pixycam.com

cam_getFrame via USB question

Pixy Software
#21

John,

I implemented the start and stop commands as you suggested and it works … sort-of. It worked twice and then the program hung … I did not have a chance to dig into thus further so cannot tell if the problem is in what I’ve done or in the libpixyusb library … I will do some more digging when I have some time.

I did manage to get this working instead by doing the following:

while(True)
…
pixy_close()

…
pixy_init()
pixy_command(“cmd_getFrame”, …

This essentially accomplishes the same thing you were suggesting, but I assume my solution is very inefficient. For now it works until I can figure out what is going on with the ‘stop’ … ‘start’ sequence.

I did have to fix an issue with libpixyusb to be able to init/close the pixy connection multiple times. The variable ‘interpreter’ in pixy.cpp is global … meaning that it is not destroyed until the program exits. This is a problem as this means that the underlying objects (like the USB connection) are not properly re-initialized on a close() and this means that the next init() call fails. I resolved this by making ‘interpreter’ a pointer and explicitly creating it in the init() function and explicitly deleting it in the close() function … I am now able to init()/close() the pixy connection as many times as I want.

I am wondering if there is a similar problem with the ‘start’ / ‘stop’ sequence? (When pixy_command(“stop”, … is called the thread sitting on this connection spits out error messages until “start” is called.)

I have now successfully compiled and run this python code on a Mac laptop and an RPi … the Pi refresh is slow but the Python code is very inefficient right now … all of the image setup is being done in interpreted python code.

Chris

PS - I committed all of these changes to github.

#22

Hi,
The “start” command didn’t seem to be valid for me. I believe it should be “run” instead, which is working great for me. I can grab a frame and then continue to get blocks. Note that I’m using FW version 1.0.2.

Thanks,
Shari

#23

Have you been able to get any of the larger resolutions to work? I’m still having issues. I get a return_value of 0 but a response of -2.

For 1280x800 I use a mode of 0x00
and for 680x400 I am using 0x11

(320x200 work fine with mode of 0x21).

Thanks,
Shari

#24

I am also having this same problem. I have only been able to get 320x200 to work … I also get a ‘-2’ return code for the other frame sizes. I am thinking there is more to switching modes than just setting the mode in the cam_getFrame call? John, maybe you have some insight into this?

I am hoping that the ‘run’ command solves my ‘start’ / ‘stop’ issue … I am using the most recent firmware version so I do not know if that will make a difference.

I have spent all of my time since getting this pixy camera working on the python bindings and I have not got a clue as to the significance of the frames being returned … what are they for or can you point me to something that explains them?

Thanks,

Chris

#25

Hi,
Another clue to the larger size issue is that I get libusb_bulk_read -7 error codes with the larger sizes.

Chris what do you mean by “frames being returned”.

Take care,
Shari

#26

Hi Shari,

The “stop” / “run” sequence also works for me … whereas “stop” / “start” only worked a few times before hanging … not sure what that is about.

I get the following warning dumped to stdout when using “stop” / “run”:
libusb_bulk_read -7

I am ignoring this warning as it seems to have no impact on image updates.

I meant to ask about the blocks returned (not the frames returned) in my last post. What is the significance of the array of blocks returned by pixy_get_blocks()? I am guessing this is pretty obvious but I have been fixated on getting the python wrapper working.

I have not made any progress on image size yet, but am trying to get my head wrapped around the full set of interpreter commands that can be sent to the pixy and then an understanding of what all these commands do. John is there any documentation on the interpreter commands that can go to the pixy?

Chris

#27

Hi Chris,
Looks like we are at the same place then. Hopefully John has some insight into the image sizes. I’ll continue trying to debug as well.

I’ve been using the pixy_get_blocks command - I only use the TYPE_NORMAL blocks. These are the blocks that are detected for the different signatures (depending on how you’ve trained your pixy). As seen in the hello_pixy code you get the signature, width, height, x and y of the block. So for example if you’ve trained to detect red objects on signature 1 you will get blocks for all of the red objects that are detected. Is this what you were asking? Hope it helps.

Thanks,
Shari

#28

Hi,
I think I see the problem. In cam_getFrame it says
if (xWidth*yWidth>memSize)
return -2;

memsize is set to SRAM1_SIZE-len where SRAM1_SIZE is 0x12000 (or 73,728). 640x400 = 256,000 which is too big. 320x200 = 64,000 which fits.

John is there any way to solve this? Doesn’t seem like these larger sizes are going to work. The largest SRAM I see is 0x20000 (131,072) which still isn’t big enough for 640x400.

Thanks,
Shari

#29

If I understand the file setup correctly the code generating this ‘-2’ return code is not included in libpixyusb (the client-side library) … implying that these files are compiled and installed on the Pixy camera itself (making up the ‘server’ side of the API)?
So this is a hard limit on the camera and it is not capable of retuning these larger sizes (or can it be recompiled)?
Having said all of this the pixymon app displays larger images … or is the displayed image being scaled?

So many questions,

Chris

#30

Hi guys,

Pixy has 264K bytes of memory in various banks. We use the 128K bank for code, because it’s 0 wait-state (fast) (flash is 2 or 3 wait-state) We use a 72K bank for frame-store/lut’s etc. That’s enough for a 320x200 frame, but not bigger. So how does Pixy process an entire frame (640x400)? It uses a pixel pipeline – it processes pixels as they come in. Pixy is actually able to identify objects at the top of the frame before the entire frame has been sent to the onboard processor. It’s “raster chasing” for those who might be a little older.

Pixy is meant to be used as a sensor, not so much a camera.

Grabbing frames from Pixy is possible, but I’m wondering what you guys are trying to do— can you describe your application? It might help us figure out the best way to support y’all.

#31

Hi,
Thanks for the detailed explanation Rich. In my case I was just using the larger sizes because I thought they were implemented. I’m fine with just the small size for my application.

Thanks,
Shari

#32

Hi Rich,

Right now I am just playing around with the Pixy … what I am trying to do as get a feel for the set of scripted commands that the pixy supports over USB.

My ultimate intention is to use it as a tracking sensor in an internet of things project that I am working on. This means that in addition to (hopefully) tracking an object I want to be able to upload images of what is being tracked … which I can now do at 320x200. From your explanation I am guessing that the Pixy downloads large images (> 320x200) to the Pixymon app via usb … is there a specific command (like cam_getFrame) or sequence of commands to do this, or is it more complicated than that?

My other question … is there any kind of document detailing the available commands that can be sent over USB to the Pixy?

Again, thanks for the detailed response,

Chris

#33

The higher resolution modes are there and ready to use-- but the memory size will limit how much of the frame you can grab at a time. So— you can grab a 72K chunk of an 1280x800 frame instead of a 64K full frame at 320x200 (if that makes sense.) so you can do “region of interest” processing in this way.

Type in “help cam_getFrame” into the Pixymon command window to get an idea of which args to use.

Again, grabbing raw pixels and sending them somewhere else to be processed isn’t Pixy’s strong suit.

#34

Here’s a working example, intended for the users who reach this post via google.

uint8_t* videodata;
int32_t response;
int32_t fourccc;
int8_t renderflags;
uint16_t xwidth;
uint16_t ywidth;
uint32_t size;
int return_value = pixy_command("cam_getFrame", // String id for remote procedure
       INT8(0x21), // mode
       INT16(0), // xoffset
       INT16(0), // yoffset
       INT16(320), // width
       INT16(200), // height
       END_OUT_ARGS, // separator
       &response, // pointer to mem address for return value
       &fourccc,
       &renderflags,
       &xwidth,
       &ywidth,
       &size,
       &videodata, // pointer to mem address for returned frame
       END_IN_ARGS);

if(return_value==0) {
   return_value = renderBA81(renderflags,xwidth,ywidth,size,videodata);
}

See: