Pic2Plate

The Raspberry Pi controls the camera and captures several views because a single frame rarely shows every item clearly. Packages hide behind one another, produce changes under different lighting, and the same object can appear again when the user moves things around, so I had to collect several frames without adding every detection as a new ingredient.

I handled repeated detections in the inventory stage by comparing results from successive frames and merging them before they reached the interface. This reduced duplicate entries while preserving genuinely repeated items, which mattered because an extra onion or a missing package could change the recipes the user received.

Most of the engineering work sat between components, where recognition output had to become stable application data, the inventory had to survive updates from multiple frames, and the front end needed names and confidence states that made sense to a person standing beside the scanner. I defined those boundaries explicitly so the hardware capture and interface could change without rewriting the entire flow.

Real input exposed cases that were easy to miss with prepared images, including partial labels, duplicate items, and frames where the model found nothing useful. I added handling for those cases so one weak frame would not wipe the inventory or break the rest of the scan.

After the scan, Pic2Plate shows the detected inventory before using it to find recipes, which gives the user a chance to catch an incorrect item before it changes the suggestions. From there, the groceries already sitting in front of the camera become recipe inputs without the user having to enter each ingredient manually.

I ended up spending a large part of the build on camera placement, inventory state, duplicate handling, and the handoff to the interface. A correct detection still caused problems when it arrived twice, replaced the wrong item, or appeared under a label that was confusing in the recipe view.