Team Six/Final Paper

From Maslab 2011

(Difference between revisions)
Jump to: navigation, search
(Suggestions for future teams)
(Conclusions)
Line 29: Line 29:
==Conclusions==
==Conclusions==
 +
 +
Our team came in with the purpose of
 +
 +
 +
This worked out really well in all but one instance and that was with respect to our code. The roles that we intended to have were split into two groups, building and coding. Our two strongest coders would write and handle the code and everyone else got to build. What developed was a complex hierarchy of task management where I did most of the building after discussing the design with Shawn and Wings would keep us on track by not only updating our list of things we planned to do and checking that we had done them but also writing our journal entries and eventually contributing heavily to the final paper Wings and Shawn would also solder and construct other parts that would be used to build the robot. This system worked great for the part of the team that used it. We would talk to each other, sanity check all of our ideas, and even propose alternative ideas of varying quality so that we could come to an agreement on what a good solution would be. This did not happen for our code and that was our downfall. Before I potentially offend Michael it should be noted that he was perfectly competent, friendly, and wrote a lot of time consuming code, all the while looking for more ways in which he could help the team. There was simply a disconnect between communicating how the code acted and what the code needed. The rest of the tea was always aware of what code had been written, such as the state machine or the vision processing code. What we did not know is how it intended to handle the information that it got. This made Michael too important to the team and the only member of the team that if the team lost the others would not be able to function productively and when he got sick during the final week of IAP it brought our progress to zero until he felt well enough to write more code (which he proceeded to do for > 24 of the next 32 hours.) During this time we finally got a chance to really debug the code for the first time and a large percentage of the issues we were dealing with could have been dealt with previously if we had been having productive conversations about the cod and also if Michael had some for of physical thing he could have used to test with. Overall I am glad that we got through maslab together, we would most certainly do better if we knew what we now know, and I hope that if you skipped to the end you take the time to have more than a single person who understands and can work on the code.
==Suggestions for future teams==
==Suggestions for future teams==
Build early, build often, and allot more time for this than you think you need!  Our main problem was that we were all very new to building, and things tended to go wrong often.  You never know when the laser cutter will stop working, you'll probably have to remachine parts several times over, you will find ''tons'' wrong with your robot that you didn't even think about.  Building early means that you can make more mistakes, and don't have to be afraid of them.  Having a physical robot is ''very'' useful to debugging, so having that early for your coders is incredibly useful
Build early, build often, and allot more time for this than you think you need!  Our main problem was that we were all very new to building, and things tended to go wrong often.  You never know when the laser cutter will stop working, you'll probably have to remachine parts several times over, you will find ''tons'' wrong with your robot that you didn't even think about.  Building early means that you can make more mistakes, and don't have to be afraid of them.  Having a physical robot is ''very'' useful to debugging, so having that early for your coders is incredibly useful

Revision as of 04:21, 28 January 2011

Contents


Overall Strategy

Our initial overall strategy was as follows:

Robot algorithm: The algorithm runs as long as the timer is noted less than 3 minutes (180 seconds). The first ball seen will have its color noted and be saved in a variable called our_color. As soon as this is established, search the map for goals, the goals are determined as follows: if a yellow wall is seen, drive up to it and use the ir sensor to determine whether or not the depth of the wall varies along its length. If the wall does vary, save the location of the goal in a list called goals_loc[]. When the number of goals is greater than 2 (or if more than 30 seconds have elapsed), then begin to look for balls. Whenever a ball is found, look for the nearest goal and transfer the ball to that goal. Do this as long as the timer has not gone over 2 minutes. After two minutes, whenever a ball is found, if the distance between the ball and the nearest known wall to the opponents side is less than the distance to the nearest known goal, then save the distance and calculate a random number between 0 and 1 and save it to rand_n. Should rand_n > e ^ -(d_togoal-d_towall), throw the ball over the wall, else, throw the ball into the goal. Stop after 3 minutes.

