FUBAR

One problematic issue that we came upon early in the design process was that we needed a consistent way to collect and align the hackers and students so that they could later be sorted easily. Understanding the limitations of the driving accuracy of lego robots, we knew that the collection mechanism would have to allow for a large amount of error. So we designed a one-way “gate,” which would allow blocks to enter the robot, but not leave. This gate consisted of a row of spinning gears, which would raise when blocks approached from the outside, but would push away blocks trying to leave the inside.

Once we had the blocks inside of our robot, we then needed a way to arrange them neatly into a line to be sorted. We decided to simply have the sides inside the robot to slope into one hole the approximate size of a block, so that only one could be fed through at a time. In order to prevent blocks from getting jammed near the hole, we also installed a belt on the left side that would push any blocks touching it away from the hole. This alone would mean that only blocks on the left side would make it to the sorting mechanism. So we also had our robot make only left turns, which would “move” the blocks (actually, the blocks aren’t moving, the robot is!) to the left side.

After the blocks were fed through the hole, they would be pulled along by two wheels on each the left and right sides of the blocks. However, the blocks needed to completely leave this feeding mechanism for the sorting process, and unfortunately the wheels alone would not push the block completely out. So another set of smaller wheels was placed after the first set that was this time above the block (a horizontal axis rather than vertical ones as before). This would allow the block to freely move horizontally to be sorted.

The sorter needed to first detect the presence of a block, then decided its color, and finally perform a different action depending on that color. The presence of a block was tested from simply by using a LED and light sensor as a break-beam. By placing it diagonally across the sorter, the presence of a block would prevent the LED light from reaching the sensor. This would activate a color sensor (another set of LED and light sensor), which would read the color of the block.

The mechanical, moving part of the sorter consists of a giant “windmill”- a rotating set of four arms connected to a motor. When the block is pushed into the sorter, two of the arms of the windmill act as sides while the color is being checked. If the block is a hacker (black), the windmill rotates clockwise, pushing the block into a bin on the left. If it is a student (white), the windmill rotates counterclockwise, pushing the block out of the robot.

Unfortunately, the size restrictions on the robot did not allow enough room for a fixed bin to be attached. Instead, the bin was attached to a servo and placed so that it is initially vertical, rotating down when the round starts. This allowed not only a way to construct a larger bin, but also gave an easy method of releasing the hackers into our jail- simply lift the bin. Rather than building the bin behind the robot, we decided to build it sticking out of the left side. Since the robot would make only left turns, the bin would never get too close to the wall.

Due to delays in receiving the controller board, we did not have enough time to fully debug the code and mechanical design of our robot. The most notable bug was in its turning mechanism- it would not always turn 90 degrees as programmed. In order to try to compensate for the errors in the programming, we modified the strategy of the robot. Rather than collecting and sorting all of the blocks on our campus, our robot would first move the two known hackers into our jail, and then proceed to collect and sort the remaining ones on our campus.

We survived several round to come in 3rd place.