Q-Arm Shopping

01 Project Narrative

To simulate an Amazon-style fulfillment experience, our team needed a Q-arm system that could convert a shopper's verified order into a real packaging action. That meant designing a gripper mechanism driven by the Q-arm's motor, and writing software to handle accounts, order validation, order summaries, and coordinate passing — all while staying within grip-force requirements and the Q-arm's placement accuracy.

02 Team's Work & Personal Contributions

How does a group of five students get a robotic arm to pack groceries? As a team, we developed and iterated on our end-effector design for gripping objects with the Q-arm's motor, testing each version and noting what needed to improve. Early on we found the grip force was far too weak, which led us to resize the gears. I was tasked with editing the model directly — using the team's testing notes to design a mechanism that was more efficient than the last. Our goal was simple: find the flaws in the current design and eliminate them. By the final version, the gripper had little to no flaws and wrapped accurately around every object.

The next challenge was friction. I took on researching a material to help the claws grip cleanly, and landed on gel tape — a rubbery, sticky double-sided tape. After wrapping it around the claws and rubbing off some of the excess stickiness, it reliably picked up objects and delivered them to the basket.

After that came object coordinates — another task I took on directly. I needed code that could be easily adjusted, used to map coordinates to objects, and displayed in an organized way, since we ended up changing coordinates for each object often. My solution was a Python dictionary, where each object (as a string key) mapped to five values:

• X position
• Y position
• Z position
• Degrees to open the claws
• Degrees to close the claws

This made it easy for anyone on the team to adjust variables without digging through the rest of the code — it saved us time and gave the codebase a more professional structure.

03 System Integration & Debugging

Editing the design to fix errors was straightforward, and so was debugging the Python functions on their own. The real challenge came when we combined the hardware, code, and CSV files together. Integration surfaced a string of new problems:

• Unpredictable Q-arm motor rotation (frequently overshooting)
• Gel-tape-covered arms sticking together
• Movement deviations even with identical coordinates
• CSV file errors
• Difficulty importing files into the Q-arm

The unpredictable motor rotation caused every early trial to fail — objects were knocked over instead of picked up. We initially suspected the code being sent to the Q-arm, but found that even a 1-degree rotation command triggered a much larger physical rotation. The real fix turned out to be mechanical: adding stoppers that physically prevented the arms from over-rotating. That let us predict arm position reliably and stopped the gel-tape arms from sticking to each other.