Robot strategy: We decided that we are stronger on the course 6 side of the spectrum than the course 2 side of the spectrum. We're going to keep our robot design relatively simple, with a conveyor belt and accompanying pinball-machine-like doors to pull balls into the robot and drop them into a compartment. On the side, we will have a door that opens when told so that we can drop all our balls into the goal. We decided not to drop balls onto the other side in order to keep our robot simple so that we can focus on our code.

Time-allotment strategy:

   * Michael - Since Maslab is his main IAP commitment, he'll code in the evenings and possibly during the day.
   * Shawn - Work until 4pm every day, code at night with Michael.
   * Piper - Work on building between lecture (or late mornings when lecture isn't happening) and 7pm daily.
   * Xavier - Work on building between lecture (or late mornings when lecture isn't happening) and 7pm daily. 


Mechanical Design and Sensors

We came to realize that our original robot design was problematic. The conveyor belt roller would have to be very small so that the ball would be pulled up it rather than pulled away, and the doors pushing the ball onto the roller would have to be well synchronized. We decided to start from scratch, and came up with something we believe will work much better. Our new design was not only easier to build and more predictably function, but it also allowed us to score over the wall.

We have a scoop with a slanted arm leading down, lined with teeth to scoop up a ball when the robot drives into the ball. Two motors will raise the scoop so that the ball rolls back into our collection box. We had some issues with not having enough torque before, so we added long metal bars sticking out from our scoop to provide us with the leverage needed to raise it. Under our collection box, we'll keep our motor, orc board, and computer. The collection box itself will be slanted towards an escape hatch in the back. This hatch was initially designed to be a drawbridge, but this design became harder when we decided to use a servo to open and close it, so it is just a slate of metal. Since the escape hatch is over the wall, our balls will be able to fall into the other team's field. We will do this with all our balls instead of scoring in goals.

We have two bump sensors at the back of our robot (that is, where the escape hatch is, not the side with the scoop and teeth). This way, when our robot backs up, it will be able to detect when it hits the wall. Our camera faces front, through our scoop (which is composed of plexiglass). On each side, we have two IR sensors that are used to detect the robot's angle to the wall.

Software Design

Overall Performance

Conclusions

Our team came in with the purpose of


This worked out really well in all but one instance and that was with respect to our code. The roles that we intended to have were split into two groups, building and coding. Our two strongest coders would write and handle the code and everyone else got to build. What developed was a complex hierarchy of task management where I did most of the building after discussing the design with Shawn and Wings would keep us on track by not only updating our list of things we planned to do and checking that we had done them but also writing our journal entries and eventually contributing heavily to the final paper Wings and Shawn would also solder and construct other parts that would be used to build the robot. This system worked great for the part of the team that used it. We would talk to each other, sanity check all of our ideas, and even propose alternative ideas of varying quality so that we could come to an agreement on what a good solution would be. This did not happen for our code and that was our downfall. Before I potentially offend Michael it should be noted that he was perfectly competent, friendly, and wrote a lot of time consuming code, all the while looking for more ways in which he could help the team. There was simply a disconnect between communicating how the code acted and what the code needed. The rest of the tea was always aware of what code had been written, such as the state machine or the vision processing code. What we did not know is how it intended to handle the information that it got. This made Michael too important to the team and the only member of the team that if the team lost the others would not be able to function productively and when he got sick during the final week of IAP it brought our progress to zero until he felt well enough to write more code (which he proceeded to do for > 24 of the next 32 hours.) During this time we finally got a chance to really debug the code for the first time and a large percentage of the issues we were dealing with could have been dealt with previously if we had been having productive conversations about the cod and also if Michael had some for of physical thing he could have used to test with. Overall I am glad that we got through maslab together, we would most certainly do better if we knew what we now know, and I hope that if you skipped to the end you take the time to have more than a single person who understands and can work on the code.

Suggestions for future teams

Build early, build often, and allot more time for this than you think you need! Our main problem was that we were all very new to building, and things tended to go wrong often. You never know when the laser cutter will stop working, you'll probably have to remachine parts several times over, you will find tons wrong with your robot that you didn't even think about. Building early means that you can make more mistakes, and don't have to be afraid of them. Having a physical robot is very useful to debugging, so having that early for your coders is incredibly useful

Personal tools