Our chosen design concept is similar to our initial design plans. Our robot used to collect the houses is largely unchanged, with some minor mechanical differences. It still collects the houses into a V-shape and uses the “house shields” to drag it back into the starting box. The detachability of the arm was compromised when we realized that it was interfering with the ability to move the houses around the board and back to the box. The other robot still operates on the instructions of collecting and depositing the water into the collection bins, but does so through a much-changed mechanical system from our initial write-up.

Mechanically, the house robot has been changed only slightly. Our method for lowering the house arm onto the houses has been modified to work with a worm gear attached to a motor. It allows more control and an easier time of “shielding” the houses. We use a specially written method that uses motor ticks to measure exact distances to navigate into position, then it uses a pair of touch sensors to line up to the PVC, ensuring a straight line in collecting the houses. It collects them and brings them backwards into the starting box, scoring 24 points.

This was decided upon based on input from the entire team, discussing the pros and cons. The real drawing point of this robot was its ability to score 24 points from some simple mechanisms, making it reliable. Having one robot score so many points is a great boon to our team, meaning we can concentrate on other robots to score more points.

Our other robot collects the water drops it into the collection bins. This design is completely different, especially for picking up the water. It is a claw capable of picking up both of the water balls at once, and reliably dropping it into the scoring bins for points. Mounted on the back of the robot, a tribble collector will sweep the board, after it has deposited the water and the house robot has returned successfully with the shielded houses, and pick up tribbles, dumping them into the collection bins when it is done. The mechanism to do so will use a pair of treads angled inwards, drawing the tribbles into a collection bin. We will then dump the tribbles into the scoring bins and score points per each tribble in the right bin. While this method is fairly random, and does not ensure any point scoring, we already have a reliable plan for 34 points, and the points we score from the tribbles can only be good for our score.

This design concept was eventually accepted due to our redesigned claw. We at first did not have a claw to use, but then that design was thought of and realized, so it became much more reliable. The water collection serves two purposes. It scores 10 points, and if any further lava falls into the bins, it will neutralize the lava, not subtracting us points. We agreed that the points from water will not only boost our score, but having the mobile robot allows for us to mount the tribble collection design onto the back of the water robot.

Lessons Learned from Simulation

We wrote test code into IC, then loaded up the simulator and ran it, determining how many points were scored. We tallied it into a table, and found out that we ended up often having issues scoring points. A high amount of the trials ended up scoring 0 points, due to a variety of problems. Remarkably few trials actually yielded a significant point spread, and only a single trial every scored the points our plan called for.

After getting these results, we paid closer attention to how the robots, and discovered a time when the robots interfered with each other, within the starting box; the house robot was entering with the water robot leaving too soon. We then worked out some navigation issues; our sensors were picking up incorrect items, and thus going in wrong directions.

The most helpful part of the simulation was that it allowed us to test our code for driving certain distances. We tested and debugged it through the simulator, until we could drive exact distances. This method will save us huge amounts of time, especially since it does not depend on battery strength, ensuring very accurate movements.

However, there were some simulations we did not use. The SolidWorks model program software was offered to us at the workshop. While we did try to learn the software, the time spent trying to learn and thus make the models of the robots would be much longer than actually trying to build the prototypes ourselves, making learning the software a wasted effort.

Lessons Learned from Prototype

The first prototype we attempted to build and eventually completed was the robot for collecting the houses. We took an initial house collection mechanism, integrated it into the robot and then began testing.

Our initial and current design for the house robot has only been modified slightly from our initial prototype. We originally had our arm that dropped the shields onto the houses detach from it after it had done its work of dragging the “shielded” houses back into the starting box. We figured that once the arm detached, the robot could go off and do other things. However, we could not yet figure out a way to keep the houses within the confines of the triangle without detaching the arm or throwing the houses out of the control of the robot. So the arm could no longer detach, and we used the house shields themselves to drag them along with the robot.

When we got to testing, and started to realize the robot had some more issues. We decided to try to have that particular robot move over the PVC piping, which warranted many changes to the undercarriage of the robot, in an attempt to make it over the piping of the starting box. As we got farther into the testing of this, we realized it was possible. However, the changes required to the robot to do such a thing would then interfere with its scoring capabilities, so we ended up returning it to the way it was.

Our next testing was centered on the other robot, and on the claw we would be using to pick up the water. Our first concept was a kind of scooping mechanism that would pick up the water, and then simply unload it into the collection bins. This idea was eventually scrapped, as we couldn’t get the scoop to reliably pick up the water. So we moved onto another idea, using a pair of claws mounted on the same arm. We even built this idea completely, but that idea was also scrapped because of stability problems. The weight of two servos and the arms was difficult to manage on a single controlling servo. Our next idea that so far has proved reliable and able to accomplish the task is a simple, long claw that manages to pick up both of water balls at the same time. It is lightweight, and our testing has proved its viability. So far in testing we have not seen the need to change any part of the design, as our testing has given us positive results.

Bot 1

