Halston

aka Team 4

"Is something burning?"
"Gearmotors - class A counterweights."
"Have you tried turning it off and back on again?"
"Enter win mode."
"Tease mode activated."

Team Members:

• Arinze Okeke - Biological engineering (Course 20) junior minoring in Japanese and Chemistry. Hoping to learn a bunch and have fun. Long and triple jumping with the MIT varsity track and field team.
• Scott Heng - Chemical engineering (Course 10) senior. Was part of first robotics during high school.
• Katherine Prutz - Electrical engineering and computer science (Course 6-2) sophomore. High jumping and getting real big real quick with the MIT varsity track and field team.
• Milo Knowles - Aeronautics and astronautics (Course 16) freshman. High jumping with the MIT varsity track and field team.
• Audrey Pillsbury - Chemical Engineering? ( Course 10?) freshman. Throwing various heavy objects with the MIT varsity track and field team.

Checkpoints we actually followed

Week 1

• Get code working with all sensors and motors
• CAD and build the elevator

Week 2

• Get robot driving in a straight line
• Write initial program
• CAD more pieces
• Get robot to drive in a square

Week 3

• CAD even moar pieces
• Work on sorting mechanism
• Write opencv code to locate blocks and their distance/angle away from us

Mock Competition (Monday of last week)

• Scrap the sorting mechanism, glue a box to the back of the robot to toss the cubes into from the elevator

Week 4

• Complete sorting mechanism and code
• Add wall avoiding
• Add counterweights to robot, since competition map will have bumps in the field's floor

Final Notes and Tips:

Keep teensy/microontroller firware up to date always!!!!

Write code incrementally, debugging as you go

Make sure to understand the way the code will be running between the tablet and the teensy: the teensy gets updates every timestep, so it's not actually following the code continuously. That means no while loops in the code other than the main loop(), must keep track of state and place in code always!

All Meeting Notes:

1/4/16 Scott and Arinze were trained to use the machines in the FABLab We reviewed what was talked about in lecture which was tips and common pitfalls. We then brainstormed possible strategies we could use for scoring points during a competition because these may affect what we build. We started planning how we would pick up blocks and sort them after reviewing videos from last year for starting points.2015 MASLAB final compeition here -> https://www.youtube.com/watch?v=UtwgEHx-Gss We narrowed our list down to four possible strategies. Parts from each can be combined to form new strategies.

1. Knock down all stacks
   • very easy and quick points
   • if other teams’ robots don’t move at all then easy win
   • won’t work against more advanced teams
2. Pick up all the blocks, without sorting (We won the mock competition held the monday of the fourth week with this strategy)
   • points for possession of our blocks would be better than points for having them on the floor
3. Stack opponents blocks on center platform
   • even if we can’t stack on center platform, placing them there would be worth a good number of points (2.5pts for each of theirs on the platform unstacked vs 1pt for each of ours on the ground unstacked)
   • may take a bit of time collecting specifically the opponents blocks and finding the center platform
4. Stack our blocks on the ground (We moved onto this strategy after the mock competition)
   • standard method
   • easier than trying to place on a platform

We agreed that it would probably be easiest to have some sort of chute or tube that stacks the blocks inside it (See competition starting at 2:37:00). To do this, we would need to lift the block to the top of the robot somehow. There were variations on some common themes.

• some sort of elevator to lift the block with a platform or with spokes (we chose this) making a conveyer belt
• using an arm to grab individual blocks and pick them up (other teams did this successfully)

For block sorting, we thought that the fllipper on top of the “janky” robot was simple and effective (See the robots at ~2:37:00)

