Team Seventeen

From Maslab 2014
Jump to: navigation, search



Winter Guerra
Forest Tong
Vinay Mayar


This is our daily journal of progress, challenges, and other updates.

Week 1

We got a set of Kitbot parts! (Minus the battery.)
Vinay and Winter worked on assembling the Kitbot frame, having some difficulty finding appropriately sized screws and nuts.
Forest worked on assembling the wheels and motors.

The battery and a USB cable for connecting to the Maple arrived.
Forest connected most of the wiring between the motors, motor controllers, and Maple, and tied everything down.
Winter soldered the wires to the connecting pieces and to the motor. He uploaded the demo Kitbot code onto the Maple. Preliminary tests via serial commands from computer show that the electronics are working. We need to get the tablet part of the demo up and running.
Winter also tried to learn Solidworks. He is failing miserably slowly learning.
Forest and Vinay installed the software necessary to run the Kitbot from a laptop but didn't get it working on the tablet because of driver issues with the Maple.

Ariel gave a Power Electronics and Control Systems lecture. Apparently we will be using a PID controller, but the fastest way to get it working is just by fiddling with the three coefficients (proportional, then derivate, then integral).
Forest installed OpenCV on the tablet and tried but failed to configure it in Eclipse.
The tablet now works with the Maple.
Vinay installed Ubuntu on the tablet and the software for interfacing with the Maple. We can now run Kitbot using Ubuntu. The tablet is happy. Winter and Vinay thought about design ideas for collecting, storing, and depositing balls. We are thinking of using a wheel with a brush to scoop up balls to a higher platform, with some sort of switch to sort the balls, and maybe some internal color detection. Winter did a Solidworks checkoff and resoldered a new kitbot battery connector to the 'bot. Due to the new connector, we will no longer loose power to our robot while doing testing exercises. Winter also worked with Vinay on discussing possible plans for the mechanical version of the robot.
Our current conclusion is that we should aim to collect and deposit balls into the reactor silos at ground level first. Once we have a robot that can do that, we can expand the design to attempt some of the more complicated objectives. Yay K.I.S.S! (Keep it simple, stupid!)


There was a talk about how to generally use vision systems. Forest and Winter attended the lecture.
There was also a laser cutting training session. All of the team has now been trained to use the laser.

1/10 - Winter's Birthday!

We are falling behind on checkoffs. Although this was a ill-advised decision, 3/4 1/2 of our team is going on a ski trip for the weekend. However, Winter and Lucas are staying behind to continue working on the robot. In addition, Winter has been bogged down with 8.01L work. However, we were told by the staff that we can come in on Sunday to continue working. THERE IS STILL HOPE!


Nothing special happened. The lab was closed and half of the team was away.


The lab opened at 2PM today. Winter went to lab to try and get some preliminary designs done and lasercut before Monday.
The rest of the team returned from their ski vacation today and joined Winter in the lab. Together, we debated over various mechanical designs. Our current plan is to make a circular robot with a small ball intake in the front. Assuming that we will not have time to implement a mechanical ball sorter in the robot to filter out all the red balls, we want to make the vision system be our ball sorter. By having a small ball intake, we can presort the balls by only aiming for the green balls. It's not a perfect plan, but it's our best bet if we cannot get sorting finished in time.
For the elevation mechanism of the robot, we would like to make a belt and pulley driven mechanism.

1/13 - Monday! The day before our first mock competition!

Today is the day before the first mock competition. Damage report: no vision yet, encoders are not yet running, mechanical parts have not been fully designed. We are going to need to step it up today and tonight to get something working by tomorrow.

This morning, Winter started making CAD assemblies of the ball elevator. A prototype of the elevator needs to be finished tonight to pass checkoffs.


Winter does not remember what happened today. He thinks that he stayed at MASLAB for multiple hours while CADing the prototype design for the ball elevator. However, he can't be entirely sure. Then again, his memory is bad even when he gets the daily recommended does of sleep.

