Our original design has been pared down from our first concept. Comparing it to the original idea, we have dropped the “tribble collector,” that collects and scores point with the pineapples. After discussing the idea as a team and experimenting for a few days with it, we came to the conclusion that since we had not made any design breakthroughs already, we needed to devote the rest of the time to the more reliable ideas that had a higher chance of success, such as our house collector and water handler. The other reason we dropped it was due to a shortage of space. The current point manipulation mechanisms took up too much space on our current chassis, and having to fit another such mechanism would have necessitated expansions that would have placed us out of the starting box, which is quite illegal.

Our additions to our design came after our team’s realization that navigation could be slightly complicated. Currently we do have a method for moving exact distances and making exact turns, but after testing on the board, the probability of success is not as high as we would like. Therefore we installed a pair of touch sensors on the back of both robots, to allow for our robots to line themselves up with the PVC piping, using it as simple, easy-to-use navigation. Once we tested our current code, we realized another failsafe was needed; thus, the touch sensors are used to accurately move about the board.

One of the issues that plagued us for quite some time was the arm to move the house shield down onto the captured houses. Our initial concept just had a simple lever attached to the small silver motor, to knock the arm over. However, this proved unreliable, as jarring movement of the robot (as in navigation) could knock the arm down. It also disallowed us from being able to pull the arm back up, should we need to. One of our team members came up with a very interesting idea: a worm gear. He used a normal wheel gear attached to the motor and a worm gear on the arm to move it up and down. This too, had an issue. The silver motor moved too quickly to make it effective; it broke the worm gear apparatus every time. We still had not yet realized the simplest solution: mount a different motor directly onto the hinge. It’s fairly simple, we just used a different motor with a more manageable speed, and directly linked it to the hinge.

Robot Testing

The testing regimen for both of our robots really revealed a great deal about the problems that we were having.

Our testing table has been constructed since the first day of the competition. Our sponsor, Bob Ekman, graciously went out and purchased the PVC parts that we needed to build it. It was built exactly to specification, with all of the item locations clearly marked, trying to create the most realistic testing environment possible.

As can be seen from the tables below, we ran tests of our House Collection robot both with and without tribbles, We were pretty confident about our robot without the tribbles, since our average score was quite close to 24 points, our expected total for that particular robot.

Here is a table of House Bot tests from May 5.

Without Tribbles        With Tribbles
Trial   Points          Trial   Points
1       24              1       24
2       24              2       24
3       15              3       10
4       24              4       24
5       16              5       3
6       15              6       16
7       24              7       8
8       24              8       16
9       0               9       8
10      24              10   8
Average 19              Average 14.1

Before this date, on April 29th, we used the Rockville Science Fair as a chance to test our robots vigorously and often. It helped to reveal many shortcomings of our robot, but due to the venue, we were not able to fix all of them at that time.

Our testing with the light sensor has been limited. Usually it's the simplest part of the design, and only a few more lines of code to add. On May 7th, we added the game clock functions to the code, and have it stopping and starting after the 90 seconds, regardless of functions. Our light sensor were also tested on May 7th. Our options for shielding the light sensor from surrounding light have been limited. The provided Lego pieces have not provided us with suffecient shielding from the various other light sources inthe rooms.

As our testing shows, we switched off our testing both with and without the tribbles included on the board. Should any of our sweeping mechanisms fail (leaving the tribbles on the board in the path of our robots) the robots will still be able to perform their tasks correctly. Also, due to our own issues with trying to move over the PVC pipings, we do not forsee any forays onto our side of the board, and thus have determined that time better used would be spent on getting our robots to work properly and efefctively.

Botball Lessons Learned

Through our Botball experience, Team 129 has learned how to assume roles to better act as a team, how to plan our project step by step, and, perhaps most importantly, how to work and cooperate with each other. When we first began to attend workshops, many members of the team were new at Botball robotics. We also came from schools scattered across the county; many of us would never had met at all had it not been for Botball.

Like any team, 129 realized collectively that for our robotics endeavor to succeed, we would have to form some kind of organizational system. We spent quite a bit of the first few meetings discussing our particular strengths and weaknesses, and talking about how each person would want to be involved in the team. After we had designated one person as a general leader, some people as programmers, and others as engineers, our team operated a lot more smoothly. A team functions best, when every member works not only at what they are best at, but what they enjoy doing. Team 129 understood this, one of the earliest lessons that we learned.

The next step, after we had organized ourselves, was to organize our project. We quickly found out that we could not proceed blindly ahead without forming a clear and distinct plan, one that would allow us to score the maximum amount of points, yet be flexible enough to accommodate any obstacles we might encounter. Our earliest plans were outlined on whiteboards and then transferred onto the computer. After a few sessions, we discovered one of the most important parts of any plans: compromise. Our sub-divided teams were so focused on their strategies that many people haven’t realized that Don Imus called Girls Basketball team ‘Nappy Headed Hos.’ That is right; we are so self centered, we have no idea what anyone else is doing, which in a way is restricting our ability to separate our good ideas from bad ones due to a lack of comparison.

