Quote:
Originally Posted by Greg McKaskle
<[1]> If you have access to a computer with last years files on them, flip through the NI Vision Concepts manual. [...]
<[2]> If this were going to be used extensively for FRC, we'd add a training dialog that'd generate the skewed images automatically. If the characterization doesn't support rotation or scaling, then those would need to be generated too, or we'd move to other techniques such as geometric edge detection.
Greg McKaskle
|
Replies:
<[1]> Unfortunately, I don't have a system available PERSONALLY to me with last year's package installed. My main team (I coach several) can't find their 2009 KoP NI distribution disk either (which is a separate issue)...
However, technically, let me take a crack at this, from a
theoretical level... <cracks fingers>
As long as the Fiducial block has unique recognizable perimeter features, it should be quick to isolate in a random image. The example given above was a "white square around black square, with data in the middle". In our case, since we have a
color camera, IMO it should be
much smarter to try something like "a Blue square around Red square, with Green/Black [or White/Black] data bits in the middle". This unique boundary
should be easily found in any scene (it's similar to the Flag ID problem this season)
and characterized quickly with simple operations, to create the bounding box mask for further processing (eg scaling). You can then
directly pluck the data bits from the projected image and do a quick lookup table (which I'll describe below).
As long as the data encoding scheme within the framework gives a unique pattern for all 4 rotations of the square, you're golden. If I'm given just 15 unique Fiduciaries that can be quickly decoded and tracked by NI Vision, that should be MORE than enough for ANY game I'm contemplating.
15 possible Fiduciaries translates to four bits. Accounting for rotations, (and no ECCs) that's only sixteen bits max in the data image. A sixteen bit optical matrix is simply a 4x4 blob block, where 4 bits are significant, and the 3 mirror positions for each data bit are always ZERO.
The bounding bicolor parallelegram directly IDs the data bit XY positions within it, regardless of projection, by thinking of a Cross Hatch defined by drawing lines across equal divisions of each of the four sides to its opposite side. (Your optical projection and distance limit is when the parallelogram is squished/small enough that intersections approach each other enough to be less than one pixel...)
Now, given the XY positions of each bit, you populate the sixteen bit table, then look up the 4 bit answer. ( TAA DAA! )
In my mind's eye, this OUGHT to be
quick to do, IF the library has suffficient image primitives. (...and I WISH I had a library to look at...) Maybe you can comment on whether or not the current library has sufficient primitives to try this already written...
<[2]> Next: I can't speak for FIRST GDC. I was interested in this for two reasons:
A) Possibly designing some SIMPLE but FUN off-season games for everyone to try next summer, using what we already have available. If we can jointly solve the Fiducial ID and Tracking problem part of this,
many cool things become possible...
B) Opening The Door
for the GDC, by suggesting games that COULD use this feature (again assuming we somehow figure out how to get it to work). I'd
love to make a demo of a simple game based on Fiduciaries, but to do that I need to figure out how to create and track a few Fiduciaries with our cRIO hardware and Axis 206 camera system.
Preferably, I'd like to be able to ID and track more than one Fiducial in any scene, but that's not necessary for Proof of Concept, as many games can be defined where you only see one Fiducial at a time. (BTW... An alternative to multi-track is to have a fast mechanism to MASK a Fiducial once it's understood, so another CAN be sought and found in the same scene).
As to having to skew images for training, proper definition of the Fiduciaries (as defined above) should eliminate the need for ANY kind of a training system. It's a simple feature extraction, conversion of the chosen pixels to bits to make a word, then a table lookup.
Of course, you probably want to add a few redundancy data bits in the Fiducial for error correction to make sure you ARE looking at a Fiducial and not "a robot's guts with all the pretty colored wires in it" that HAPPENS to look like a Fiducial (or a partially occluded Fiducial). But THAT is a second subject, to be addressed once "BASIC Fiducial tracking" is cracked...
(BTW... Robot wiring is why I said "Red and BLUE" boundry, not "Red and BLACK"... )
Does any of this make sense? I'm not sure if I explained this well or not.
There may also be many OTHER or BETTER ways to do this that uses things tougher techniques already WRITTEN (eg: pattern recognition training?), but I'm trying to take the direct approach and throw a Straw Man out there, just to get everyone's brains started and get the ball rolling...
Given that criteria, is there anyone out there that's a Vision Jock, that HAS access to the 2009 hardware and software, that wants to take a crack at finding a Fiducial in a scene? Unfortunately here, until we can find our disk, get our software up on another system AND get back up to speed, my hands are tied. But I'd be happy to correspond with anyone that wants to take a crack at it!
- Keith