Reflection
Team 15: "Do It"

What worked:

  • Our initial strategy and concept was extremlely similar to our final robot. It was quite satisfying to have a completed robot with all the functionality we intended for it.
  • We were the 4th out of 16 teams to get checked off! After consenting on our design and strategy, we immediately got working and quickly built our functional robot.
  • Our final bumpers always triggered the bumpers on our robot as well as the lights on the arena
  • Our arm releasing mechanism consistently worked and our arms buffered our hits, keeping Mr. Roboto safe for scoring more points.
  • Our beacon sensor could immediately sense and react to a robot in any area in the opposing arena. Using a blinder improved our consistency considerably.
  • Our code was extremely organized and required no debugging after it was all written. We could very easily make various working state diagrams that could try out different game strategies.
  • We also included debugging code in each module, which saved us tremendous amounts of time in isolating our problems. With our code, we were able to quickly decide if our problems were mechanical or electronic.
  • We included LEDs on our circuit board to indicate how our inputs and outputs were working, which was a great decision for debugging our mechanical systems.
  • Our strategy was minimal, so it allowed for quick and efficient solutions that were often more mechanical than electronic or software.
  • Mr. Roboto was robustly and solidly built, so he and his components were left undamaged by the end of the experience.
  • Our mechanical design was effective in fighting off stray balls by having a low to the ground base.
What we would like to improve:
  • Though we did not realize it in the beginning, having two seemingly identical motors (same type) with different outputs was probably the worst setback for our team during this project. We thought we could correct for this difference by changing our software, and this worked well with some playing around with numbers. However, the day of the competition, one motor completely changed its behavior, leading to utter chaos with our previously working code! We quickly found that this was neither an electrical nor software issue, so we could not do anything right before the competition except hope that a few software changes could make up for these changes. We wasted a considerable amount of time on playing around with numbers to try to get our robot to just run straight.
  • We had never ending issues with spider couplers. In the future, we would find better spider couplers or even a replacement for using spider couplers in the first place. These were so unreliable for us that by the last week we could not run Mr. Roboto without tightening the spider couplers before each run!
  • In an effort to deal with stray balls, we built our base just a centimeter away from the arena floor. Though useful, this also turned out to be difficult for us. Our nuts often risked scratching the arena floor, which lead to some motor stalling. Next time, we would raise the base just a bit so that it prevented stray balls from reaching our wheels and also did not create unnecessary base friction.
  • We ought to have thought a bit more about our final arm release mechanism. We did not realize that our prototype mechanism would become a difficult to access and inefficient to set up final mechanism.
Tong Zhang | Agustin Ramirez | Nina Joshi

 
last updated 3.12.09