<< return to Pixycam.com

Differences between Cooked view and Default

Pixy Software
#1

Hello, I am trying to use the pixy for a tracking application, using three different color codes. I need this to work at in daylight, in the shade and at night (using an EL panel as a backlight for my color codes), so I am using 6 signatures and different ranges, each pair tuned to a different environment.

However, I’m seeing different results in pixymon’s Cooked view and the Default program.

[Album] Imgur

Default is what I need to tune, but it always seems to work under different parameters than the cooked view. I’m getting perfect results in this particular instance on the cooked view, (signatures 3 and 4 are meant to be for shade), but default detects signatures 2 and 3 in an erratic fashion, with some false negatives.

Why are the results in cooked and default different?

EDIT: Another example, here the outdoor sunlight CC a detected just fine in default, but they are nowhere to be seen in Cooked view:

[Album] Imgur

#2

Hello Jose,
That is definitely odd. The only real difference between cooked and default is that cooked is 1/2 the resolution of default, but this wouldn’t explain the differences you are seeing. What version of firmware and PixyMon are you using. Be sure you are using the most recent versions:

http://cmucam.org/projects/cmucam5/wiki/Latest_release

Also, I’m not sure why you are using 6 signatures – are you setting signatures to the same color but different lighting conditions? That is, for example, signatures 1, 2, and 3 are for pink under sun, shade, night, respectively? This can cause some strange issues because (in the case I just described) signatures 1, 2 and 3 have lots of overlap on the color wheel. Pixy will tend to give signature 1 the biggest portion of the color wheel and signatures 2 and 3 will only get small sections, sections that aren’t taken by signature 1, and therefore behave strangely.

I’m not sure why you are getting a disparity between cooked and default modes, but using the signatures like this is not recommended.

Edward

#3

Thanks for the response Edward. It looks like I was a few versions behind in PixyMon, but up to date in firmware. I updated, but checking again, it seems to be behaving as before, apparently showing different results in cooked and default views, as shown in the attached images.

This changed as I was writing this post, resetting to default parameters, clearing all signals and teaching the two I was testing again now shows parity between cooked and default. Must have been something with the configuration I had.

As to the other point, that was the idea, yeah. Ideally, I want this application to work outdoors where lightning conditions can change dramatically and to be able to function at night with an EL panel on the tracker. Current configuration in signals 1 and 2 for pink/green and 3 and 4 for backlit pink/green. Still testing it out, I’m adding pictures of the EL panel as well, which showed some differences between cooked and default again, but not nearly as immense as on my last setup.

That said, how would you recommend working with sunlight, shade and night? At the moment, I’m trying to setup a sweep with the ‘int8_t setBrightness(x)’ command to help it adjust in sun/shade if it does not detect the 3 CCs after a period of time. For night I have 2 more signals plus the EL panel. So given your last post, I tried to go from 6 to 4 signals and need to run some tests.

#4

Hello Jose,
Those conditions (indoor, outdoor, dark) are fairly different. You’re probably getting a sense that you’re running up against Pixy’s capabilities, at least now. One suggestion, and it’s not a super awesome one, is to have one set of signatures for each lighting condition. You can save off the parameters and reload them depending on which condition you’re encountering.

http://cmucam.org/projects/cmucam5/wiki/How_to_SaveRestore_Pixy_Parameters

Give this a try and let us know how it goes. If it works well for you (aside from being a pain) we can consider implementing a signature disable feature where you could have 6 signatures and disable/enable them accordingly such that they don’t step on each other. I guess the missing piece then is being able to determine which “mode” you’re in, but let us know if this might be helpful.

Edward

#5

Thanks Edward.

Yeah, I think I’ll forgo the daytime tracking and just focus on the night time setting, at least for now. This is meant to be used as a headtracking element on an ATV to direct a pair of spotlights, it should be used mostly at night anyway.

It would depend on the application, but I could see a lot of use in the disable/enable feature. Here, for example, if the system is on it should be seeing the pattern and reporting three different color codes. I would probably set the trigger to having X cycles with less then the three CCs detected, if this is true, then I would load the other parameters or switch the active signals.