<< return to Pixycam.com

Problems controlling brightness and getting block data with Arduino Mega

Pixy Software
#1

I’m writing a program that takes block width at each loop and sets a new brightness each time, with the goal of finding a range of acceptable brightnesses and setting a final optimal brightness. The brightness response in pixymon seems like it has a hysteresis built in, so I start low and go high, waiting nearly a second each time. The main idea here is that my block width is true-to-life when the brightness is set correctly, but grows to include the background when the brightness is set too high. I’m using the IR-lock, so my image is monochrome.

I’m sure that my program is adjusting the brightness, and my program is working reasonably well. It’s just that I can’t trust my block data, or perhaps that my brightness control is only working partially. As if I have a lever but the lever is rusty and there’s sand in the gears. The control sticks, and then I get a sudden checksum error and a herky-jerky response.

The problem that I’m having is that pixy.getBlocks() does not seem to refresh when I call it, or perhaps that it has some sort of memory associated with it that won’t clear.There usually seems to be no consistency in the behavior of the block data when I run the same program twice.

Adjusting the brightness programmatically via Arduino from 0-255 does not seem to have the same effect as it does in Pixymon. For example, a brightness of 25 in pixymon produces a clear block, but in my program no blocks are detected. Then again, I frequently get blocks detected when I’ve set the brightness to zero and waited many seconds. Setting the brightness very low never seems to result in the block disappearing as it should, though the block will usually grow to the screen size when I set the brightness very high (as expected).

In addition, block data will often return wildly innacurate numbers, such as width = -23456 or some such number. Sometimes, if I print the variable “blocks”, I get zero, but if I print the block data as it is done in the “Hello World” example at the same time, I get a block detected. I’ve tried at this for three solid days, but I cannot seem to be able to get to the bottom of it. I think there’s something wrong with how I’m calling getblocks() or something. I’m also getting a lot of randomly occurring checksum errors.

I’m attaching a sample of my code. Can anyone spot anything blatantly wrong? I’m using Arduino ICSP SPI for the data out port, and I have the latest versions of the library and pixymon. I’m coding in visual micro for visual studio, and my pixy is an IR-lock version, if that matters.

#2

UPDATE::

After four full days, I was finally able to get the Pixy to do what I want by repeatedly sending the brightness command and getBlocks() least 25 times before finally accepting the block data. Apparently Pixy has a listening problem?? Anyway, before this, I tried every timing method and communication method I could think of to no avail. This is finally what worked:

int Bri;
int D = 20;
int W;

for (int p = 0; p < 30; p++) {
	pixy.setBrightness(Bri);  //Set initial brightness. Range is 0-255 
	delay(D);
	pixy.getBlocks();
	delay(D);
	}
		
blocks = pixy.getBlocks();
W = pixy.blocks[0].width; //get width

If anyone has any ideas why this worked, I’d love to hear them because I’m still getting random checksum errors.

#3

Hello David,
You bring up a couple issues. It seems that one issue you are having is that you don’t seem to be getting good block data into your Arduino (when compared with what you are seeing in PixyMon). Is this correct? Perhaps we could focus on that and defer the brightness problem until after we get this first problem addressed.

If you run the hello_world Arduino program, do you see good/consistent data from your Arduino?

Edward

#4

I have no reason to suspect erroneous block data while running “hello world”.

#5

Hello David
Try adding a call to pixy.setBrightness() after pixy.getBlocks() in the hello_world program. Usually adjusting the brightness isn’t needed on a frame-by-frame basis, but it should work.

Let me know what you find.

Edward