CMUcam Pixy

port513

Anyone here that use CMUcam and Propeller?
I will use it for some navigation challenges we have at work and for some other things.

Duane Degn

Here are a couple threads discussing using the Pixy with the Propeller.

http://forums.parallax.com/discussion/155501/pixy-for-propeller

http://forums.parallax.com/discussion/155119/pixy-cmucam5-is-out-in-the-wild-now-on-journy-with-it-and-the-propeller

From my own experiments, I've found the Pixy needs a lot of light to work well. I haven't used the latest version of the firmware so it might work better than when I last tried using the Pixy.

port513

Thanks, missed that when I searched...

twm47099

In the first thread that Duane linked I did get SPI data transfer to work. However, since then the firmware for the Pixy has changed. The newer firmware made significant changes to the SPI data transfer protocol that Pixy uses.

In the older firmware, the Pixy always sent data without any handshaking. The receiving program just had to collect data as quickly as possible. The current version (not sure which firmware version made the change) requires that the receiving program send a 'sync' byte after every other byte received. I'm not sure how this affects data speed. A couple of nice things about the new firmware is that since it sends data as 16 bit bigendian words, it is easier to deal with in a C program. It should be easier to sync with words and not have to find the first byte and then flip the order into a variable.

I'm not sure if there were any changes made to the UART mode.

The newer firmware also allows the connected micro-controller to remotely set certain parameters such as brightness, which is a big advantage over the old firmware.

I'm still using my Pixy with the older firmware, so have not had a chance to try any of the newer features. In my use I want to collect data as quickly as possible, and I am concerned that having to send the sync byte every other byte will slow things too much.

I am using the Pixy with my ActivityBot to have the bot "chase" a color. The easiest, but most limiting data mode is the Pixy D/A mode that outputs a voltage based on the x or y position of the center of the largest color blob (largest usually equals closest). So it works best with only one defined color object. But there is no need to worry about finding sync words or the actual data transfer. Just use the ABot A/D functions in the Simple IDE libraries. It was a nice way to learn to use Pixy. Then when I wanted to be able to track more than one color, I used UART mode, but I found that speed limited to being able to use 3 defined colors (Pixy will usually detect multiple objects per color and restarts sending data from the beginning every 20 ms) .

Tom

port513

Why not SPI?
We should create a C/C++ library for Pixy

Electrodude

twm47099 wrote: »

A couple of nice things about the new firmware is that since it sends data as 16 bit bigendian words, it is easier to deal with in a C program. It should be easier to sync with words and not have to find the first byte and then flip the order into a variable.

Not to bring up the topic of endianness again, but you're surely doing something wrong if you find it easier to receive big endian data on a little endian processor. If you were doing it right (regardless of endianness), you wouldn't need any explicit flipping of bytes.

twm47099

Electrodude wrote: »

twm47099 wrote: »

A couple of nice things about the new firmware is that since it sends data as 16 bit bigendian words, it is easier to deal with in a C program. It should be easier to sync with words and not have to find the first byte and then flip the order into a variable.

Not to bring up the topic of endianness again, but you're surely doing something wrong if you find it easier to receive big endian data on a little endian processor. If you were doing it right (regardless of endianness), you wouldn't need any explicit flipping of bytes.

In C with the 16bit bigendian data transfer all I have to do is:

short x;                      // declare x to be a 16 bit int
...                              // do other stuff like initialize the spi 
x = getspi(pixy...);         // the command to get 16 bit spi data from the pixy 

With the earlier non-stop byte transfer (which for spi was also big endian), it was necessary to get a byte, determine if it was the high byte of the Pixy sync word. If not try again.
If it was the high byte, check the next byte to see if it was the low byte of the sync word. If not it was just a byte (high or low??) of a data word and you had to repeat the tests until the sync word was received. Once synced the program could just treat the next words as 16 bit data starting with the high byte and at a known point in the data block.

UART used smallendian. It was still necessary to find the sync word, except now the program had to check for the low byte first. Once the sync word was found, instead of doing a 16 bit getspi() it was necessary to do two 8 bit gets and build the 16 bit word. Not a big deal, but it is easier to just read a 16 bit variable after doing an sendspi(). However, I don't know the impact of having to send a byte (including function call overhead) on the number of data signatures that can be received before Pixy starts a new series.

When using the UART interface, once sync'd I was doing something like

x = get() | (get() << 8 );    // I used the C simpleide library fdserial commands not the ones I show here

Note getspi(), sendspi(), get() are not the actual commands; I'm not at my computer and I don't recall the actual function names and parameters I used.

Tom

twm47099

port513 wrote: »

Why not SPI?
We should create a C/C++ library for Pixy

If you are referring to the SPI functions in the SimpleTools library, I did try that and it did work, but I could only get 2 blocks of data (object position, color, etc ) per frame (collection of blocks before Pixy starts from the beginning again). I needed to get more blocks per frame. With a lot of help I wrote faster SPI C functions by importing the PASM from SPIASM.spin (from the PropTools library). With that code I was able to receive 14 blocks per frame. See:

forums.parallax.com/discussion/157441/can-spi-in-simple-libraries-be-speeded-up/p1

tom