MTG Collection Manager

Introduction

In the multiverse of Magic: The Gathering (MTG), the complexity and variety of the card collection is what makes the game so great. It is easy to see a common challenge among players: the task of organizing and managing extensive card collections. Inspired by this, we developed a system that not only autonomously digitizes MTG cards, but also simplifies the management and tracking of these collections. Our project brings many elements of engineering together with our physical feeder mechanism to our QT user interface and our SQLite database. We strived to create a solution that blends practical utility with the engaging world of MTG. This project challenged us to push our boundaries, expand our skills to find ways to bring this project together.

Hardware

The foundation of our hardware design was inspired by an existing project on Instructables, which we modified to suit our specific needs. The core structure was built using home-made ultra-strong cardboard, Lego wheels and axles, and standard hardware store parts. A notable contribution to our design was 2 pen springs, generously provided by our professor, which became an essential component in the card feeder mechanism as it pulled the top and bottom tracks together, allowing the rubber wheels to grip the cards.


Full mechanism view of the card feeder.


Reinforcing the cardboard with sticks.


Reinforcing the cardboard edges with spackle.


Pen springs used in the card feeder mechanism.


Camera mount and dropbox setup for card scanning.


Behind-the-scenes view of the servo and gears.

We constructed a light foam drop box to catch the cards post-scanning. We initially had our camera and scanning location more towards the front. But found much more consistent success on card scans after moving it farther away from the motion This new design ensures much more orderly handling of the cards as they pass through the system. To integrate the scanning functionality, we modified the design by adding attachments that perfectly position the camera for optimal card recognition. This setup was crucial for accurate image capture, which directly impacts the system's effectiveness in card digitization.

One of the significant challenges we encountered was the unavailability of a specific gear crucial for the feeder mechanism. To overcome this, we turned to 3D printing, which allowed us to fabricate a custom gear that precisely met our requirements.

Software

The software architecture of our system is the core of our digitization magic. Our approach utilized the following libraries/APIs:

• QT: For developing our user interface with UI and multithreading capabilities.
• OpenCV: Used for image processing and preparing card images for recognition.
• AWS Rekognition: Integral for card text recognition, extracting text accurately from card images.
• Scryfall API: For detailed card information and its fuzzy search feature, which minimized recognition errors.
• SQLite3: Our relational database for collection management, allowing filtering and searching of the collection based on various criteria.

Card Processing Workflow:

1. We initiated card feeding and scanning on a new QThread.
   
2. Text recognition via AWS Rekognition.
   
3. Card data was then fetched from Scryfall and stored in our SQLite3 database.
   
4. We utilized SQL queries for filtering the database.
   
5. Emailing users their collection was handled through Linux commands.
   

Software Hiccups

• Tesseract: We found Tesseract OCR to be unreliable for MTG card recognition, which was consistent with other sources online. Attempts at heavy preprocessing and using a pretrained Tesseract model for MTG cards were made before switching to AWS Rekognition.
• Project Deletion: After inadvertently deleting our project with a 'sudo rm -rf' command, we had to rapidly reconstruct our work. This stressful situation was a critical learning point on the importance of regular commits to version control systems.
• QT on piTFT: Despite initial frustrations with QT on the piTFT, we achieved a functional GUI. The experience deepened our understanding of QT’s signals and slots and how to structure a QT project, including incorporating touches like MTG arena's light-up buttons.
• CMake Challenges: We encountered significant challenges with CMake but overcame them. We were able to work through them with the help of online forums.

Testing

Our testing protocol was comprehensive, we started with a variety of MTG cards across different filters to ensure the robustness of our card recognition and sorting algorithms. We included both older and newer cards to make sure almost any magic card would be covered. We meticulously adjusted the feeder timings and PWM values to fine-tune the card dispensing process. The challenges with lighting due to card glare were addressed by modifying the environment and scanner placement.

The switch from Tesseract to AWS Rekognition was also part of our testing process. While testing Tesseract we noticed nothing we would do would work well for magic cards. We dramatically improved the accuracy of text recognition by making the move. Through these rigorous testing phases, we honed both the hardware precision and software responsiveness of our system, making a reliable and user-friendly platform for MTG card collection management. Although our feeder is not perfect it is in a pretty good state.

Results

The project culminated in a sophisticated system that not only scans and digitizes Magic: The Gathering cards but also offers a dynamic user interface for collection management. Each card is able to be scanned with precision, and its data extracted and stored. The system demonstrates very high accuracy, with card's details easily viewable after scanning. Users can now easily filter, sort, and search through their collections, making the management of even the largest card collections a seamless and enjoyable task. The only thing we were unable to get to was card condition assessment but it is coming soon in the next version!

Conclusions

In conclusion, our project successfully achieved its goal of creating a digitized management system for MTG card collections. The project leveraged a combination of hardware and software integration, including 3D-printed components, computer vision, database management, and a GUI to provide a seamless user experience. The system's ability to adapt to various cards and the intuitive interface design highlights our functionality and user-friendliness.

Future Work

• Speed Optimization: We plan to significantly reduce the card scanning time, which currently takes approximately 4-5 seconds per card, by developing our own text recognition model that is specifically designed for the unique font and format of MTG cards.
• Lighting Robustness: To counteract the variability of lighting conditions that affect scan quality, our next step is to design and integrate a custom lighting attachment that will provide consistency, ensuring the system's reliability in different environments.
• Card Condition Assessment: A key feature planned for the next version is the assessment of card condition and automatic pricing. We did not get this feature done in the current iteration due to time constraints. In the future, we will implement image analysis techniques to evaluate the wear and tear on each card, adding another layer of value to the collection management system.

Source Code

Access our code here: https://github.com/AbioticFactor/mtg-collection-manager

Parts List

• Raspberry Pi: Provided by lab
• piTFT: Provided by lab
• USB Camera Module: Estimated $10.00
• Custom-built Card Feeder: Material costs estimated $30.00
• Wires - Provided in lab

Total: $68.00

References

Base feeder build
Bootstrap
Pigpio Library
SQLiteCPP Library
QT documentation
AWS documentation
ECE 5725: Labs 1 - 4
Student Website (campus congestion guide)
Professor Skovira