Team Ten/Final Paper

From Maslab 2015
Jump to: navigation, search

Contents

Strategy

We didn’t want to bother with the problem of sorting blocks. Throughout our initial design process, we couldn’t think of a fast, easy, and reliable way to sort blocks after picking them up indiscriminately. As a result, we decided to leave the sorting of color as a function to be handled before the block was even approached by the robot (through computer vision!), and focus on collecting and stacking with a presumed color.

Hardware

• Collection: the goal was to have 3D-printed rollers actuated via a motor that were all connected via a gear train so that torque could be accelerated (with a slight difference between the torque on each side as to prevent jamming)

• Stacking: set of pins that sat on a carriage driven by a leadscrew. When a block came in, a servo would then actuate the pins to come out and rest within the hole of the block. When it was time to lift the block stack, the leadscrew would drive the carriage with the pins, which would then push all of the blocks up. The stack was then guided by an acrylic cage that would serve to constrain problematic motion.

• Depositing: With a stack already created within the structure of the robot, all that needed to happen was to open the cage. To accomplish this, we had the cage rest on two slabs that sat slightly above the base of the robot with gear teeth cut into them. Via a servo actuating said teeth, we could achieve enough motion of the slabs to open up the cage and have the robot back away from the stack it had created.

Sensors

gyro for driving, IR for wall following, camera for sensing blocks and walls

Software

• Software design was divided based on different levels of functionality for the robot. Lower level interface interactions between the Edison and the onboard Arduino were handled in C++; the use of JNI (Java Native Interface) allowed for these methods to be made available in Java, which was used for the vast majority of the code. The mraa library for the Intel Edision was used to control, read, and write values to and from the motors, servos, and IR sensors. For the camera, an ImageUtil class--along with other helper classes and native methods--was developed. Images were read in from the camera, resized, and color filtered through direct operations on the image data; use of the OpenCV library was kept to a minimum (an important note on the camera used: the Logitech c110 was, in the words of Ariel, “not meant for use by humans,” and had ridiculous buffer time when trying to run on the Edison. PID controllers were also coded for, and a thread for constant updating of heading based on gyroscope readings was used as needed. The solution is to have your camera grab several frames first (5 or so should do), and then retrieve the most recent frame). A single Main method used classes from the various packages to thread and control the states of the robot, based on inputs from the camera (aka THE BEST SENSOR YOU HAVE).

Lessons Learned

• There is no such thing as too early

• There is NO SUCH THING as too early: we had the basic concept for our design done a few days into the competition, but it took a while to bring to fruition. Do not underestimate the time it takes to work through the details of things. Also do not underestimate the time it takes to troubleshoot.

• Simplicity is key (and it isn’t always what you think it is): we liked our idea for a leadscrew a lot, but in retrospect, it wasn’t particularly simple (especially when it came to the details). We also didn’t take into account the amount of manual machine we’d have to do as a result (which is much more intensive than any laser cutting or water jetting). If you have a complicated/highly detailed mechanism, either get something you know will work or don’t do it.

• Build early, build often: we tried to circumvent this through doing a lot of CAD and we still had lots of things that needed to be rebuilt. Don’t bother trying to solve things in CAD. It really isn’t the most efficient way to re-design.

• Alternative shops are great, especially ones with 24-hour access. We had access to the CSAIL machine shop and it was a godsend. Additional access to 24-hour machine shops would have been greatly helpful at multiple points during the competition.

• Hardware and software should (kind of) know what the other is doing: it gets harder to communicate if no one can understand the other… it just makes things easier.

Personal tools