We have chosen a design with two black motors geared directly to the wheels and a servo that holds/places the umbrellas. In addition, we have a funnel to force the houses into a straight line and hold them there when we put the umbrellas on them and then drive back to the starting box. We also have decided to use two large touch sensors on the back of the bot so we can align to the pipes. Because during various tests, pineapples and leaves have interfered with the touch sensors, we placed two flat panel fairings in front of the sensors. This way, even with interfering composts, our sensors will still trigger at the proper times. This bot should score a max of 24 points.

Bot 2

We decided to make robot 2 a stationary bot, but its construction is slower than the other 2 robots. This could be a very helpful design because there are very many ways to score points, since the house are located at a workable distance from the starting box. Using retractable arms, this robot will simple reach out and grab all the houses at once, thus it will have 3 arms and 3 corresponding servos. The exact details of the arms have just been worked out. The center arm will be a folding arm, since the distance to the center house is the shortest. The other two will be non-folding, but not entirely rigid. They will bend, and a rubber band on each will provide some folding capability upon extension. When those arms retract into an upward-pointing position, the weight of the house will cause the farther half to fold down, which will help bring all the houses in line with each other inside the starting box. After each house if pulled in, a white motor places umbrellas on each house. This bot should score a max of 24 points. We have not gotten to the point at which we test and evaluate the consistency and efficiency of this bot, although we have half completed it and have built some prototype arms.


Bot 3

We have chosen a design that utilizes two black motors to drive and steer. We also have decided on a servo to raise and lower the arm that picks up and then deposits the water. On this arm we have mounted a white motor to eject the water into the bins. We also use another servo and arm combination to block the volcano. This arm will be hinged and have a latch so that it can fit into the starting box. This bot will have two large touch sensors on the back so that it can align to pipes. The front of the bot will also have a large touch sensor so that the arm that picks up the water will rise at the right point. We are also planning on using an XBC with an SP game boy so that it does not interfere with the arm that picks up the water. This bot should score a max of 10 points, plus any lava that its arm can block and deflect to the other side.

Bot 4

We evaluated many different methods of sorting the leaves and pineapples and found sorting them mechanically difficult. Obviously this is the most important feature of the robot, as aforementioned in earlier reports, as of now. In considering possible mechanisms we evaluated some designs used last year by other teams to solve the 'tribble'-sorting problem, a problem that is very similar to this one. We have decided to have one clamp, powered by a white motor, remain at the height of a pineapple and grab and lift in into a bin, perhaps walled by paper. The leaves will be swept into a side bin be a ground servo arm. These will then be lowered/raised into the crop bins. In addition to this mechanism, a movement plan must be worked out to get all the piles.

Lessons Learned from Simulation

Simulation Lessons for Bot 1 & 3:

Our group read the instructions and attempted to enter our code into the robot simulator. However, we had difficulty executing the program. Our simulator failed to accurately depict the movements of our robot which we later tested in a game situation on the game board. Our results included a square which moved out of the starting box and froze. These unexpected results were probably due to the fact that the distance values weren’t coordinated in the simulator. For example, when we expected the robot to go forward 6 inches, it did not move a corresponding distance in the simulation run. In addition to this, we do not know how to set up the sensors in the simulator. Because all of our robots use touch sensors to properly align, it became nearly impossible to get accurate results from this simulator.

Simulation Lessons for Bot 2:

Two simulation tests were conducted on Robot 2. They both involved building part of the robot with Legos and substituting another part of the design with ordinary non-Lego parts. They are as follows:

The first simulation involved the determination of whether a folding arms was feasible, given the distance of the house from the starting box and the weight of the houses. The arms were first built with rubber bands designed to trigger expansion of the whole arm. To simulate the house, we attached a D-sized 1.5 volt battery at the end and used a motor attached to string to determine if the arm could pull it up. It turned out that it couldn't really, (which was kind of expected). The string broke frequently and the rubber wore out. It was particularly horrible for the left and right houses, which are at a considerably greater distance away.

The next simulation involved the weight distribution and center of gravity for the robot as a whole. We found that pulling up the houses (substituted as batteries) brought the robot close to tipping out of the box. We realized that using an XBC alone (although heavy) may not be enough, so we decided to have more weight fill in the robot, which would lower the center of gravity even more.

Simulation Lessons for Bot 4

No simulations have yet been done on this robot because it is still being conceived/built.

Lessons Learned from Prototype

Prototyping was not very hard to set up, so we tested concepts of the entire robot at once, broken down by robot:

All:
One key item we learned was that in programming, use of the motor() command and then waiting for a specified time was not very accurate. If the robot's battery levels were only slightly different, the robot would travel a different distance during a given time period, causing the robot to do different things based on the level of the batteries. Use of the mav() command in IC was better, but it still remained slightly inaccurate when one motor went faster than the other. Finally, a solution was reached using the mrp() command, which told the motor to move a specified number of revolutions forward, making the distance traveled the same each time regardless of the time taken. To compensate for differing motor speeds, a subroutine was created that drove each motor for the specified number of encoder counts. In this subroutine, a small unit of power was subtracted from the fast motor, causing the robot to run straight.

