I’m looking for an arduino/raspberry pi fan to take on the design work of making a card-sorting robot for me.
This is a paid gig. Budget is $2500 CAD. If you can do it for less, keep the rest.
Details
I have a stack of 1000 cards (at a time) from a trading game like Magic: the Gathering, YuGiOh, etc.
The first half of the machine identifies the card. The second half sorts that card into appropriate bin(s).
At a minimum two bins (accept/reject), possibly more. Aiming to process 1 card/second. Important to not damage the cards.
The work can be done at VHS. I want documentation along the way - what works, what doesn’t, how to build duplicate machines.
It is likely different card families are mixed together in a stack, and have to be sorted by family first. Once a single machine has been made, they can be daisy-chained to triage the problem into sub-problems. Additional funds would be available later for this later step, but it’s worth keeping in mind while building machine #1.
much work has been done on card identification already. I suspect the harder part is the mechanical component.
I really want to take this on but worry I wouldn’t have the time to finish it on an acceptable timeframe. Nonetheless, I have some questions:
How open/closed is the project? Can the designer post the documentation and build logs, or is this a design you wish to keep under wraps?
How many output hoppers to you imagine? In other words, how many categories can the machine sort in a single run?
What’s the benchmark for success? Building the mechanics is one thing, but there is significant risk in getting the computer-vision classifier working perfectly, and is dependent on the design of the cards and the variation therein. What is an acceptable rate for false positives (category includes a wrong card) and false negatives (card is not identified and goes to an “unknown” bucket)?
Is a training set available? Is there a database of all cards in existence that could be used?
once the project is approved, I’d want a v1 within a month. I will assist with the code part of the project and have identified a few RS232 card dispensers that can be made to work with a Pi. A OTS card sorter (eg, put this card in bin N) has not been found, which will probably be the bulk of the work.
Just to try to scope it out for takers (I don’t have mech design skills to take this on):
The optical recognition is the hard bit here in my mind. Building profiles for the different card games, and having an interface to select which go where, and the logic there, would take a decent amount of thought and knowledge of the games.
For magic cards, the art changes quite a bit, there are a bunch of different editions and releases, etc. You’d need to study up quite a bit on the cards just to come up with the filters for each set. You said there is work done on this part already?
As a last note, I imagine it being not much harder to bin the cards into multiple bins, lessening the need for future passes through the same machine or additional machines.
You don’t think OCRing a portion of the card would be a better route to go? You know on a Magic card, the title will always be in the same location on the card. Then your templates per-game would essentially just be a block to show the system which part of the image to OCR to get the name (and edition/release/etc if desired)? They can change the art and background all they want then
I think the easiest approach for the highest number of bins might be a ‘whole system on a lazy-susan’ sort of thing with a ring of bins around the sorter. If you can pick up a small conveyor then you can increase the circumference and therefore get more bins.
Yes, the image recognition is the hard part of this, but there are some projects that already exist out there; also, there’s databases of all cards from all editions out there, that might even let you determine which edition a card is if the art changed since you wouldn’t get a compressed match.
@Rob_MacKenzie
OCR on cards has been done and is open source.
Canonical images of every card released for most major games are already available online.
Several youtube videos show people’s experiments with best methods for card matching.
@miststlkr
two editions of the same card with different pictures could fail on a partial scan. let the machine do what it’s good at and scan the whole card.
That approach doesn’t allow for chained sorters, but it does allow for expansion of the system by increasing the radius; not sure if that’s enough bins or if the system needs to truely be chainable.
I’m a fan of the chained sorter idea. it can even be expanded to a 2d grid of sorters, or a tree. the conveyor between nodes or leaves (bins?) is the part where I get stuck. I’m happy to do the OCR stuff.
what are you optimizing for? flexibility, speed, etc?
If you are optimizing for flexibility you could treat your sorting like sorting an array and build the output to feed back into the input for progressive sorting algorithms, you could also have, on the last pass, some boundary item (like a blank card) in-between final categories
Do you have a ballpark on how many of these machines you want? I.e., Is the deliverable design a one-off that can be re-created or are you looking for something that can be easily manufactured? (e.g. 10’s, 100’s, 1000’s)
In other words, is there a budget target for the actual machine (or duplicates)?
there is no budget target. obviously if we can build one for less than 2500 the rest should also come in at that price, and if there’s enough units ordered at once then economies of scale come into play. To me that’s a optimization problem for after it’s working.
By what are you optimizing for, I’m asking that for specific end goals in mind and which attributes are the most important to be good in the final design. It sounds like you have a particular purpose for this in mind. That end goal should influence what designs are initially pruned.
For instance, if cards/minute are important in the final system, then that influences what designs (such as iterative sorting) are invalid.
I’d value accuracy over speed and then I’d want as fast as I can get. 1 card/s? The open source card is systems I’ve seen look crazy fast. I imagine the sorting hardware is the bottleneck.