We have resolved to solve this issue by having a general 10 minute meeting to discuss what everyone is doing and how they plan to do it. We also plan to make a table to distinguish high scoring ideas from low scoring ideas and hard to do ideas from easy to do ideas. This helped us rationalize the good from the bad and the easy from the difficult. We hence aimed to focus on the easy, high scoring ideas and ignore the hard to do, low scoring ideas. We need to assess difficulty and do a better analysis of scores in the future.

We also had problems with poor use of our testing table. Many people were found to be misusing the testing table as a building site or a food stand. This not only clutters the place where important scrutiny and development and recycling of ideas takes place but also leads people to become completely disorganized. We need to reserve the testing table for testing and quick repairs only.
We also desperately needed checklists at this point in the game! We had people working on robots that no one yet knew the purpose of, let alone how to operate them. A checklist is essential to ensure that if by some misfortune the leader of the robot is absent, someone else can replace and effectively operate the robot at the competition. Moreover, we have to make sure that tasks are comprehensible and easily comprehendible in a checklist format. We have seen the use of checklist save the day! We need to make sure in the future that this is squared away as quickly as possible, so that no one is left in a blind spot during the regionals.

Another dilemma that our team has faced is the apparent distortion of cooperation. It has been noted that one member of the team begins the code without commentary, then another attempts to continue writing the code with the absence of any direction hence resulting in a code that is off the task requirements. We must make it a point to comment on our codes no matter what! This way the goals and what the program actually does is not a mystery! Let’s not make this Jeopardy! We needed comments to ensure that anyone can understand exactly what was happening, without puzzling over it for an hour!

Moreover, it seems that with such a large group of individuals each divided into sub-groups, decisions and progress are hard to come by just like the legislative process is slow and painstaking. But this reaches extreme annoyance when 3/4 of the group decides that it is not necessary to attend the regular meetings. This has become a real issue. Although this is somewhat understandable since the AP exams are here and many people are under stress and pressure, those who just "wing it when they feel like it" should realize their commitment to this project. Because of this lack of cooperation, our team had to compensate for lost time and try to cramp hours of programming code and last minute building. We should learn from this mistake and make sure not to make it precedence for future teams. It is essential to work together to perform well and learn.

Another very important lesson learned was to delete the old versions of the software, especially if the icons look the same. You see, an interesting little incident occurred during one workshop. The problem occurred when the wrong version of IC was clicked because both icons were on the desktop right next to each other and one was randomly picked to open. So the wrong IC was open and some minor modifications were made to the code of the refining robot. Yet when we attempted to download the code, of course the libraries didn't match up. So the firmware was redownloaded, except that this just made things worse. Then the code was downloaded. Then we tried to run...Nothing worked except the motors. The servos didn't enable, the sensors didn't give input, it was scary - we thought we broke the XBC. So after many fruitless attempts at redownloading the libraries, redownloading the firmware, checking all the servo and sensory connections, we were just about to give up and tear the bot apart to replace the XBC. But as we closed IC and saw the wrong icon still highlighted on the desktop, it hit us all at once! It was absurd. We promptly deleted the wrong IC software and redownloaded the correct firmware and the code. If this had happened during competition...that would be tragic.

Our documentation process helped our team question the excruciating process that writers undergo when they are having road-blocks; in our case we found it extremely surprising that documenting progress is quite easy, when your team is making progress. Documenting went smoothly considering that we had minimal problems with our bots.

Moving House Bot (Bot 1)

Umbrellas –
(1) Our original concept was for a moving platform which would funnel the houses into a line in front of our robot. The umbrellas were originally designed to be passively placed into the houses by just having the bottom tips of the umbrellas.
(2) Once we found that this design did not work well or reliably, we decided to use a servo to drop the umbrellas into the houses. At first, the umbrella servo was designed to drop into the houses from above inline with the houses, but this design was not used because the XBC used to control our robot took up the space needed to mount the servo-umbrella-dropper inline with the houses.
(3) The second design then changed into its final form, where the umbrellas drop down from the left of the houses. The servo is mounted on the left rail used to align the houses.

Navigation –
(1) The initial design of House Bot included sonar designed to ping on one side of our robot. The sonar would have been used to ping the pipes to ensure that our robot would remain aligned with the PVC pipes that made up the game board.
(2) As of now, our default code does not use the sonar, but the sonar is on our robot to allow it to work together with another robot that is still under construction. In this instance, the sonar would be used to search for the houses because the other robot would most likely move them after picking up the pineapples and leaves.

Drive Train –
(1) In order to get the houses and not interfere with Water Bot, our robot was intended to back over the perpendicular pipe of the starting box. This required large, high friction wheels to climb the pipe. This design was limited because it either got stuck, flipped on its back or was severely disorientated after it went over the pipe.
(2) We scrapped the idea of climbing over the pipe but continued to use the large wheels because it allowed us to move slightly faster using our code. This alleviated the problems of finding a way to balance our robot because the pieces we used to keep the robot level before got stuck when we tried to climb over. We discovered that the axels our wheels were on were severely bent; the pineapples and leaves also got stuck in our wheels when we drove through them. We added wheels guards to keep the leaves and pineapples out of the wheels as well as adding structural support to keep the drive axels straight.