1/5/16 Lecture discussed mechanical components of MASLAB. Scott was out of town, but everyone else was able to attend the lecture. We got our parts and worked on trying to get the motor running and the teensy hooked up. Arinze and Milo looked a bit at Solidworks. There wasn’t time to get the frame for the kit bot laser cut so we will do this tomorrow and start assembling the kitbot. Milo may have figured out how to get the motor running and how to control its speed and direction. He took the parts home with him and will test it out tonight. The wiki was set up. A google doc was started for people to start putting ideas for team names. We will meet later to choose one. There is another safety training tomorrow at 1pm and a 3D printer training at 2pm. Audrey, Katherine, and Milo will do both safety trainings, and Arinze will do the 3D printer training also. Katherine is doing a UPOP next week and will be busy from 9 to 5 every day so we will need to be able to work independent of her by then. Scott should be back by then. We should aim to have CAD for most of the robot done by the end of this weekend.

1/6/16 We printed out the kit bot and started putting it together. We also worked on getting the wheels moving. We figured out that the teensy wasn’t making good connection so we had to solder some parts so we could control the wheels through the program. We decided to build our robot around the kitbot, and we liked the idea of having a chute in the front elevated for the opponents blocks and a chute in the front touching the ground for ours. We thought we could maybe use a slide to get it from the front to the back.

1/7/16 The teensy was soldered to the breakout board with male pins. There were no correctly sized allen wrenches so we could not properly attach the wheels. We chose a way to lift the block and started CADing parts. We also decided that a rotating center might be more possible than creating a slide. We compiled a list of parts we may need ordered.

1/8/16 We met with the MASLAB staff and they tore apart our idea. Luckily we were able to quickly figure out a potential alternate. Milo made a prototype conveyer belt with zip ties that seems to pick up blocks pretty well even when vertical. We ordered a belt so we could make the part. We also did some work on creating something that would be able to draw in a block and position it correctly for being picked up by the conveyer belt.

1/9/16 There was a track meet so no work was done.

1/10/16 Milo did a lot of CADing for the elevator that lifts the blocks. We ordered brackets so we can mount the yellow pololu motors for the block positioners. We were having a lot of problems connecting the teensy to computers. We finally got it working for Scott’s anaconda python and Arinze’s IDLE. Arinze learned how to read the code and manipulate it and took most of the electrical parts home to try to get the Teensy connected to the tablet so we could run code from the tablet.

1/11/16 Tej helped us a lot with getting the Teensy to work properly because the tablet was not sensing the serial connection. We safely hooked up the battery and fuse and played around with the gyro and encoder sensors. We were able to get both wheels moving and the robot to drive. The robot drove out of control though. Milo worked on laser cutting the pieces we CADed for the elevator and I 3D printed the round pieces. Milo and Arinze went over the notes for the lecture on using the encoder and gyro to drive in a straight line and planned out how we would write the code for it. Arinze made some code later that night to be tested tomorrow. Milo also started to take a look at the webcam and how we could capture images with it. Plans for tomorrow: printing the axel for the elevator print more precise spacers for the wheels CAD and laser cut the chutes for the blocks finalize positions of the electrical components figure out the DC step down voltage converter and set one up for 6V, 5V, and 3.3V create a wiring convention decide on a team name cad the parts for the block positioners and decide how the wheels for it will be mounted get the robot driving in a near straight line.

1/12/16 Code was written and tested to make the robot drive straight. We were having a lot of problems because the robot was just veering off to the left even though the gyroscope knew it was wrong. The problem was the way the code was implemented. We later found that packets were only sent to the teensy once the loop function finished. After readjusting the code, the robot was able to change its angle based on the gyroscope. However the robot would over correct and then over correct the other way even more leading to crazy spinning.

1/13/16 After more testing and studying the lecture notes we were able to fix the overcorrecting problem by setting bias to a constant number. We wrote code to make it go in a square in preparation for friday except while turning the 90 degrees it would overshoot and not have enough time to correct before the next turn so it would eventually lead to the robot’s square moving. We considered setting the bias to 0 while spinning large angles.

1/14/16 We did some rough prototyping and planning for the block positioner. Milo and Arinze were laser cutting trained. A TON of CADing was done and pieces were laser cut by Erin that evening and given to Scott because everyone else had to leave for track. Assembly took place in the evening. Some pieces were cut incorrectly because we sent the wrong file. And some pieces were missing because some files were not left with Scott, so pieces were recut that evening. A bunch of assembling was done.

