Pixy: Reading out I²C Data on another platform than Arduino?

[Diphthong]

Hello everyone,

first of all I want to say that the Pixycam is a really, really cool device and is going to have a big community!
My Pixy arrived two days ago and after I configured tested everyhing via Pixymon, I want to read out the Pixy Data via I²C. I configured it in Pixymon to the modus ‘1’ (I²C). But now I have no idea how to implement the I²C communication (Peter Fleury Library on AVR ATmega2560) because I can’t find absolutely NO information about that (how to start the communication, when does the Pixy answers with an Ack or an Nak, which registers to access etc. and I am really not planning to reverse-engineer the Arduino Library.

Can you help me? Where do I find the relevant information?

Do I have to read out every single word like this:

uint16_t pixy_getWord(uint8_t adr)
{
	uint16_t word = 0;

	i2c_start(adr);

	word += (uint16_t)(i2c_readAck()<<8);
	word += i2c_readNak();

	i2c_stop();

	return word;
}

[...]

uint16_t var = pixy_getWord(0x54);

and proceed with this somehow like in the “Pixy Serial Protocol” wiki article?

This only returns me 0x5454, two times the address of the pixy…

Thanks and
regards
Jan

EDIT:
Note; The i2c_start returned until now ‘1’ (failed to access device), if I add a “<<1” (shift the address one bit to the left) I get a ‘0’ (device accessible). I observed the same thing on a MLX90614 IR Temperature Sensor btw… Now the word I get back is “A8A8”.

[srobins1]

Hi Jan,

Glad you’re enjoying Pixy! Yes, you can follow the guide in the “Pixy Serial Protocol”:http://cmucam.org/projects/cmucam5/wiki/Pixy_Serial_Protocol#The-serial-protocol page. This should tell you all you need to know for the message format. I’ll get back to you with more I2C details.

Scott

[srobins1]

Hi Jan,

To follow up, you need to ack/nack each byte (if the library doesn’t do it for you), and I’m not sure what you mean when you ask about the registers, that will be dependent on the hardware you’re using.

If you suspect something is wrong, you can always test out the I2C communication with an Arduino since we know that works.

Scott

[Diphthong]

Hello Scott,
thanks for your response!

Alright, This works to me:

uint16_t pixy_getWord(uint8_t adr)
{
	uint16_t word = 0;

	i2c_start(adr + I2C_READ);
	word += i2c_readAck(); //msb
	word += (uint16_t)(i2c_readNak()<<8); //lsb

	i2c_stop();

	return word;
}

But I don’t really understand how the protocol and especially the Arduino Pixy Library (that, unfortunately, has absolutely no ducumentation and comments…) works.

The arduino example program works well, but my implementation does not. I looked at the raw words from the pixy and printed them into the arduino serial monitor (and, with the same result, on my other, not working implementation). This is the result. The arduino program and PixyMon return me four detected blocks, but how is that possible, when there is always two times the “AA55” word? My library sees this as a new frame, just as the documentation says;

Hex output:

1D4 4 BD 5C 6A 4D *AA55 AA55* 1D6 4 BD 5C 6C 4D *AA55* 
142 4 63 50 37 54 *AA55 AA55* 1D6 4 BD 5D 6A 4E AA55 
AA55 1D4 4 BD 5D 6A 4C *AA55 AA55* 1D4 4 BD 5C 6A 4D 
AA55 AA55 1D5 4 BD 5D 6A 4D *AA55 AA55* 1D4 4 BC 5C 6B 
4D *AA55 AA55* 1D6 4 BC 5D 6B 4E *AA55 AA55* 1D4 4 BC 5C 
6B 4D *AA55 AA55* 1D6 4 BD 5D 6A 4E *AA55 AA55* 1D5 4 BC 
5D 6B 4D *AA55 AA55* 1D5 4 BC 5D 6B 4D *AA55 AA55* 1D6 4 
BC 5D 6B 4E *AA55 AA55* 1D7 4 BD 5D 6B 4E *AA55 AA55* 1D4 
4 BC 5D 6B 4C *AA55 AA55* 1D6 4 BD 5C 6C 4D *AA55 AA55* //and so on... 
1D6 4 BD 5C 6C 4D AA55 AA55 1D4 4 BC 5C 6B 4D AA55 
AA55 1D8 4 BD 5D 6C 4E AA55 AA55 1D4 4 BD 5C 6A 4D 
AA55 AA55 1D4 4 BD 5D 6A 4C AA55 AA55 1D4 4 BD 5D 6A 
4C AA55 AA55 1D5 4 BD 5C 6B 4D AA55 AA55 1D5 4 BD 5C 
6B 4D AA55 AA55 1D5 4 BD 5C 6B 4D AA55 AA55 1D6 4 BC 
5D 6B 4E AA55 AA55 1D4 4 BD 5D 6A 4C AA55 AA55 1D6 4

Shouldn’t it be like this for four objects?

AA55
x x x x x x AA55
x x x x x x AA55
AA55 //Start of new frame?
x x x x x x AA55
x x x x x x AA55
x x x x x x AA55
x x x x x x AA55
AA55
x x x x x x AA55
x x x x x x AA55
x x x x x x AA55
x x x x x x AA55
 etc.

What do I understand wrong?

Thanks and regards
Jan

EDIT:

Ok, this is really strange. It seems like this has something to do with the timing. I think there may be a bug in the PixyCam Firmware!?

If I connect the cam with an Arduino and upload the I2C example, the amount of the detected outputs shrinks from 5 (there are 5 LED dots to track) to 1 with the following void loop:

void loop() 
{ 
  int j;
  uint16_t blocks;
  char buf[32]; 
  
  blocks = pixy.getBlocks();
  
  if (blocks)
  {
    sprintf(buf, "Detected %d:\n", blocks);
    Serial.print(buf);
    for (j=0; j<blocks; j++)
    {
      sprintf(buf, "  block %d: ", j);
      Serial.print(buf); 
      pixy.blocks[j].print();
    }
    
    for(uint8_t i = 0; i < blocks; i++) //Output the amount of detected objects via the led
    {
      digitalWrite(13, HIGH); delay(50);
      digitalWrite(13, LOW); delay(200);
    }
  }
  
  delay(1000);
}

Output:

Detected 5:
  block 0: sig: 4 x: 98 y: 70 width: 44 height: 69
  block 1: sig: 4 x: 163 y: 85 width: 45 height: 68
  block 2: sig: 4 x: 218 y: 90 width: 44 height: 66
  block 3: sig: 4 x: 35 y: 60 width: 31 height: 64
  block 4: sig: 4 x: 7 y: 55 width: 12 height: 55
Detected 5:
  block 0: sig: 4 x: 98 y: 70 width: 44 height: 69
  block 1: sig: 4 x: 163 y: 85 width: 45 height: 68
  block 2: sig: 4 x: 218 y: 89 width: 43 height: 67
  block 3: sig: 4 x: 35 y: 60 width: 31 height: 66
  block 4: sig: 4 x: 7 y: 55 width: 12 height: 55
Detected 4:
  block 0: sig: 4 x: 98 y: 70 width: 44 height: 70
  block 1: sig: 4 x: 163 y: 85 width: 45 height: 67
  block 2: sig: 4 x: 218 y: 90 width: 44 height: 66
  block 3: sig: 4 x: 35 y: 60 width: 31 height: 64
Detected 1:
  block 0: sig: 4 x: 98 y: 70 width: 44 height: 69
Detected 1:
  block 0: sig: 4 x: 97 y: 70 width: 43 height: 70
Detected 1:
  block 0: sig: 4 x: 98 y: 70 width: 44 height: 69
Detected 1:
  block 0: sig: 4 x: 98 y: 70 width: 44 height: 69
Detected 1:
  block 0: sig: 4 x: 98 y: 70 width: 44 height: 69
Detected 1:
  block 0: sig: 4 x: 98 y: 70 width: 44 height: 69
Detected 1:
  block 0: sig: 4 x: 97 y: 70 width: 43 height: 68
Detected 1:
  block 0: sig: 4 x: 98 y: 70 width: 44 height: 69
Detected 1:
  block 0: sig: 4 x: 98 y: 70 width: 44 height: 69

What do you say?

[srobins1]

Hi Jan,

I’m guessing there could be a problem due to these delays in your code:

digitalWrite(13, HIGH); delay(50);
digitalWrite(13, LOW); delay(200);

You’re delaying for a quarter of a second, which is the equivalent of 12.5 frames. I’m wondering if that creates a problem with the communication. Try taking that part out and seeing if the behavior improves.

Scott

[Diphthong]

Hi Scott,

yes, this is the problem, but I put the delays on purpose into the program to test the behaviour of the Cam when there is not enough time to poll the data…

If the cam reacts like this (it’s really bad… Why doesn’t it at least completes the just started frame and instead loses data?) I will have to use the UART…

Do I understand right that the camera just sends data onto the uart when there are Block? I don’t have to start the comunication somehow? Because I configured it in PixyMon and the camera does not send anything (confirmed on oscilloscope).

Greetings
Jan