Water Bot (Bot 3)

Our final design is quite different from our original concept. First, we added an arm to block the volcano. This arm prevents most of the lava from coming onto our side and deflects the rest onto the opponent's side of the board. It is comprised of a servo sitting atop a tower and a latched arm that unfolds when the servo lifts it. Second, our robot now slips axels under the water and lifts them instead of using panel fairings to grab the water. We also added smaller upward pointing axels at the end of each long axel so that the water does not fall off when the arm lifts it up.

Our particularly elegant solutions to fiendishly difficult problems are large panel fairings over the back touch sensors, a tower that holds a servo exactly 11.999 inches above the board, and the XBC's ability to close the gameboy SP's screen via the arm that picks up the water. The large panel fairings or "wings" allow the back touch sensors to avoid the particularly nasty problem of pineapples and compost either stopping the touch sensors from triggering or causing the bot to align at an angle. This problem had larger ramifications such as the blocker missing the volcano, the bot flipping over, and the bot almost driving itself off the board. But now our bot has wings and the problem is solved. The servo in the tower solved the problem of being able to reach the volcano. Before mounting the servo in the tower, we were unable to fit an arm of the required length into the staring box. Now, our arm is almost half as long as it used to be and is thus easier to fit in the starting box. Last, we gave our bot the ability to shut its own SP screen. Before this was added, we always forgot to shut our SP's screen which resulted in being unable to pick up the water.

The Elements of Testing

To guarantee fantastic, crowd-pleasing performance, we ran the robots until the motor oil in our finger joints have dried. If 50 test runs was ambitious, completing them in less than two hours was an adrenaline drive. Each robot was tested individually and then together. The scores ranged from -7 to 43 points. The mean score was 33 points. The median score was 36 points.

We created quality testing by measuring precisely the dimensions of the board during construction two months ago. In the past, our teams have notice discrepancies between our team’s practice board and the fields used at the competition site, and each year we strive to eliminate that difference. Three team members separately measure the positions of the game pieces every Saturday. Obsession is our pride.

Another key element of the testing procedure is the starting lights. We have been testing with calibrated light start-up for two weeks; the process is second nature now. Calibration goes smoothly, light goes on smoothly, robot goes smoothly. We have let the robots run out the timer and they stop obediently at 89 seconds.

The House Robot (Bot 1) performs spectacularly. The strategy is simple, the design is simply, and KISS makes the scoring simple. The robot consistently starts with the light, veers slightly off a straight path at exactly the same spot, pushes the same three poms to its left, and scores 24 points by gathering and protecting all the houses.

The Water Robot (Bot 3) is always fun to watch. Since the strategy involves more variable qualities, the results are less consistent. The water does not always behave as we expect and the volcano – who knows. The Water Robot scores anywhere from 0 to 21 points and on average it brings in 17 points.

The robots together create a formidable team. We can see through the results that the strategy was obviously well-coordinated. The robots never have issues with occupying the same space at the same time, and the tasks are divided efficiently.

Just for kicks, we ran scrimmages against our other team (Team 129) to simulate the double-elimination rounds. Our bot usually beat their bot, but not always.

Last week, we had an exhibit at a local science fair. We demonstrated our bots many times during the day. This was a great stress test. We learned to run our bots quickley and made some small corrections to the structures.

We have been using the test results to compile a checklist for competition day.

The kept our test results in several Excel spreadsheets. We couldn't submit the files in this section so we submitted them as a separate file in the Project Plan section.

Lessons Learned from Botball

From the first meeting the Lockheed Martin Post 1010 explorer program worked together as a team. Once we obtained the kit we broke down into our team 130. From this point we got together 1, 2, and even 3 times a week. We learned to work together as a team by assigning tasks to each other. We felt comfortable enough with each other to speak our minds. We shared ideas, talked about them accepted or rejected them and then put them in into action. Our team evaluated our bots together and then modified them. The natural leaders on our team showed their resourcefulness. We all helped and contributed while completing required tasks in the documentation. Overall, our entire team learned how to work together.

The documentation process as a whole allowed our team to have a permanent record of our discoveries. Several times we went back to our documentation from the previous weeks and found useful information on ideas that we attempted. In the long term our team learned how to successful keep records of the projects we will work on in the future.

The most surprising thing that our team has learned from this botball experience is learning from testing robot which methods work for certain tasks. Not only did we learn that from the bots, but the more experienced members of our team shared advice of past failures and successes. We've also been pleasantly surprised by the creativity of our fellow group members. Challenges that seemed impossible to one were elegantly solved by other minds.

We've also realized the importance of efficient communication. If we couln't transmit our ideas, spat at each other's suggestions or ignored new ideas, we'd still be stuck with Lego pieces. Instead, because we took the effort to develop trust in each others' skills, we have two great robots.

The most practical advice for future teams is to start your robot as soon as possible. In past years, our former teams have started the robot late and many people ended up working for many days right before the competition. We started planning our robots as soon as we obtained the kit and we are in very good shape for the competition this coming week.