WPILib Bugs (Fixes FindColor unreliability)

[Bongle]

Team 2702 and I have found what appear to be several bugs in the chain of functions called when you call FindColor. They don't completely stop it from working, but they nearly do. If you're using WPILib and your FindColor works, it is likely mostly due to luck. If you're using WPILib and your FindColor generally picks up single pixels even when you're SURE your TrackingThresholds are set perfectly, then this thread is for you. If other teams have been having trouble with FindColor being fairly finicky or unreliable about picking things up, maybe these tips could help. I can't post our source code because I'm don't have access to it right now, but hopefully these tips should guide you.

MODIFY YOUR WPILIB SOURCE CODE AT YOUR OWN RISK. MAKE A BACKUP.

1) InArea (TrackApi.cpp). Look at this code:

imaqMeasureParticle(binaryImage, particleIndex, 0, IMAQ_MT_BOUNDING_RECT_LEFT, &position);
if ( position < (rect.left + rect.width) ) return false;

So if the left side of the particle's bounding rect is less than the right side of the caller's input rect, it returns false. It seems that the "+ rect.width" shouldn't be there. The rest of the conditions to return false in InArea appear to be incorrect as well.
2) GetLargestParticle (TrackApi.cpp)
The very first thing this function does it blow away the caller-supplied pointer (instead making it point at a stack-declared variable), thus making it impossible to return the largest particle index. Though it never seems to try to return the largest particle index in its current implementation anyway. Note that even if you fix the return problems, this function won't work right until you fix InArea as well.
3) FindColor (TrackApi.cpp)
After its call to GetLargestParticle (see (2)), the main implementation of FindColor does "if (largestParticleIndex == 0) { /* lots of analysis code goes here */ )". It seems that this should be "if( largestParticleIndex >= 0)", since you can have nonzero particle indexes once GetLargestParticle and InArea is fixed.

Hope this helps some teams. Again, use at your own risk, and I imagine WPI will have fixes for these soon. But if you want to get FindColor working better, these should help until WPI puts official fixes out.

The effect of these three bugs is:
-InArea fails pretty much every time
-GetLargestParticle always appears to return 0 for the largest particle index because it doesn't change the input parameter.
-FindColor uses that 'returned' index, and analyzes the 0th particle. This _could_ be your target, but more likely it'll be a single-pixel noise blob in the top-left of your image.

With these fixes:
-InArea correctly returns whether a given particle is in your search rect
-GetLargestParticle actually returns the particle index of the largest, rather than the first, particle
-FindColor does analysis on the largest particle, which will more reliably be the particle you're actually interested in


And a little pre-response:

You should email WPI with these

I did just before I posted this thread

Teams should wait until WPI posts their official fixes

They should, but if they are risk takers and want to make their camera work properly sooner, they can try to implement these fixes.

[Dr Nick]

Ah nice. My team is working on vision either late this week or early next week so if there's no update by then we'll definitely implement these fixes. You guys rock!

[Joe Ross]

Looks like you found the same things team 67 posted about on the FIRST forums a few days ago: http://forums.usfirst.org/showpost.p...7&postcount=28

[Bongle]

Originally Posted by Joe Ross

Looks like you found the same things team 67 posted about on the FIRST forums a few days ago: http://forums.usfirst.org/showpost.p...7&postcount=28

Well, it's good to see we found the same stuff independently and we're not just crazy.