Bot 1:
This robot had major problems with driving straight, veering off to the left after a few inches of driving. To fix the problem, code was added to turn the robot slightly to the right during long runs down the board. However, this is a temporary solution and will eventually be removed as a good constant is found for equalizing motor power as described in the previous section. Aligning with the walls also helped, since code could be set up to turn the robot if only one side sensor was pressed down. Tribbles could get in the way of the sensor, blocking the switch and leaving the robot stuck at the wall with a sensor that would never activate. Instead of solving this mechanically, our team chose to add a time-out in the code, which assumed the robot was aligned to the wall after three straight seconds of backing up with no touch sensors pressed. The arm to place the umbrellas and funnel to collect the houses worked as expected. Consistency is still an issue, but this robot is well on its way. It can score the expected number of points, 24, during most of its runs.

Bot 2:
A few prototypes of this robot have been built, all of which are arm prototypes, because after all, it is the most important feature. These different prototypes represent different ways of retrieving the houses and placing umbrellas on them.
The first prototype involved a rubber band triggered arm that unfolded rapidly upon impact of the trigger against the side of the pipe (of the starting box). Upon release, it would fall with its own weight, hit the pipe, then unfold. A motor with string attached to it and the arm would reel the whole thing in, allowing it to fold itself up compactly. First of all, this prototype could not withstand the strain of a house's weight on the end, and it did not properly fold all the time. We first built this for the center arm, which is shortest. But the design was not feasible for the longer arms, simply because of the greater distance and the consequent increase in motor power needed. So this prototype was abandoned. The next prototype involved having the all the arms rigid, with no rubber bands. This theoretically would be easier to handle because we could use the stronger servo to lift the arms. When we built it, we found that a lot of torque (naturally) was required and it would be a strain on the servos, although they could still do it. Also, the arms resulted in an odd formation of houses brought back into the starting box that it was difficult to place umbrellas on them.
After that, we built yet another prototype, this time using more beams to aid in the folding process, with a servo to help extend and retract. This, we found, was much better than the former two because the forces to lift the weight were distributed in different angles and it was overall easier to lift. Also the arm happened to be rather compact when folded. However we couldn't quite use this prototype for the longer arms because folded version was not compact at all and rather difficult to extend. So we decided to only use that arm for the center, short arm.

Bot 3:
Unlike Bot 1, this robot had fewer navigation issues, requiring minimal adjustment to run straight. Tribbles were still a problem when the robot aligned with the pipes, but a mechanical guard was built over the sensor to deflect tribbles away from the switches. The biggest changes for this robot were in the manipulator system. First, the water manipulator was tested. From the beginning, we expected to pick up the water from above. However, this proved hard to build and we decided to push a scoop underneath and pick up the water. This scoop required a servo in the base to raise the arm up and down, but it did not require a grabber motor unlike the initial idea. Our first shovel design attempt was finicky, since it failed to hold onto the water after picking it up. A second design was tried, this time with a bent piece on the end to hold the water inside. Now there were problems with removing the water and putting it inside the bins. After a few failed tries to make a passive system for ejecting the water that would trigger when the robot impacted the cans, a white motor was placed on the end of the arm to push the water out when needed. In the code, this robot needed a loop to bring the water arm up in increments with a pause in between, so the water would not fly off the side of the board as the arm went up. A front touch sensor was also incorporated so the arm could be raised at the right point. But the biggest changes were yet to come when the volcano lava blocker was tested. We had anticipated the problem of the long arm fitting in the starting box, and placed a joint accordingly to allow the arm to bend inside the box. A servo was also incorporated to flip the blocker over the top of the robot and onto the volcano, However, when a rubber band was placed on the joint to pull it into position after the robot left home base, the joint was unable to resist the upward pressure of the volcano and bent, causing the blocker to fall off and lava to go everywhere. A latch was eventually designed to lock the arm into straight after leaving the box. The blocker itself was to be made out of paper, but our initial design used more than 36 square inches. After designing a new, smaller attachment, the robot failed to consistently hold the lava inside the volcano. Insight came one day when somebody bothered to measure and found the arm too tall for the starting box. The arm was promptly shortened to fit, but this had the unintended effect of allowing the arm servo to bring the arm farther forward. Thus, the latch worked much better and the arm did not move when the volcano was fired, causing more lava to fall on the opponent's side, sometimes even 12 pieces to one on a good run. Therefore, this robot was able to score more points than anticipated by causing the opponent to lose more points while helping to eliminate negative points for our team.

Bot 4:
Not many prototypes of this robot have been built yet, however we have built a small simple prototype of a mechanism to grab the pineapple off of the pile of leaves. It involves a clamp of two halves, one half rigid, the other powered and lowered by a white motor. Since the whole structure will remain at this one height above the board, it is an ideal solution to grab pineapples, which are conveniently placed above the leaves. When the clamp clamps onto the pineapple, another white motor will lift the whole thing up over the back of the robot and dump the pineapple in its bin, to be walled with paper.
We figure that the rest of the leaves will be swept aside with a servo arm into another bin. The difficulty lies in the attempt to raise and lower those bins to the crop bin heights and dump all of them out, without losing any.