ME35 Project 6: The Pinching and Positioning Agent (PaPA)
In ME35, a course in mechatronics and robotics, we were tasked with building an Amazon warehouse style pick-up and drop-off robot. There were two fixed pick up locations; we had to send a robot to each, scan the item at the pick-up, and bring it to its designated drop-off location. Of course, all of this was to be made autonomous.
Our professor provided us with one week, an iRobot Create 3 and a Raspberry Pi. We had to build a gripper from scratch, but we were told that we could position and orient the items-of-interest in whichever way we'd like, enabling the use of a simple 1DOF claw.
For a long time, though, I've really been meaning to make a robot arm. Naturally, I somewhat forcefully self-imposed a constraint on our group that rather than just making a gripper, we should strive to fabricate an arm that could lift the object without us positioning it in any special way.
We needed to scan, identify, and grab toys from the set above.
WAREHOUSE ITEMS
This is our robot with the arm
integrated
PaPA
Our robot arm uses two sponges to grip those in front of it
PaPA Lifts
PaPA in Action
-
Before demo-day, our professor provided us the coordinates of our drop off and pick up locations. At a high level, our code essentially use ROS to send these coordinates to our robot, which uses its internal sensors to navigate to those locations.
-
Upon arrival, PaPA uses its Raspberry Pi Camera to detect the character at the location. We run the photos it clicks through an ML model to identify the character up ahead.
-
We trained our own model for this task. We took hundreds of photos in different angles and lighting conditions, and processed them through a beginner-ML training software called Teaching Machine, enabling us to distinguish between the different toys.
-
After detecting the toy, our grabber rotates downward, collects the character, and brings it towards its designated drop-off spot.
-
The biggest challenge, certainly, was constructing our arm. Our motors were not very strong, so we prioritised making the arm shorter and lighter. This is why the bulk of the arm is hollow and made with a very low (5%) infill.
-
Unfortunately, none of our stepper or servo motors possessed enough torque for our task. We therefore were stuck with using a DC motor, which made our robot arm motions a tad imprecise; we had to play around with PWM control and timing to ensure we could actuate our system with successfully.
-
For our purposes, this worked out okay, as our arm only needed to rotate a few times, and only to a few positions. If, for whatever reason, our robot had its responsibilities increase, we would need to purchase a stronger servo motor or add an encoder to our DC motor to minimise drift.
Extra & Takeaways
-
One of the big successes from our project was our planning. Our CAD model was precise, and allowed us to see how each of our different parts would interface with one another.
-
That said, planning only takes you so far. At some point, on the night before our project was due, our robot worked near perfectly; the arm could grab, our camera could scan, and the robot could drive. Over the course of a few hours after 9PM, however, everything started to go wrong... our motor, for whatever reason, blew up. The threads on the one flanged motor coupling we had access to wore off. And, to make matters worse, all of our electronic components began to fail: pins on our Pi stopped working, sometimes our H-Bridge would bug out, and our batteries were running out of juice. It seemed like everything was going wrong, and overcoming this took a lot of resilience (and caffeine).
-
For this, I must certainly thank my teammates, Kabir and Caden. We all worked on each of our robot's parts, but Kabir took lead on the claw and Caden did so with the code for the driving/scanning, while I covered the arm.