Pffft! Sleep!

1/15 - Wednesday
Vinay got the tablet to recognize ball-colored objects and export the required change in the robot's angular position to intercept the ball. However, we have not actually tried to implement this code into getting the robot to move and follow balls. Tomorrow, Vinay will try and code a PID controller using only P. This will allow him to start integrating his vision system into the robot's internal positioning system.

Winter has not slept in a few days. Hot off of an all-nighter triggered by a sadistic 8.01L pset, Winter decided that it would be a good idea to stay in MASLAB for 11 hours straight. Take this as a warning future roboticists, DO NOT BE THIS GUY!

On a more positive note, Winter finished prototyping V1 of the ball retrieval and elevation design. He laser cut and assembled the pieces to check that the design worked. In the process, however, he found some flaws in the design. However, the prototype still validates the general design of the ball elevator as being sane. By 2AM on Thursday, Winter had finished resolving 7 out of the 12 design issues that plagued the first prototype. He plans to lasercut V2 of the ball-elevation design by Thursday evening.

1/16 - Thursday

Forest worked on the robot controller -- getting the computer to control the robot's movement and query the robot's sensors, with the help of MaslabComm and the Maple firmware. He was held up for hours by unfortunate minor errors, most notably (1) the cytrons weren't connected to ground, (2) the motor-wheel connection was loose, (3) you can't set the motor speed to anything higher than 1 or it does nothing. Good news is the robot can now move on command and detect angular velocity, but the controller is still a piece of shit as the robot just drives in circles. Forest also swapped out the old motor with no encoder for a new motor with encoder.

1/17 - Friday

Winter was held up by classes and work for the whole day. However, he did manage to go to lab and finish the design for the 2nd prototype of the elevator. He generated new DXF files for laser cutting, but the lab closed before he was ready to lasercut. The lab will be closed on Saturday, but he will be back on Sunday to lasercut the second prototype.

1/19 - Sunday

Lab opened at 3PM today, but the laser cutters remained closed due to card access issues. None of the staff had card access to the laser cutters. Thus, Winter will stay here fleshing out the design until the shop manager arrives to open up the laser cutters.

1/22 - Wednesday

Winter and Vinay braved the cold to go to lab today. Since we fried our Maple a few days ago, Vinay started to work on porting all of the needed Maple firmware over to an Arduino. Thus, development can continue without waiting for new Maple boards.

Winter plugged himself into the grid and cranked out new sensor, battery, tablet, and electronic mounts for version 4 of the robot. Over 8 commits, he made 12 new parts to add to the robot. Here's a screengrab of the current design: V4 Screengrab.jpg Since Winter has class all day tomorrow, he's going to bed now (1:40AM).

1/23 - Thursday

We brainstormed ideas for the chute to deposit balls into the reactor. Forest glued the wheel screws in place and worked on calibrating the ball detection system. Vinay worked on debugging the software-firmware connection.

1/24 - Friday
Winter stayed up all night finishing the design for the chute, elevator, and base, assembling prototype 3, and putting electronics on the new prototype. Vinay and Forest tried desperately to get the arduino to communicate with a tablet/macbooks, but some bytes are still getting dropped. Vinay used a TTS library to make the robot talk about what it's doing.

1/27 - Monday
Forest hooked up the Cytrons to the arduino and tried to control the motors.

1/28 - Tuesday
Forest and Vinay worked with John Bowler to try to figure out why the Arduino connection was acting glitchy. In the end Vinay figured out that we simply were not waiting long enough for the Arduino to establish the USB connection. Then Forest and Vinay replaced the motors with new motors with encoders, along the way figuring out that the gear ratio of the motors affects how easy they are to turn. The robot now moves.


No assignments yet.

Final Paper


