Is FPGA the right way to go for recognizing cards from a desk?

Question

I'm building a playing card dealing machine and I would like to get some advice in regards how I should do with my image processing.

The card will be scanned and depending on the suit and rank of the card it will be place in 1 out of 4 slots.

The best way I believe (Which does not have to be the right one..) is to use a FPGA chip for the image recognition. A FPGA chip seem to be very affordable for the speed but I have no experience with this. So here is a few questions.

1. Is FPGA to way to go or should I look into a different solution? (Low price and energy consumption is two important factors for me)
2. Is it best for example to read the corner of the card and read the suit and rank individually(4 suits and 13 ranks) or just compare against the 52 cards right off? I really want the solution simple so I can for example easily use different layouts of decks.

Hope I'm making some sense here!

Thanks, Stefan

Answer 1

For this kind of application I would rather think of a DSP solution. You'll probably find image processing code easier for DSP than for FPGA. Sure, you can run a soft DSP on the FPGA, but I wonder what the FPGA's added value would be. It seems you don't need extensive peripherals around the DSP which would justify a great amount of gates.
Just connect your camera to an A-to-D converter and let the DSP do the rest.

Analog Devices has this image processing toolbox for its Blackfin DSP. Analog has several DSP lines. I would look for a DSP development kit targeted at image processing.

Answer 2

Both FPGAs and DSP chips are specialized optimizations where you trade greater difficulty in implementing an idea for the mere possibility of higher performance for a given physical volume and cost. That is, relative to using a commodity PC.

As a result, your best bet is to first get an algorithm working (at any speed) using a PC and webcam. Then, once you know precisely the kinds of computations that need to be done, you can contemplate pushing it onto an embedded platform and make an informed choice of what that platform should be (embedded general purpose processor, DSP, or FPGA).

Edit: one thing to think about when doing this is integer vs. floating point. There are floating point DSPs, and even blocks you can put into FPGAs, but especially for the later integer implementations would be simpler to build. Obviously a modern PC can do both.

Answer 3

Context matters:

1. Budget -- what's the most you can spend on the hardware and IP purchase / dev?
2. Performance -- roughly evaluate the required performance (throughput, power consumption, etc.)
3. IP -- find which platform candidates (FPGA/uC/GPU/whatever) has ready made IP components within your budget and performance margins.
4. Prototyping -- identify prototyping platforms that are within your budget, support existing IP you require, and are within your performance envelope.

Once you have thought of those things you'll be able to answer the question yourself. As it stands, there's too little information here (for me) to provide a more meaningful answer.

By the way, your second question is a bit off-topic to the main question; consider asking it again once you decided on a target platform.

Answer 4

FPGAs are best for massively parallel operations.

It's best to look at your algorithm and ask yourself, "If I had 100-200 slow multiplier/accumulator units instead of one really fast one, would it run faster?" In other words, can your algorithm be broken up into a lot of little parallel operations that have minimal interdependencies (places where one operation depends on the result of another)?

Another question to ask is, "Do I have huge I/O requirements that could be fixed by replacing a couple multi-megabyte RAM banks with hundreds of smaller, independent 32-to-4096 byte banks?"

If the answers to these questions are "yes", then an FPGA may be a good solution and you should look into the algorithm more closely to see if it does fit. Otherwise, use a DSP.

Answer 5

Is your goal to have a solution that will work with any bridge-size deck, or a solution which can be adapted to work with some particular readily-available bridge-size deck? If the latter would be acceptable, and if you could move cards vertically through the machine, you might be able to get by with a single optical pickup. Were it not for the fact that they use red light, one might even be able to get by with an off-the-shelf reflective photo-eye unit or swipe-style barcode reader; I'm not sure red cards could be scanned reliably with a red LED, however. Perhaps some vendors' cards would work reliably with an IR-LED scanner.

In any case, the goal would be to draw a vertical line some distance from one edge of the card such that all 13 ranks and all 4 suits would yield unique patterns. I would expect that most vendor's card designs would be amenable to finding such a line. If one needs to have the cards move horizontally, it would most likely be necessary to use at least 2-4 lines through the card (one or two each for the rank and the suit). Things would be complicated by the fact that the top half of a spade looks like the top half of a diamond, and the bottom half of a heart looks like the bottom half of a diamond; it would thus be somewhat difficult to have a single horizontal line distinguish all four suits. By contrast, a slightly-off-center vertical line would yield three blobs with a club, two blobs with a spade, a large blob nearer the top for a heart, and a smaller blob for a diamond. Such a line might also be adequate to distinguish all the different ranks, depending upon how the figures are drawn.

Perhaps the best bet would be to have three sensors if the cards move vertically through the machine, or five if they move horizontally (three for the rank and two for the suit), and figure that for most deck designs will probably yield 13 different scan patterns for the rank and 4 for the suits). Grab maybe 32 pixels from each sensor if scanning vertically, or 16 if scanning horizontally (so one will have either a 3x32 or 5x16 bitmap). Scan a dozen or so sorted decks and tally up how often each pixel is on or off for each type of card.

Then to read a card, scan it as before. Compute the match score for each rank/suit by adding up, for each "on" pixel, the number of "reference" cards of that rank/suit which had that pixel on, and for each "off" pixel, the number of "reference" cards of that rank/suit which had that pixel off. If the printing on the cards is at all consistent, there will most likely be one rank and one suit whose match score far exceeds that of any other. That's your card.

No particularly fancy processing should be required. An ARM should be able to handle this task "hand"ily, but even something like an 18Fxx by Microchip should be able to "PIC" out cards pretty reliably.

Answer 6

I have only used the eval board to get my feet wet with it but you might look at the xmos.com xcore processors. They are a hybrid if you will. Multithreaded processors, which means you program them using C and a C compiler, but designed for replacing cplds and fpgas, the processor is geared heavily toward hardware type operations. Above average programming for a software engineer but not as far as you would need to go to get into HDL.

Depending on how far you want/need to go you may just want to put a dsp down with an fpga front end depending on what your interface is. Or there are a number of pgas with processors inside, both hard cores and soft cores. It really takes some experience with fpgas though to get that logic running in double or triple digit megahertz frequencies.

You might look at something like the beagleboard or hawkboard, basically to take advantage of the DSP with the ARM next to it (running in the several hundred mhz range) it would all depend on the I/O you need for the processor.

I imagine you are using some sort of video/camera module to snap a color picture, I guess even black and white would work. Those normally have only a few pins on the interface so you could probably feed that into something on a beagleboard or hawkboard. I know there are folks other than embeddedarm.com (processors with fpgas on the board, but not omap processors) that have fpgas on the eval board you get a win-win, just have to wire it up not build a pc board. Cant think of it right now...

Now if you put a barcode on the cards, you could be like the post office and be able to sort the cards as fast as you could physically move them. with a camera approach just taking the picture is going to be difficult with off the shelf solutions then getting into something to be processed on a probably slow interface then you can process it quickly. At first you are probably going to still end up with a system that only knows one brand or font if you will of cards (not unlike barcoding the deck).

doh, just saw the comment on another post, yes the leopardboard looks good assuming you can repurpose the video processing. If it only has a few canned features, the jpeg family, h.264 and some others and this face recognition thing, and is difficult to redesign maybe you want to go with a generic DSP.

Answer 7

Put some linux board with a video grabber connected to some high resolution camera above the desk. Then all you have to do is to isolate card rectangles from the image (cards may overlap), rotate them, isolate letters/numbers and shapes, and recognize them.