Hey, we could use your help with a semi-detrimental issue with our Axis vision tracking system.
We have loaded the FIRST sample code (2010ImageDemo) and have got it running on Classmate; however, the system is tracking down too many other shapes besides the target. This is causing our camera to run a lot slower than normal.
We would like to know if any other teams have had a problem with this, and if so, how they have gotten around it.
Thanks for your help :]
Actually, there should be a white paper on the FIRST site that discusses tuning and troubleshooting. To speed things up, fewer pixels is indeed a common approach, but keep in mind that as pixels get larger, they represent more stuff in the real world. They average lots of detail and capture it in a single pixel. That averaging tends to round off corners and generally make everything look fuzzier. This will naturally make it more difficult for the ellipse code to be accurate.
Another way to speed up the vision code is to raise the edge threshold. This defines the difference between light and dark that defines an edge. Set too low, and all sorts of small things in the image will need to be mathematically fit, then filtered for ellipses.
Anyway, it would also be helpful to know what speed it is running at. Slow is not very accurate for debugging. And the first thing you may want to do is make it accurate, then try to speed it up. Do you want fast and buggy, or slow and accurate?
Greg McKaskle
What changes were needed to either the enviroment or software to get your system to work. My camera is talking and I get a clean build with WindRiver but no image or tracking.
Bill
That would be great to have, but I can’t find it. Who should we poke to get it released?
I spoke too soon. Due to a misunderstanding, it will be posted on the NI site shortly and will have a link from FIRST.
Greg McKaskle
It’s posted now: http://joule.ni.com/nidu/cds/view/p/id/1568/lang/en
You can get to it through the FIRST 2010 Control System page as well.
I’m concerned about the white paper’s assumption that there won’t be “Streaked lighting” obscuring parts of the target at events.
In previous years this has often been a problem - vision systems work reliably in development and do not work at competition due to the (very) bright lighting.
Any suggestions about approaching this? We’ve tried modifying the curve options to try allowing curves with a gap to still be considered closed, or allow open curves, but have had limited success.
The streaking assumption was based on movies taken with cameras onboard robots. Also, the lights on official fields tend to be on the long side of the field facing center, thus not shining into the eyes of the coaches and drivers.
If you intend to turn on occlusion, be sure to limit it to 20% or less. Also beware that this will probably require lowering the ellipse score and perhaps the overall score.
Greg McKskle