|
|
|
![]() |
|
|||||||
|
||||||||
|
|
Thread Tools | Rate Thread | Display Modes |
|
#1
|
||||
|
||||
|
WPILib Bugs (Fixes FindColor unreliability)
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: Code:
imaqMeasureParticle(binaryImage, particleIndex, 0, IMAQ_MT_BOUNDING_RECT_LEFT, &position); if ( position < (rect.left + rect.width) ) return false; 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: Quote:
Quote:
Last edited by Bongle : 13-01-2009 at 08:29. |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| pic: Hex Bugs | Freddy Schurr | Extra Discussion | 1 | 11-05-2007 09:54 |
| Portal Config Fixes | Brandon Martus | Announcements | 0 | 28-06-2006 13:27 |
| PWM cables: too fragile? what fixes/precautions? | BillCloyes | Control System | 18 | 14-03-2005 17:34 |
| Email Bugs | Brandon Martus | Announcements | 0 | 07-03-2003 22:53 |
| robot fixes for battlecry 2 | mike o'leary | Off-Season Events | 1 | 20-06-2001 23:37 |