Initially, we planned to focus on ball collection and depositing in the high ports of reactors. We decided that the additional points to be gained from depositing balls in the low port were not worth the design challenge of having two mechanisms for depositing balls. Moreover, we decided to collect only green balls at the beginning of the game, before depositing, and red balls at the end. This would allow us to forgo a ball sorting mechanism and additional collection area.

Due to time constraints, we were unable to make our robot deposit balls. Instead, we tried to pick up as many balls as possible, of either color, and hold them in a collection tube. Our robot would bounce around off walls - detecting and avoiding them with short-range infrared sensors - and follow balls detected with vision. Upon getting stuck on something or oscillating back and forth in a corner, our robot would back up and turn away.


Our robot uses a mounted camera to detect red and green balls. It uses a belt-driven claw elevator to scoop balls from ground level to an elevated platform. The goal of this elevator was to deposit balls in the high port of reactors. We designed and built a platform at the top of the elevator to hold two to three balls and deposit them with a servo-powered gate. Before the final competition, we dismounted the servo and replaced the end of the chute with an enclosed tube leading down to the base of the robot, for ball storage. The claw on the elevator flings balls into this tube.

Software Architecture

Our software comprises five interacting java classes. RobotBrain contains setup and loop methods which initialize the game state using pre-set constants and continually sends commands to the Arduino. The loop method contains high-level strategy, including methods like goToLargestBall. The brain contains references to the other parts of the robot - the controller, eye, world, and mouth - and coordinates between them. The RobotController class uses an instance of MapleComm to send controls to the robot on every loop. It keeps track of current encoder and infrared information and past error in position and orientation. Using a PID controller and position and orientation targets set by RobotBrain, the sendControl method determines the motor speeds to send to the Arduino. The RobotEye class processes images from the webcam. Though it implements line detection as well as red and green circle detection, we use it only for circle detection. Using a series of filters - color filters, blurring, hough circle transform - the process method returns an accurate list of detected red and green balls. To avoid lags in updating strategy and sending control signals, the eye runs continuously in a thread separate from the brain. Upon receiving new data from the eye, the brain updates an instance of RobotWorld, which forms the model. Though RobotWorld only keeps track of balls, it communicates with BotClient to receive and store the map. We hoped to use the map to create a grid of occupied and unoccupied squares and use long-range infrared sensors for localization within the playing field, but were unable to complete it in time. RobotWorld contains methods visible to the brain for determining ball positions. There were also a number of struct-like classes used for storing and sharing data - SensorData, Error, Ball, EyeData, etc. Finally, RobotMouth uses a TTS library to dictate the robot's current strategy.

The Arduino runs a modified version of the Maple firmware provided by the staff.

Things We Learned

We learned how to build a robot! None of us had experience building robots before MASLAB. Each piece of electronics was new to (most of) us, and simply being able to get information out of the sensors and to control the motors was a learning experience. We also learned a lot about mechanical design and how to fit parts together. Winter learned SolidWorks from scratch. We all learned how to use a laser cutter and became more familiar with the basic tools used to build robots.

Lessons, Advice, Regrets

  • Electronics are easy to break.
  • Voltages should always be checked before turning power on.
  • 5V != 16V
  • 16V != ground
  • Wiring should be clean and color-coded, and long wires should be avoided.
  • Building a prototype as early as possible would have gone a long way - there are always little mechanical problems that require you to reprint.
  • Avoid complex design choices - choose the simplest option.


Thanks to the MASLAB staff for all the work they put in to make this competition happen, and for their patience when we broke stuff, fell behind, and generally messed up. They were always ready to help - from walking us through how to use parts to debugging code and wiring. Thanks to David for helping us build two of our prototypes and for lending us your Arduino - we probably would have fallen even further behind without your help. Thanks to the sponsors for letting us build a robot for free! We wouldn't have been able to build a robot without all the parts paid for by sponsors. Lastly thanks to Charles Guan for letting us use the lab. It was a great place to work and we contributed to its utter destruction.

Personal tools