1/15/16 We planned where sensors would be placed and hooked up the wheels to show the staff that our robot could drive in a square. Not much was done that evening because all of the team had a very long track meet the next day or was planning to travel and needed to rest.

1/16/16 Track meet: no work done.

1/17/16 We worked on getting the elevator belt and block positioner motors connected so we could test out the mechanism for picking up blocks. We were able to write a code to have the robot drive straight and pick up blocks along the way if it was in front of it. We looked into opencv and worked on color detection for finding blocks.

1/18/16 We were having a lot of trouble with the gyroscope. The gyroscope was drifting a lot. We could not fix this problem. We had to wait until tuesday because today was a holiday. We were able to get opencv installed on the tablet.

1/19/16 We did more looking into color detection and object identification. We found that we could start with a black window and fill in where the desired colors are and then put contours around the blocks. We can then select the largest contour and assume it is the closest block and go after it. We also tested the color sensors and distance sensors. Code was written that tells the robot to spin until it finds a block. Then when it finds a block, center it in the webcam and drive forward. It needs to be tested tomorrow. If that is successful, we can then work on our wall following algorithm. Tomorrow we can hopefully also mount the sensors and camera and cad the mechanism for block sorting.

1/20/16 After analyzing the space we had at the top of our robot, Arinze and Milo designed a cardboard prototype for block sorting which featured two slides for our main stacking chutes. However, we did not come up with a way to collect the block and deposit it into the correct slide. We decided that moving the chute for the opponent blocks to the back of our robot wouldn’t interfere with us finding the center platform and depositing the blocks.

1/21/16 Today was the first day our robot was able to identify and move toward blocks!

1/22/16 The color sensor code was updated so it now works. However, the RGB values need to be normalized or correlated to red or green as we will use it to sort our blocks. Arinze also calculated an equation to determine distance for the short range IR sensor that we will use to detect walls.

1/23/16 Track meet from 8am to 12pm. no work done.

1/24/16 Spent all day trying to code debug the scan while spinning in a circle state and collect blocks code using the distance and angle calculator Milo made. It uses the area of the block to determine distance and the height of the block (in pixels) to determine angle. We eventually got it to work. Milo worked on CADing the structure for sorting.

1/25/16 MOCK COMPETITION We tried to get wall following working and the sorting structure done. Neither were working. The mock competition was that night... We couldn’t get the bot wall following or sorting so we just slapped a box on top and collected blocks using the spin and collect. The robot had many problems. There was no time out so it kept driving into the wall when it got stuck. There was also a case where the robot saw some blocks over the center divider and tried to go get them. Nevertheless, we won the competition! After the mock competition, we planned out the block sorting and threw out the idea of using the center platform.

1/26/16 We worked all day on remodelling the code so it uses a state machine and is more modular. Katherine split up the files and we tried to make things work but they didn’t. Working in parallel Milo and Scott worked on the sorting mechanism. We went through several prototypes and nothing worked. After track we came back and finally figured it out using a bunch of hand-band-sawed parts and tape and cardboard. We still need to get the servo for sorting set up and mount the color sensor. We blew the stepdown converter because we were using it to power both pololu motors for the block positioners and the elevator dc motor. We had to make a new stepdown converter and move the dc motor for the elevator to the battery voltage. Now the belt moves faster so we need to adjust the belt speed in the code.

1/27/16 Blew up the teensy. Whoops. Luckily there were spares and we got a lot of work done on the sorting mechanism before that.

1/28/16 Teensy is back up and running. Got the easy to understand and ready for change new code debugged - implements a state machine. Change wall following to be more of a wall avoiding using IR sensors on the left, right, and front of the robot. We’ll only go into wall bouncing state if there are no blocks around, so if a block is against a wall then we’ll still be able to go after it. Robot is spinning wildly in the wall avoiding test runs... We also added three motors to the front of the robot - not plugged in or anything. We just needed a counterweight. Gearmotors = class A counterweights.

1/29/16 FINAL COMPETITION