https://maslab.mit.edu/2011/w/index.php?title=Special:Contributions/Emolague&feed=atom&limit=50&target=Emolague&year=&month=Maslab 2011 - User contributions [en]2024-03-29T15:28:06ZFrom Maslab 2011MediaWiki 1.16.0https://maslab.mit.edu/2011/wiki/Team_Six/Final_PaperTeam Six/Final Paper2011-01-29T16:44:46Z<p>Emolague: /* Software Design */</p>
<hr />
<div>__TOC__<br />
<br />
==Overall Strategy==<br />
<br />
Our initial overall strategy was as follows:<br />
<br />
'''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.<br />
<br />
'''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.<br />
<br />
'''Time-allotment strategy''': <br />
* Michael - Since Maslab is his main IAP commitment, he'll code in the evenings and possibly during the day.<br />
* Shawn - Work until 4pm every day, code at night with Michael.<br />
* Piper - Work on building between lecture (or late mornings when lecture isn't happening) and 7pm daily.<br />
* Xavier - Work on building between lecture (or late mornings when lecture isn't happening) and 7pm daily. <br />
<br />
<br />
==Mechanical Design and Sensors==<br />
<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
==Software Design==<br />
In general, our software was fairly simplistic. The software consisted primarily of two threads, one carrying out the process of image-processing, and the other carrying out the actual motion of the robot. Apart from both threads was a class (public class Commander) which contained code to actually execute the movements of the robot. That is to say, Commander contained the lowest level code on how the robot moves. <br />
<br />
The image processing thread worked with the class ImageScanner. As the name implies, ImageScanner scans the image and makes available to the other thread the positions of various points of interests. The method ImageScanner.analyze() is at the heart of the class and contains four different submethods that all work in the same way. These methods find_red_blob() , find_blue_blob() etc identify the regions of the image that contain the respective colors. When the regions are found, their center of mass and extremities are recorded to be made available to the other thread. In the event that we wanted to see the output of the method in a visual sense, we can uncomment the name method ImageScanner.proc() and then forward the result to a BotClient.<br />
<br />
The finite state machine that comprises the main navigation thread is fairly simplistic. It starts off in a state called "SCAN" and essentially takes several scans of the course in front of it. On the occasion that it might see a red ball, it changes to the state "FOLLOW__FOOBALL" (FOO being either RED or GREEN). In this state, it uses a simplistic proportional controller to try to zero in on the ball. As such whenever the ball is on the left, the robot moves left slightly and the same on the right. Upon having the ball centered, the robot then charges forward at full speed and attempts to pick it up using the state "PICKUP_BALL". The state involves two smaller threads originating in Commander that allow the robot to move backwards slightly while lifting the scoop as well. The actual scoring mechanism was never really implemented, but similar methods to "SCAN" and "FOLLOW_REDBALL" were hypothesized for the search and approach to goals.<br />
<br />
==Overall Performance==<br />
<br />
Our robot's final performance was non-ideal (we were one of the first groups knocked out). We ended up having scoop/code problems that didn't pop up until the night before the competition, and we weren't able to fix it in time. Overall, we had a physical robot prepared, but it was too late to get our code working with it.<br />
<br />
==Conclusions==<br />
<br />
Our team came in with the purpose of learning more about building and coding, having lot of fun and sleep deprivation doing it, and not worrying about being the most competitive team. For the most part, this worked out really well (other than a couple of panicked moments where we were behind on a checkpoint or two and wondered if we should drop out - the staff helped get us up to speed and this ended up not being a problem). Overall, we walked away with what we wanted to get out of MASlab, which is really awesome.<br />
<br />
We ended up deviating from our original scheduling plan quite a bit. Instead of having our strongest coders (Michael and Shawn) code and our builders (Wings and Xavier) build, we had a fuzzy division of labor that arose naturally. After discussing designs, Xavier would go build, and Wings would maintain the journal and keep a to-do list for our robot. Wings and Shawn would also solder and construct other parts (ie, at the Edgerton Center). Michael worked on the code. With both the code and the building, we constantly sanity-checked each other and proposed alternative ideas, coming to a group agreement every step of the way. <br />
<br />
However, we ended up not being effective at this with our code. Michael spent a lot of time coding, but not being able to build the robot fast enough and not being absolutely clear on how the code and robot should interact meant that we ran into a lot of problems when we were trying to tie everything together. With more time, we would've been able to debug enough to have our robot work as intended. In the end, however, we weren't able to do this, and defaulted to the plan of just having the robot drive around and scoop up balls instead of using our scoring mechanism.<br />
<br />
But as stated before, we are very happy with what we got out of MASlab. We learned to build, code, and work as a team. No doubt we'll carry on the awesome lessons we learned here :)<br />
<br />
==Suggestions for future teams==<br />
<br />
When forming a team, make sure that everyone is on the same page as far as what they want to get out of MASlab, how competitive they want to be, and what their time commitments are expected to be. Also, there's absolutely no harm in thinking about ideas over winter break! It certainly means building can start earlier. Which brings us to...<br />
<br />
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.</div>Emolaguehttps://maslab.mit.edu/2011/wiki/Team_Six/JournalTeam Six/Journal2011-01-12T22:23:32Z<p>Emolague: </p>
<hr />
<div>__TOC__<br />
<br />
==January 3rd, 2011==<br />
<br />
First time writing the date this year, and I (Piper) got it right! W00! Anyway, our team began Maslab in an extremely sleep-deprived state, which made things very amusing. (I was incredibly giggly...) (I am journaling this sleep-deprived. Expect lots of exclamation points and smiley faces!)<br />
<br />
Problems we ran into with our code: our "Hello, World!" statement won't print without being in an infinite loop. We're not entirely sure why, but this problem didn't carry over to our Drive class (which we used to get our second component of the checkoff - the robot drove forward for three seconds). This is a good thing, because interrupting the infinite loop didn't work, and we can't make infinity last only three seconds :). After a little debugging, our code successfully drove the robot forward for three seconds and stopped.<br />
<br />
With the actual board, we were able to attach our wheels, motors, and castor to our base. We had trouble securing all our wires to the microboard, since the crimping didn't seem to clamp the wires down all the way. We also had to short our emergency stop (due to Maslab adjusting some of the code this year) before our robot could work. But worked it did! And we got a checkoff! And then it broke again! After replacing a fuse and soldering the insides of our battery clips, our attachments were more secure and the robot worked again :).<br />
<br />
<br />
'''[x] Since one of our motors were initially wired backwards, our ground and power do not follow the standard color convention. We should rewire this.<br />
<br />
'''[x] Double check to see that when our code decides the robot is moving forward, the robot is moving forward instead of backwards.<br />
<br />
==January 4th, 2011==<br />
<br />
'''Possible algorithm for robot''': 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.<br />
<br />
'''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.<br />
<br />
'''Schedule'''<br />
<br />
* Michael - Since Maslab is his main IAP commitment, he'll code in the evenings and possibly during the day. <br />
* Shawn - Work until 4pm every day, code at night with Michael.<br />
* Piper - Work on building between lecture (or late mornings when lecture isn't happening) and 7pm daily.<br />
* Xavier - Work on building between lecture (or late mornings when lecture isn't happening) and 7pm daily.<br />
<br />
'''Other'''<br />
* Piper did shop training today.<br />
* Xavier did laser training today.<br />
<br />
<br />
'''[x] TA gave us a suggestion for fixing the code problem we had on the first day. Try it out. [it works now! yay!]'''<br />
<br />
== January 5th, 2011 ==<br />
<br />
'''New robot strategy''': We came to realize that our original robot design was problematic. Our design had a lot of failure modes. 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. So, yay! :)<br />
<br />
We're going to have a scoop with a slanted arm leading down, away from the robot. We will scoop the ball, then rotate the arm up so that it rolls down the arm into our collection box. This requires another motor with a decent amount of torque, and will likely be our main expense. Our collection box will be at least 6" above the ground. Our computer, battery, and orc board will live under the collection box. The collection box itself will be slanted towards a drawbridge on the back, which we will use a servo to open and close. With this design, we believe that building will be easier, ball collection will be more predictable, and we will now be able to score over the wall! <br />
<br />
We are currently working on a SolidWorks design. <br />
<br />
'''Other labwork''': We were able to successfully attach our new sensor to the orc board and calibrate it. (The distance is 16.93*output+1.624.) We decided that for consistency, we're going to be American and use inches. We got the robot to go up to a wall, sense it, stop, and turn. Thus earning Checkpoint 3! Yay! We started working on our image processing/camera, as well as making some cutouts to envision our robot better.<br />
<br />
'''Other''': Piper is no longer as sleep-deprived or as sick! Thus, the journaling is less scatterbrained. Bwaha. Shawn is somehow getting his thesis work done despite also doing Maslab! Xavier is sore from Ultimate frisbee (and has practice again tonight lol)! Michael is having trouble constantly switching between Mac OS, Ubuntu, and Windows.<br />
<br />
'''Other other''': Our print statement during testing was "Scully Scully Scully Scully Scully". This amused Michael greatly. Piper may or may not be obsessed with the X Files.<br />
<br />
<br />
<br />
'''[x] Possibly move wheels more towards the middle of our board. [we're probably going to with a two-wheel-two-caster operation<br />
<br />
'''[x] Figure out the torque needed on the new motor (weigh the balls?) [balls are super light]<br />
<br />
==January 6th, 2011==<br />
<br />
'''Lab''': Shawn and Xavier worked on robot design while Michael worked on the Checkoff 4 imaging problem. Piper joined Michael after the H-bridge tutorial. Also soldered a header together so that we could short our ESTOP in a less painful way :).<br />
<br />
'''Other''': Piper went to the H-bridge tutorial. Below are her random notes.<br />
<br />
* Current sense lines, always ground them. Both enable A and enable B should be tied to Vss. Input 1 and input 2 are tied to enable A and 3/4 are supplied to B. Orcboard output 5V needs to be connected to 5V line. Need to ground battery to ground and ground orcboard to ground. Supply voltage needs to be connected to the 12V line on battery.<br />
* Control-c might stop the code but not the motor. Make sure to clear the ports so that the motor stops in time.<br />
* Data sheet here: http://web.mit.edu/6.186/2011/Lectures/L298.pdf<br />
* There was an email sent out about shutdown hooks. We should look here: : http://download.oracle.com/javase/6/docs/api/java/lang/Runtime.html#addShutdownHook(java.lang.Thread)<br />
<br />
'''Other other''': <br />
<br />
* Michael and Piper have been arguing about who's a better Mexican for the past half hour.<br />
* And then a Spanish-speaking machine called Xavier's phone. He might be part of the Mexican mafia, and thus be most Mexican of all.<br />
* Robot beta plan (Piper's way): Robot is a giant skewer. Robot skewers other team's robot until dead. Robot then skewers own balls and tosses skewer onto other side. Profit!<br />
* Robot charlie plan (Shawn's way): robot is a giant vacuum. Robot vacuums up all balls. Robot fires all balls at the other team's robot. Profit!<br />
* Violence is the answer.<br />
* Robot delta plan (Shawn's other way): Build a plane. Collect balls upon takeoff. Dump on other side. Should be easy, right? :D<br />
* We were really happy to realize that our journal was long, thus writing the final paper will likely be super easy. Then we realized only about a quarter of the information here would actually be useful to our papers >.> :D<br />
<br />
<br />
'''[x] Figure out why our motors are so temperamental.<br />
<br />
'''[x] Decide where we want our sensors and camera.<br />
<br />
==January 7th, 2011==<br />
<br />
'''Labwork''': Our code can find red, blue, green, and yellow things! Yay, Checkoff Four! We also now have a full cardboard mockup of our robot, so we can start building. We're currently hard at work on the Checkoff Five code.<br />
<br />
'''Weekend plan''':<br />
* CODE CODE CODE<br />
* SolidWorks ? [decided not to do this because we have a physical model]<br />
<br />
'''Future plan''':<br />
* Use Monday's mock competition as a place to test our detection code and robot movement<br />
* Make robot parts and build this week!<br />
<br />
==January 10th, 2011==<br />
<br />
'''Lab''': SO MUCH CODING!!!!!! We did a lot of coding today, as well as revised our strategies for post-mock-competition. (Our robot isn't fully built yet, so our idealized code wouldn't have worked for this mock competition.) We ran into a lot of problems getting our camera to work :( Hopefully we'll be able to spend Tuesday-Thursday building and constructing for our robot, and testing our more finalized code by Thursday evening.<br />
<br />
'''Other''':<br />
* New robot strategy: Our robot will totally not be a trained puppy with an orcboard taped to it. It may ''look'' that way, but we promise the drool is purely synthetic.<br />
<br />
'''Other Other''':<br />
* "How can Farrah Fawcett die? She was so cool!"<br />
* Batman hasn't died because he is ''actually'' cool.<br />
<br />
<br />
'''[ ] Figure out why our repository is sad.<br />
<br />
==January 11th, 2011==<br />
<br />
'''Lab''': EVEN MORE CODING OMGZ!!!! We also made some progress on making our design REAL! We have dimensions ready and hinges designed so that we can spend the rest of the week building, hoping to be done by Thursday evening. We got the camera to supply tracking! Now it accurately gives information to the controller and gives recommendations on what way the robot should turn.<br />
<br />
Michael then doubled the speed of image processing. We were doing the main process twice.<br />
'''Other''':<br />
* Beakman is better than Bill Nye, but no one ever saw Beakman :/<br />
* Xena was way more attractive than Bill Nye.<br />
* We have been in Maslab forever. <br />
* Piper hates computers. (But she really loves them.)<br />
* The passage of time is truly a mystery. "How did it 6pm?!"<br />
* Michael is obsessed by the song "Vagabond" from 500 Days of Summer (a movie that makes him cry).<br />
<br />
==January 12th, 2011==<br />
<br />
Snow day!!!! Michael did some angle from image data calculations and got stressed when he couldn't work it out so he came to annoy Piper.</div>Emolaguehttps://maslab.mit.edu/2011/wiki/Team_Six/JournalTeam Six/Journal2011-01-12T03:46:34Z<p>Emolague: /* January 11th, 2011 */</p>
<hr />
<div>__TOC__<br />
<br />
==January 3rd, 2011==<br />
<br />
First time writing the date this year, and I (Piper) got it right! W00! Anyway, our team began Maslab in an extremely sleep-deprived state, which made things very amusing. (I was incredibly giggly...) (I am journaling this sleep-deprived. Expect lots of exclamation points and smiley faces!)<br />
<br />
Problems we ran into with our code: our "Hello, World!" statement won't print without being in an infinite loop. We're not entirely sure why, but this problem didn't carry over to our Drive class (which we used to get our second component of the checkoff - the robot drove forward for three seconds). This is a good thing, because interrupting the infinite loop didn't work, and we can't make infinity last only three seconds :). After a little debugging, our code successfully drove the robot forward for three seconds and stopped.<br />
<br />
With the actual board, we were able to attach our wheels, motors, and castor to our base. We had trouble securing all our wires to the microboard, since the crimping didn't seem to clamp the wires down all the way. We also had to short our emergency stop (due to Maslab adjusting some of the code this year) before our robot could work. But worked it did! And we got a checkoff! And then it broke again! After replacing a fuse and soldering the insides of our battery clips, our attachments were more secure and the robot worked again :).<br />
<br />
<br />
'''[x] Since one of our motors were initially wired backwards, our ground and power do not follow the standard color convention. We should rewire this.<br />
<br />
'''[x] Double check to see that when our code decides the robot is moving forward, the robot is moving forward instead of backwards.<br />
<br />
==January 4th, 2011==<br />
<br />
'''Possible algorithm for robot''': 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.<br />
<br />
'''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.<br />
<br />
'''Schedule'''<br />
<br />
* Michael - Since Maslab is his main IAP commitment, he'll code in the evenings and possibly during the day. <br />
* Shawn - Work until 4pm every day, code at night with Michael.<br />
* Piper - Work on building between lecture (or late mornings when lecture isn't happening) and 7pm daily.<br />
* Xavier - Work on building between lecture (or late mornings when lecture isn't happening) and 7pm daily.<br />
<br />
'''Other'''<br />
* Piper did shop training today.<br />
* Xavier did laser training today.<br />
<br />
<br />
'''[x] TA gave us a suggestion for fixing the code problem we had on the first day. Try it out. [it works now! yay!]'''<br />
<br />
== January 5th, 2011 ==<br />
<br />
'''New robot strategy''': We came to realize that our original robot design was problematic. Our design had a lot of failure modes. 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. So, yay! :)<br />
<br />
We're going to have a scoop with a slanted arm leading down, away from the robot. We will scoop the ball, then rotate the arm up so that it rolls down the arm into our collection box. This requires another motor with a decent amount of torque, and will likely be our main expense. Our collection box will be at least 6" above the ground. Our computer, battery, and orc board will live under the collection box. The collection box itself will be slanted towards a drawbridge on the back, which we will use a servo to open and close. With this design, we believe that building will be easier, ball collection will be more predictable, and we will now be able to score over the wall! <br />
<br />
We are currently working on a SolidWorks design. <br />
<br />
'''Other labwork''': We were able to successfully attach our new sensor to the orc board and calibrate it. (The distance is 16.93*output+1.624.) We decided that for consistency, we're going to be American and use inches. We got the robot to go up to a wall, sense it, stop, and turn. Thus earning Checkpoint 3! Yay! We started working on our image processing/camera, as well as making some cutouts to envision our robot better.<br />
<br />
'''Other''': Piper is no longer as sleep-deprived or as sick! Thus, the journaling is less scatterbrained. Bwaha. Shawn is somehow getting his thesis work done despite also doing Maslab! Xavier is sore from Ultimate frisbee (and has practice again tonight lol)! Michael is having trouble constantly switching between Mac OS, Ubuntu, and Windows.<br />
<br />
'''Other other''': Our print statement during testing was "Scully Scully Scully Scully Scully". This amused Michael greatly. Piper may or may not be obsessed with the X Files.<br />
<br />
<br />
<br />
'''[x] Possibly move wheels more towards the middle of our board. [we're probably going to with a two-wheel-two-caster operation<br />
<br />
'''[x] Figure out the torque needed on the new motor (weigh the balls?) [balls are super light]<br />
<br />
==January 6th, 2011==<br />
<br />
'''Lab''': Shawn and Xavier worked on robot design while Michael worked on the Checkoff 4 imaging problem. Piper joined Michael after the H-bridge tutorial. Also soldered a header together so that we could short our ESTOP in a less painful way :).<br />
<br />
'''Other''': Piper went to the H-bridge tutorial. Below are her random notes.<br />
<br />
* Current sense lines, always ground them. Both enable A and enable B should be tied to Vss. Input 1 and input 2 are tied to enable A and 3/4 are supplied to B. Orcboard output 5V needs to be connected to 5V line. Need to ground battery to ground and ground orcboard to ground. Supply voltage needs to be connected to the 12V line on battery.<br />
* Control-c might stop the code but not the motor. Make sure to clear the ports so that the motor stops in time.<br />
* Data sheet here: http://web.mit.edu/6.186/2011/Lectures/L298.pdf<br />
* There was an email sent out about shutdown hooks. We should look here: : http://download.oracle.com/javase/6/docs/api/java/lang/Runtime.html#addShutdownHook(java.lang.Thread)<br />
<br />
'''Other other''': <br />
<br />
* Michael and Piper have been arguing about who's a better Mexican for the past half hour.<br />
* And then a Spanish-speaking machine called Xavier's phone. He might be part of the Mexican mafia, and thus be most Mexican of all.<br />
* Robot beta plan (Piper's way): Robot is a giant skewer. Robot skewers other team's robot until dead. Robot then skewers own balls and tosses skewer onto other side. Profit!<br />
* Robot charlie plan (Shawn's way): robot is a giant vacuum. Robot vacuums up all balls. Robot fires all balls at the other team's robot. Profit!<br />
* Violence is the answer.<br />
* Robot delta plan (Shawn's other way): Build a plane. Collect balls upon takeoff. Dump on other side. Should be easy, right? :D<br />
* We were really happy to realize that our journal was long, thus writing the final paper will likely be super easy. Then we realized only about a quarter of the information here would actually be useful to our papers >.> :D<br />
<br />
<br />
'''[x] Figure out why our motors are so temperamental.<br />
<br />
'''[x] Decide where we want our sensors and camera.<br />
<br />
==January 7th, 2011==<br />
<br />
'''Labwork''': Our code can find red, blue, green, and yellow things! Yay, Checkoff Four! We also now have a full cardboard mockup of our robot, so we can start building. We're currently hard at work on the Checkoff Five code.<br />
<br />
'''Weekend plan''':<br />
* CODE CODE CODE<br />
* SolidWorks ? [decided not to do this because we have a physical model]<br />
<br />
'''Future plan''':<br />
* Use Monday's mock competition as a place to test our detection code and robot movement<br />
* Make robot parts and build this week!<br />
<br />
==January 10th, 2011==<br />
<br />
'''Lab''': SO MUCH CODING!!!!!! We did a lot of coding today, as well as revised our strategies for post-mock-competition. (Our robot isn't fully built yet, so our idealized code wouldn't have worked for this mock competition.) We ran into a lot of problems getting our camera to work :( Hopefully we'll be able to spend Tuesday-Thursday building and constructing for our robot, and testing our more finalized code by Thursday evening.<br />
<br />
'''Other''':<br />
* New robot strategy: Our robot will totally not be a trained puppy with an orcboard taped to it. It may ''look'' that way, but we promise the drool is purely synthetic.<br />
<br />
'''Other Other''':<br />
* "How can Farrah Fawcett die? She was so cool!"<br />
* Batman hasn't died because he is ''actually'' cool.<br />
<br />
<br />
'''[ ] Figure out why our repository is sad.<br />
<br />
==January 11th, 2011==<br />
<br />
'''Lab''': EVEN MORE CODING OMGZ!!!! We also made some progress on making our design REAL! We have dimensions ready and hinges designed so that we can spend the rest of the week building, hoping to be done by Thursday evening. We got the camera to supply tracking! Now it accurately gives information to the controller and gives recommendations on what way the robot should turn.<br />
<br />
Michael then doubled the speed of image processing. We were doing the main process twice.<br />
'''Other''':<br />
* Beakman is better than Bill Nye, but no one ever saw Beakman :/<br />
* Xena was way more attractive than Bill Nye.<br />
* We have been in Maslab forever. <br />
* Piper hates computers. (But she really loves them.)<br />
* The passage of time is truly a mystery. "How did it 6pm?!"<br />
* Michael is obsessed by the song "Vagabond" from 500 Days of Summer (a movie that makes him cry).</div>Emolaguehttps://maslab.mit.edu/2011/wiki/Team_Six/JournalTeam Six/Journal2011-01-11T23:03:41Z<p>Emolague: /* January 11th, 2011 */</p>
<hr />
<div>__TOC__<br />
<br />
==January 3rd, 2011==<br />
<br />
First time writing the date this year, and I (Piper) got it right! W00! Anyway, our team began Maslab in an extremely sleep-deprived state, which made things very amusing. (I was incredibly giggly...) (I am journaling this sleep-deprived. Expect lots of exclamation points and smiley faces!)<br />
<br />
Problems we ran into with our code: our "Hello, World!" statement won't print without being in an infinite loop. We're not entirely sure why, but this problem didn't carry over to our Drive class (which we used to get our second component of the checkoff - the robot drove forward for three seconds). This is a good thing, because interrupting the infinite loop didn't work, and we can't make infinity last only three seconds :). After a little debugging, our code successfully drove the robot forward for three seconds and stopped.<br />
<br />
With the actual board, we were able to attach our wheels, motors, and castor to our base. We had trouble securing all our wires to the microboard, since the crimping didn't seem to clamp the wires down all the way. We also had to short our emergency stop (due to Maslab adjusting some of the code this year) before our robot could work. But worked it did! And we got a checkoff! And then it broke again! After replacing a fuse and soldering the insides of our battery clips, our attachments were more secure and the robot worked again :).<br />
<br />
<br />
'''[x] Since one of our motors were initially wired backwards, our ground and power do not follow the standard color convention. We should rewire this.<br />
<br />
'''[x] Double check to see that when our code decides the robot is moving forward, the robot is moving forward instead of backwards.<br />
<br />
==January 4th, 2011==<br />
<br />
'''Possible algorithm for robot''': 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.<br />
<br />
'''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.<br />
<br />
'''Schedule'''<br />
<br />
* Michael - Since Maslab is his main IAP commitment, he'll code in the evenings and possibly during the day. <br />
* Shawn - Work until 4pm every day, code at night with Michael.<br />
* Piper - Work on building between lecture (or late mornings when lecture isn't happening) and 7pm daily.<br />
* Xavier - Work on building between lecture (or late mornings when lecture isn't happening) and 7pm daily.<br />
<br />
'''Other'''<br />
* Piper did shop training today.<br />
* Xavier did laser training today.<br />
<br />
<br />
'''[x] TA gave us a suggestion for fixing the code problem we had on the first day. Try it out. [it works now! yay!]'''<br />
<br />
== January 5th, 2011 ==<br />
<br />
'''New robot strategy''': We came to realize that our original robot design was problematic. Our design had a lot of failure modes. 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. So, yay! :)<br />
<br />
We're going to have a scoop with a slanted arm leading down, away from the robot. We will scoop the ball, then rotate the arm up so that it rolls down the arm into our collection box. This requires another motor with a decent amount of torque, and will likely be our main expense. Our collection box will be at least 6" above the ground. Our computer, battery, and orc board will live under the collection box. The collection box itself will be slanted towards a drawbridge on the back, which we will use a servo to open and close. With this design, we believe that building will be easier, ball collection will be more predictable, and we will now be able to score over the wall! <br />
<br />
We are currently working on a SolidWorks design. <br />
<br />
'''Other labwork''': We were able to successfully attach our new sensor to the orc board and calibrate it. (The distance is 16.93*output+1.624.) We decided that for consistency, we're going to be American and use inches. We got the robot to go up to a wall, sense it, stop, and turn. Thus earning Checkpoint 3! Yay! We started working on our image processing/camera, as well as making some cutouts to envision our robot better.<br />
<br />
'''Other''': Piper is no longer as sleep-deprived or as sick! Thus, the journaling is less scatterbrained. Bwaha. Shawn is somehow getting his thesis work done despite also doing Maslab! Xavier is sore from Ultimate frisbee (and has practice again tonight lol)! Michael is having trouble constantly switching between Mac OS, Ubuntu, and Windows.<br />
<br />
'''Other other''': Our print statement during testing was "Scully Scully Scully Scully Scully". This amused Michael greatly. Piper may or may not be obsessed with the X Files.<br />
<br />
<br />
<br />
'''[x] Possibly move wheels more towards the middle of our board. [we're probably going to with a two-wheel-two-caster operation<br />
<br />
'''[x] Figure out the torque needed on the new motor (weigh the balls?) [balls are super light]<br />
<br />
==January 6th, 2011==<br />
<br />
'''Lab''': Shawn and Xavier worked on robot design while Michael worked on the Checkoff 4 imaging problem. Piper joined Michael after the H-bridge tutorial. Also soldered a header together so that we could short our ESTOP in a less painful way :).<br />
<br />
'''Other''': Piper went to the H-bridge tutorial. Below are her random notes.<br />
<br />
* Current sense lines, always ground them. Both enable A and enable B should be tied to Vss. Input 1 and input 2 are tied to enable A and 3/4 are supplied to B. Orcboard output 5V needs to be connected to 5V line. Need to ground battery to ground and ground orcboard to ground. Supply voltage needs to be connected to the 12V line on battery.<br />
* Control-c might stop the code but not the motor. Make sure to clear the ports so that the motor stops in time.<br />
* Data sheet here: http://web.mit.edu/6.186/2011/Lectures/L298.pdf<br />
* There was an email sent out about shutdown hooks. We should look here: : http://download.oracle.com/javase/6/docs/api/java/lang/Runtime.html#addShutdownHook(java.lang.Thread)<br />
<br />
'''Other other''': <br />
<br />
* Michael and Piper have been arguing about who's a better Mexican for the past half hour.<br />
* And then a Spanish-speaking machine called Xavier's phone. He might be part of the Mexican mafia, and thus be most Mexican of all.<br />
* Robot beta plan (Piper's way): Robot is a giant skewer. Robot skewers other team's robot until dead. Robot then skewers own balls and tosses skewer onto other side. Profit!<br />
* Robot charlie plan (Shawn's way): robot is a giant vacuum. Robot vacuums up all balls. Robot fires all balls at the other team's robot. Profit!<br />
* Violence is the answer.<br />
* Robot delta plan (Shawn's other way): Build a plane. Collect balls upon takeoff. Dump on other side. Should be easy, right? :D<br />
* We were really happy to realize that our journal was long, thus writing the final paper will likely be super easy. Then we realized only about a quarter of the information here would actually be useful to our papers >.> :D<br />
<br />
<br />
'''[x] Figure out why our motors are so temperamental.<br />
<br />
'''[x] Decide where we want our sensors and camera.<br />
<br />
==January 7th, 2011==<br />
<br />
'''Labwork''': Our code can find red, blue, green, and yellow things! Yay, Checkoff Four! We also now have a full cardboard mockup of our robot, so we can start building. We're currently hard at work on the Checkoff Five code.<br />
<br />
'''Weekend plan''':<br />
* CODE CODE CODE<br />
* SolidWorks ? [decided not to do this because we have a physical model]<br />
<br />
'''Future plan''':<br />
* Use Monday's mock competition as a place to test our detection code and robot movement<br />
* Make robot parts and build this week!<br />
<br />
==January 10th, 2011==<br />
<br />
'''Lab''': SO MUCH CODING!!!!!! We did a lot of coding today, as well as revised our strategies for post-mock-competition. (Our robot isn't fully built yet, so our idealized code wouldn't have worked for this mock competition.) We ran into a lot of problems getting our camera to work :( Hopefully we'll be able to spend Tuesday-Thursday building and constructing for our robot, and testing our more finalized code by Thursday evening.<br />
<br />
'''Other''':<br />
* New robot strategy: Our robot will totally not be a trained puppy with an orcboard taped to it. It may ''look'' that way, but we promise the drool is purely synthetic.<br />
<br />
'''Other Other''':<br />
* "How can Farrah Fawcett die? She was so cool!"<br />
* Batman hasn't died because he is ''actually'' cool.<br />
<br />
<br />
'''[ ] Figure out why our repository is sad.<br />
<br />
==January 11th, 2011==<br />
<br />
'''Lab''': EVEN MORE CODING OMGZ!!!! We also made some progress on making our design REAL! We have dimensions ready and hinges designed so that we can spend the rest of the week building, hoping to be done by Thursday evening. We got the camera to supply tracking! Now it accurately gives information to the controller and gives recommendations on what way the robot should turn.<br />
<br />
'''Other''':<br />
* Beakman is better than Bill Nye, but no one ever saw Beakman :/<br />
* Xena was way more attractive than Bill Nye.<br />
* We have been in Maslab forever. <br />
* Piper hates computers. (But she really loves them.)<br />
* The passage of time is truly a mystery. "How did it 6pm?!"<br />
* Michael is obsessed by the song "Vagabond" from 500 Days of Summer (a movie that makes him cry).</div>Emolaguehttps://maslab.mit.edu/2011/wiki/Team_Six/JournalTeam Six/Journal2011-01-11T22:56:55Z<p>Emolague: /* January 11th, 2011 */</p>
<hr />
<div>__TOC__<br />
<br />
==January 3rd, 2011==<br />
<br />
First time writing the date this year, and I (Piper) got it right! W00! Anyway, our team began Maslab in an extremely sleep-deprived state, which made things very amusing. (I was incredibly giggly...) (I am journaling this sleep-deprived. Expect lots of exclamation points and smiley faces!)<br />
<br />
Problems we ran into with our code: our "Hello, World!" statement won't print without being in an infinite loop. We're not entirely sure why, but this problem didn't carry over to our Drive class (which we used to get our second component of the checkoff - the robot drove forward for three seconds). This is a good thing, because interrupting the infinite loop didn't work, and we can't make infinity last only three seconds :). After a little debugging, our code successfully drove the robot forward for three seconds and stopped.<br />
<br />
With the actual board, we were able to attach our wheels, motors, and castor to our base. We had trouble securing all our wires to the microboard, since the crimping didn't seem to clamp the wires down all the way. We also had to short our emergency stop (due to Maslab adjusting some of the code this year) before our robot could work. But worked it did! And we got a checkoff! And then it broke again! After replacing a fuse and soldering the insides of our battery clips, our attachments were more secure and the robot worked again :).<br />
<br />
<br />
'''[x] Since one of our motors were initially wired backwards, our ground and power do not follow the standard color convention. We should rewire this.<br />
<br />
'''[x] Double check to see that when our code decides the robot is moving forward, the robot is moving forward instead of backwards.<br />
<br />
==January 4th, 2011==<br />
<br />
'''Possible algorithm for robot''': 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.<br />
<br />
'''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.<br />
<br />
'''Schedule'''<br />
<br />
* Michael - Since Maslab is his main IAP commitment, he'll code in the evenings and possibly during the day. <br />
* Shawn - Work until 4pm every day, code at night with Michael.<br />
* Piper - Work on building between lecture (or late mornings when lecture isn't happening) and 7pm daily.<br />
* Xavier - Work on building between lecture (or late mornings when lecture isn't happening) and 7pm daily.<br />
<br />
'''Other'''<br />
* Piper did shop training today.<br />
* Xavier did laser training today.<br />
<br />
<br />
'''[x] TA gave us a suggestion for fixing the code problem we had on the first day. Try it out. [it works now! yay!]'''<br />
<br />
== January 5th, 2011 ==<br />
<br />
'''New robot strategy''': We came to realize that our original robot design was problematic. Our design had a lot of failure modes. 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. So, yay! :)<br />
<br />
We're going to have a scoop with a slanted arm leading down, away from the robot. We will scoop the ball, then rotate the arm up so that it rolls down the arm into our collection box. This requires another motor with a decent amount of torque, and will likely be our main expense. Our collection box will be at least 6" above the ground. Our computer, battery, and orc board will live under the collection box. The collection box itself will be slanted towards a drawbridge on the back, which we will use a servo to open and close. With this design, we believe that building will be easier, ball collection will be more predictable, and we will now be able to score over the wall! <br />
<br />
We are currently working on a SolidWorks design. <br />
<br />
'''Other labwork''': We were able to successfully attach our new sensor to the orc board and calibrate it. (The distance is 16.93*output+1.624.) We decided that for consistency, we're going to be American and use inches. We got the robot to go up to a wall, sense it, stop, and turn. Thus earning Checkpoint 3! Yay! We started working on our image processing/camera, as well as making some cutouts to envision our robot better.<br />
<br />
'''Other''': Piper is no longer as sleep-deprived or as sick! Thus, the journaling is less scatterbrained. Bwaha. Shawn is somehow getting his thesis work done despite also doing Maslab! Xavier is sore from Ultimate frisbee (and has practice again tonight lol)! Michael is having trouble constantly switching between Mac OS, Ubuntu, and Windows.<br />
<br />
'''Other other''': Our print statement during testing was "Scully Scully Scully Scully Scully". This amused Michael greatly. Piper may or may not be obsessed with the X Files.<br />
<br />
<br />
<br />
'''[x] Possibly move wheels more towards the middle of our board. [we're probably going to with a two-wheel-two-caster operation<br />
<br />
'''[x] Figure out the torque needed on the new motor (weigh the balls?) [balls are super light]<br />
<br />
==January 6th, 2011==<br />
<br />
'''Lab''': Shawn and Xavier worked on robot design while Michael worked on the Checkoff 4 imaging problem. Piper joined Michael after the H-bridge tutorial. Also soldered a header together so that we could short our ESTOP in a less painful way :).<br />
<br />
'''Other''': Piper went to the H-bridge tutorial. Below are her random notes.<br />
<br />
* Current sense lines, always ground them. Both enable A and enable B should be tied to Vss. Input 1 and input 2 are tied to enable A and 3/4 are supplied to B. Orcboard output 5V needs to be connected to 5V line. Need to ground battery to ground and ground orcboard to ground. Supply voltage needs to be connected to the 12V line on battery.<br />
* Control-c might stop the code but not the motor. Make sure to clear the ports so that the motor stops in time.<br />
* Data sheet here: http://web.mit.edu/6.186/2011/Lectures/L298.pdf<br />
* There was an email sent out about shutdown hooks. We should look here: : http://download.oracle.com/javase/6/docs/api/java/lang/Runtime.html#addShutdownHook(java.lang.Thread)<br />
<br />
'''Other other''': <br />
<br />
* Michael and Piper have been arguing about who's a better Mexican for the past half hour.<br />
* And then a Spanish-speaking machine called Xavier's phone. He might be part of the Mexican mafia, and thus be most Mexican of all.<br />
* Robot beta plan (Piper's way): Robot is a giant skewer. Robot skewers other team's robot until dead. Robot then skewers own balls and tosses skewer onto other side. Profit!<br />
* Robot charlie plan (Shawn's way): robot is a giant vacuum. Robot vacuums up all balls. Robot fires all balls at the other team's robot. Profit!<br />
* Violence is the answer.<br />
* Robot delta plan (Shawn's other way): Build a plane. Collect balls upon takeoff. Dump on other side. Should be easy, right? :D<br />
* We were really happy to realize that our journal was long, thus writing the final paper will likely be super easy. Then we realized only about a quarter of the information here would actually be useful to our papers >.> :D<br />
<br />
<br />
'''[x] Figure out why our motors are so temperamental.<br />
<br />
'''[x] Decide where we want our sensors and camera.<br />
<br />
==January 7th, 2011==<br />
<br />
'''Labwork''': Our code can find red, blue, green, and yellow things! Yay, Checkoff Four! We also now have a full cardboard mockup of our robot, so we can start building. We're currently hard at work on the Checkoff Five code.<br />
<br />
'''Weekend plan''':<br />
* CODE CODE CODE<br />
* SolidWorks ? [decided not to do this because we have a physical model]<br />
<br />
'''Future plan''':<br />
* Use Monday's mock competition as a place to test our detection code and robot movement<br />
* Make robot parts and build this week!<br />
<br />
==January 10th, 2011==<br />
<br />
'''Lab''': SO MUCH CODING!!!!!! We did a lot of coding today, as well as revised our strategies for post-mock-competition. (Our robot isn't fully built yet, so our idealized code wouldn't have worked for this mock competition.) We ran into a lot of problems getting our camera to work :( Hopefully we'll be able to spend Tuesday-Thursday building and constructing for our robot, and testing our more finalized code by Thursday evening.<br />
<br />
'''Other''':<br />
* New robot strategy: Our robot will totally not be a trained puppy with an orcboard taped to it. It may ''look'' that way, but we promise the drool is purely synthetic.<br />
<br />
'''Other Other''':<br />
* "How can Farrah Fawcett die? She was so cool!"<br />
* Batman hasn't died because he is ''actually'' cool.<br />
<br />
<br />
'''[ ] Figure out why our repository is sad.<br />
<br />
==January 11th, 2011==<br />
<br />
'''Lab''': EVEN MORE CODING OMGZ!!!! We also made some progress on making our design REAL! We have dimensions ready and hinges designed so that we can spend the rest of the week building, hoping to be done by Thursday evening. We got the camera to supply tracking! Now it accurately gives information to the controller and gives recommendations on what way the robot should turn.<br />
<br />
'''Other''':<br />
* Beakman is better than Bill Nye, but no one ever saw Beakman :/<br />
* Xena was way more attractive than Bill Nye.<br />
* We have been in Maslab forever. <br />
* Piper hates computers. (But she really loves them.)<br />
* The passage of time is truly a mystery.</div>Emolaguehttps://maslab.mit.edu/2011/wiki/Team_Six/JournalTeam Six/Journal2011-01-06T19:42:35Z<p>Emolague: /* January 6th, 2011 */</p>
<hr />
<div>__TOC__<br />
<br />
==January 3rd, 2011==<br />
<br />
First time writing the date this year, and I (Piper) got it right! W00! Anyway, our team began Maslab in an extremely sleep-deprived state, which made things very amusing. (I was incredibly giggly...) (I am journaling this sleep-deprived. Expect lots of exclamation points and smiley faces!)<br />
<br />
Problems we ran into with our code: our "Hello, World!" statement won't print without being in an infinite loop. We're not entirely sure why, but this problem didn't carry over to our Drive class (which we used to get our second component of the checkoff - the robot drove forward for three seconds). This is a good thing, because interrupting the infinite loop didn't work, and we can't make infinity last only three seconds :). After a little debugging, our code successfully drove the robot forward for three seconds and stopped.<br />
<br />
With the actual board, we were able to attach our wheels, motors, and castor to our base. We had trouble securing all our wires to the microboard, since the crimping didn't seem to clamp the wires down all the way. We also had to short our emergency stop (due to Maslab adjusting some of the code this year) before our robot could work. But worked it did! And we got a checkoff! And then it broke again! After replacing a fuse and soldering the insides of our battery clips, our attachments were more secure and the robot worked again :).<br />
<br />
<br />
'''[x] Since one of our motors were initially wired backwards, our ground and power do not follow the standard color convention. We should rewire this.<br />
<br />
'''[x] Double check to see that when our code decides the robot is moving forward, the robot is moving forward instead of backwards.<br />
<br />
==January 4th, 2011==<br />
<br />
'''Possible algorithm for robot''': 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.<br />
<br />
'''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.<br />
<br />
'''Schedule'''<br />
<br />
* Michael - Since Maslab is his main IAP commitment, he'll code in the evenings and possibly during the day. <br />
* Shawn - Work until 4pm every day, code at night with Michael.<br />
* Piper - Work on building between lecture (or late mornings when lecture isn't happening) and 7pm daily.<br />
* Xavier - Work on building between lecture (or late mornings when lecture isn't happening) and 7pm daily.<br />
<br />
'''Other'''<br />
* Piper did shop training today.<br />
* Xavier did laser training today.<br />
<br />
<br />
'''[ ] TA gave us a suggestion for fixing the code problem we had on the first day. Try it out.'''<br />
<br />
== January 5th, 2011 ==<br />
<br />
'''New robot strategy''': We came to realize that our original robot design was problematic. Our design had a lot of failure modes. 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. So, yay! :)<br />
<br />
We're going to have a scoop with a slanted arm leading down, away from the robot. We will scoop the ball, then rotate the arm up so that it rolls down the arm into our collection box. This requires another motor with a decent amount of torque, and will likely be our main expense. Our collection box will be at least 6" above the ground. Our computer, battery, and orc board will live under the collection box. The collection box itself will be slanted towards a drawbridge on the back, which we will use a servo to open and close. With this design, we believe that building will be easier, ball collection will be more predictable, and we will now be able to score over the wall! <br />
<br />
We are currently working on a SolidWorks design. <br />
<br />
'''Other labwork''': We were able to successfully attach our new sensor to the orc board and calibrate it. (The distance is 16.93*output+1.624.) We decided that for consistency, we're going to be American and use inches. We got the robot to go up to a wall, sense it, stop, and turn. Thus earning Checkpoint 3! Yay! We started working on our image processing/camera.<br />
<br />
'''Other''': Piper is no longer as sleep-deprived or as sick! Thus, the journaling is less scatterbrained. Bwaha. Shawn is somehow getting his thesis work done despite also doing Maslab! Xavier is sore from Ultimate frisbee (and has practice again tonight lol)! Michael is having trouble constantly switching between Mac OS, Ubuntu, and Windows.<br />
<br />
'''Other other''': Our print statement during testing was "Scully Scully Scully Scully Scully". This amused Michael greatly. Piper may or may not be obsessed with the X Files.<br />
<br />
<br />
'''[ ] Decide where we want our sensors and camera.<br />
<br />
'''[ ] Finish SolidWorks design.<br />
<br />
'''[ ] Possibly move wheels more towards the middle of our board.<br />
<br />
'''[ ] Figure out why our motors are so tempermental.<br />
<br />
'''[ ] Figure out the torque needed on the new motor (weigh the balls?)<br />
<br />
==January 6th, 2011==</div>Emolaguehttps://maslab.mit.edu/2011/wiki/Team_Six/JournalTeam Six/Journal2011-01-06T19:37:43Z<p>Emolague: /* January 6th, 2011 */</p>
<hr />
<div>__TOC__<br />
<br />
==January 3rd, 2011==<br />
<br />
First time writing the date this year, and I (Piper) got it right! W00! Anyway, our team began Maslab in an extremely sleep-deprived state, which made things very amusing. (I was incredibly giggly...) (I am journaling this sleep-deprived. Expect lots of exclamation points and smiley faces!)<br />
<br />
Problems we ran into with our code: our "Hello, World!" statement won't print without being in an infinite loop. We're not entirely sure why, but this problem didn't carry over to our Drive class (which we used to get our second component of the checkoff - the robot drove forward for three seconds). This is a good thing, because interrupting the infinite loop didn't work, and we can't make infinity last only three seconds :). After a little debugging, our code successfully drove the robot forward for three seconds and stopped.<br />
<br />
With the actual board, we were able to attach our wheels, motors, and castor to our base. We had trouble securing all our wires to the microboard, since the crimping didn't seem to clamp the wires down all the way. We also had to short our emergency stop (due to Maslab adjusting some of the code this year) before our robot could work. But worked it did! And we got a checkoff! And then it broke again! After replacing a fuse and soldering the insides of our battery clips, our attachments were more secure and the robot worked again :).<br />
<br />
<br />
'''[x] Since one of our motors were initially wired backwards, our ground and power do not follow the standard color convention. We should rewire this.<br />
<br />
'''[x] Double check to see that when our code decides the robot is moving forward, the robot is moving forward instead of backwards.<br />
<br />
==January 4th, 2011==<br />
<br />
'''Possible algorithm for robot''': 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.<br />
<br />
'''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.<br />
<br />
'''Schedule'''<br />
<br />
* Michael - Since Maslab is his main IAP commitment, he'll code in the evenings and possibly during the day. <br />
* Shawn - Work until 4pm every day, code at night with Michael.<br />
* Piper - Work on building between lecture (or late mornings when lecture isn't happening) and 7pm daily.<br />
* Xavier - Work on building between lecture (or late mornings when lecture isn't happening) and 7pm daily.<br />
<br />
'''Other'''<br />
* Piper did shop training today.<br />
* Xavier did laser training today.<br />
<br />
<br />
'''[ ] TA gave us a suggestion for fixing the code problem we had on the first day. Try it out.'''<br />
<br />
== January 5th, 2011 ==<br />
<br />
'''New robot strategy''': We came to realize that our original robot design was problematic. Our design had a lot of failure modes. 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. So, yay! :)<br />
<br />
We're going to have a scoop with a slanted arm leading down, away from the robot. We will scoop the ball, then rotate the arm up so that it rolls down the arm into our collection box. This requires another motor with a decent amount of torque, and will likely be our main expense. Our collection box will be at least 6" above the ground. Our computer, battery, and orc board will live under the collection box. The collection box itself will be slanted towards a drawbridge on the back, which we will use a servo to open and close. With this design, we believe that building will be easier, ball collection will be more predictable, and we will now be able to score over the wall! <br />
<br />
We are currently working on a SolidWorks design. <br />
<br />
'''Other labwork''': We were able to successfully attach our new sensor to the orc board and calibrate it. (The distance is 16.93*output+1.624.) We decided that for consistency, we're going to be American and use inches. We got the robot to go up to a wall, sense it, stop, and turn. Thus earning Checkpoint 3! Yay! We started working on our image processing/camera.<br />
<br />
'''Other''': Piper is no longer as sleep-deprived or as sick! Thus, the journaling is less scatterbrained. Bwaha. Shawn is somehow getting his thesis work done despite also doing Maslab! Xavier is sore from Ultimate frisbee (and has practice again tonight lol)! Michael is having trouble constantly switching between Mac OS, Ubuntu, and Windows.<br />
<br />
'''Other other''': Our print statement during testing was "Scully Scully Scully Scully Scully". This amused Michael greatly. Piper may or may not be obsessed with the X Files.<br />
<br />
<br />
'''[ ] Decide where we want our sensors and camera.<br />
<br />
'''[ ] Finish SolidWorks design.<br />
<br />
'''[ ] Possibly move wheels more towards the middle of our board.<br />
<br />
'''[ ] Figure out why our motors are so tempermental.<br />
<br />
'''[ ] Figure out the torque needed on the new motor (weigh the balls?)<br />
<br />
==January 6th, 2011==</div>Emolaguehttps://maslab.mit.edu/2011/wiki/Team_Six/JournalTeam Six/Journal2011-01-06T19:36:12Z<p>Emolague: /* January 6th, 2011 */</p>
<hr />
<div>__TOC__<br />
<br />
==January 3rd, 2011==<br />
<br />
First time writing the date this year, and I (Piper) got it right! W00! Anyway, our team began Maslab in an extremely sleep-deprived state, which made things very amusing. (I was incredibly giggly...) (I am journaling this sleep-deprived. Expect lots of exclamation points and smiley faces!)<br />
<br />
Problems we ran into with our code: our "Hello, World!" statement won't print without being in an infinite loop. We're not entirely sure why, but this problem didn't carry over to our Drive class (which we used to get our second component of the checkoff - the robot drove forward for three seconds). This is a good thing, because interrupting the infinite loop didn't work, and we can't make infinity last only three seconds :). After a little debugging, our code successfully drove the robot forward for three seconds and stopped.<br />
<br />
With the actual board, we were able to attach our wheels, motors, and castor to our base. We had trouble securing all our wires to the microboard, since the crimping didn't seem to clamp the wires down all the way. We also had to short our emergency stop (due to Maslab adjusting some of the code this year) before our robot could work. But worked it did! And we got a checkoff! And then it broke again! After replacing a fuse and soldering the insides of our battery clips, our attachments were more secure and the robot worked again :).<br />
<br />
<br />
'''[x] Since one of our motors were initially wired backwards, our ground and power do not follow the standard color convention. We should rewire this.<br />
<br />
'''[x] Double check to see that when our code decides the robot is moving forward, the robot is moving forward instead of backwards.<br />
<br />
==January 4th, 2011==<br />
<br />
'''Possible algorithm for robot''': 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.<br />
<br />
'''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.<br />
<br />
'''Schedule'''<br />
<br />
* Michael - Since Maslab is his main IAP commitment, he'll code in the evenings and possibly during the day. <br />
* Shawn - Work until 4pm every day, code at night with Michael.<br />
* Piper - Work on building between lecture (or late mornings when lecture isn't happening) and 7pm daily.<br />
* Xavier - Work on building between lecture (or late mornings when lecture isn't happening) and 7pm daily.<br />
<br />
'''Other'''<br />
* Piper did shop training today.<br />
* Xavier did laser training today.<br />
<br />
<br />
'''[ ] TA gave us a suggestion for fixing the code problem we had on the first day. Try it out.'''<br />
<br />
== January 5th, 2011 ==<br />
<br />
'''New robot strategy''': We came to realize that our original robot design was problematic. Our design had a lot of failure modes. 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. So, yay! :)<br />
<br />
We're going to have a scoop with a slanted arm leading down, away from the robot. We will scoop the ball, then rotate the arm up so that it rolls down the arm into our collection box. This requires another motor with a decent amount of torque, and will likely be our main expense. Our collection box will be at least 6" above the ground. Our computer, battery, and orc board will live under the collection box. The collection box itself will be slanted towards a drawbridge on the back, which we will use a servo to open and close. With this design, we believe that building will be easier, ball collection will be more predictable, and we will now be able to score over the wall! <br />
<br />
We are currently working on a SolidWorks design. <br />
<br />
'''Other labwork''': We were able to successfully attach our new sensor to the orc board and calibrate it. (The distance is 16.93*output+1.624.) We decided that for consistency, we're going to be American and use inches. We got the robot to go up to a wall, sense it, stop, and turn. Thus earning Checkpoint 3! Yay! We started working on our image processing/camera.<br />
<br />
'''Other''': Piper is no longer as sleep-deprived or as sick! Thus, the journaling is less scatterbrained. Bwaha. Shawn is somehow getting his thesis work done despite also doing Maslab! Xavier is sore from Ultimate frisbee (and has practice again tonight lol)! Michael is having trouble constantly switching between Mac OS, Ubuntu, and Windows.<br />
<br />
'''Other other''': Our print statement during testing was "Scully Scully Scully Scully Scully". This amused Michael greatly. Piper may or may not be obsessed with the X Files.<br />
<br />
<br />
'''[ ] Decide where we want our sensors and camera.<br />
<br />
'''[ ] Finish SolidWorks design.<br />
<br />
'''[ ] Possibly move wheels more towards the middle of our board.<br />
<br />
'''[ ] Figure out why our motors are so tempermental.<br />
<br />
'''[ ] Figure out the torque needed on the new motor (weigh the balls?)<br />
<br />
==January 6th, 2011==</div>Emolaguehttps://maslab.mit.edu/2011/wiki/Team_Six/JournalTeam Six/Journal2011-01-05T00:49:36Z<p>Emolague: /* January 4th, 2011 */</p>
<hr />
<div>__TOC__<br />
<br />
==January 3rd, 2011==<br />
<br />
First time writing the date this year, and I (Piper) got it right! W00! Anyway, our team began Maslab in an extremely sleep-deprived state, which made things very amusing. (I was incredibly giggly...) (I am journaling this sleep-deprived. Expect lots of exclamation points and smiley faces!)<br />
<br />
Problems we ran into with our code: our "Hello, World!" statement won't print without being in an infinite loop. We're not entirely sure why, but this problem didn't carry over to our Drive class (which we used to get our second component of the checkoff - the robot drove forward for three seconds). This is a good thing, because interrupting the infinite loop didn't work, and we can't make infinity last only three seconds :). After a little debugging, our code successfully drove the robot forward for three seconds and stopped.<br />
<br />
With the actual board, we were able to attach our wheels, motors, and castor to our base. We had trouble securing all our wires to the microboard, since the crimping didn't seem to clamp the wires down all the way. We also had to short our emergency stop (due to Maslab adjusting some of the code this year) before our robot could work. But worked it did! And we got a checkoff! And then it broke again! After replacing a fuse and soldering the insides of our battery clips, our attachments were more secure and the robot worked again :).<br />
<br />
<br />
'''Things we need to fix tomorrow'''<br />
<br />
[ ] Since one of our motors were initially wired backwards, our ground and power do not follow the standard color convention. We should rewire this.<br />
<br />
[ ] Double check to see that when our code decides the robot is moving forward, the robot is moving forward instead of backwards.<br />
<br />
==January 4th, 2011==<br />
<br />
* Piper did shop training today.<br />
* Xavier did laser training today.<br />
<br />
<br />
'''Possible algorithm for robot''': 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.<br />
<br />
'''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.<br />
<br />
'''Schedule'''<br />
<br />
Michael - Since Maslab is his main IAP commitment, he'll code in the evenings and possibly during the day. <br />
<br />
Shawn - Work until 4pm every day, code at night with Michael.<br />
<br />
Piper - Work on building between lecture (or late mornings when lecture isn't happening) and 7pm daily.<br />
<br />
Xavier - Work on building between lecture (or late mornings when lecture isn't happening) and 7pm daily.</div>Emolaguehttps://maslab.mit.edu/2011/wiki/Team_Six/JournalTeam Six/Journal2011-01-05T00:49:18Z<p>Emolague: /* January 4th, 2011 */</p>
<hr />
<div>__TOC__<br />
<br />
==January 3rd, 2011==<br />
<br />
First time writing the date this year, and I (Piper) got it right! W00! Anyway, our team began Maslab in an extremely sleep-deprived state, which made things very amusing. (I was incredibly giggly...) (I am journaling this sleep-deprived. Expect lots of exclamation points and smiley faces!)<br />
<br />
Problems we ran into with our code: our "Hello, World!" statement won't print without being in an infinite loop. We're not entirely sure why, but this problem didn't carry over to our Drive class (which we used to get our second component of the checkoff - the robot drove forward for three seconds). This is a good thing, because interrupting the infinite loop didn't work, and we can't make infinity last only three seconds :). After a little debugging, our code successfully drove the robot forward for three seconds and stopped.<br />
<br />
With the actual board, we were able to attach our wheels, motors, and castor to our base. We had trouble securing all our wires to the microboard, since the crimping didn't seem to clamp the wires down all the way. We also had to short our emergency stop (due to Maslab adjusting some of the code this year) before our robot could work. But worked it did! And we got a checkoff! And then it broke again! After replacing a fuse and soldering the insides of our battery clips, our attachments were more secure and the robot worked again :).<br />
<br />
<br />
'''Things we need to fix tomorrow'''<br />
<br />
[ ] Since one of our motors were initially wired backwards, our ground and power do not follow the standard color convention. We should rewire this.<br />
<br />
[ ] Double check to see that when our code decides the robot is moving forward, the robot is moving forward instead of backwards.<br />
<br />
==January 4th, 2011==<br />
<br />
* Piper did shop training today.<br />
* Xavier did laser training today.<br />
<br />
<br />
'''Possible algorithm for robot''': 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 > vbce ^ -(d_togoal-d_towall), throw the ball over the wall, else, throw the ball into the goal. Stop after 3 minutes.<br />
<br />
'''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.<br />
<br />
'''Schedule'''<br />
<br />
Michael - Since Maslab is his main IAP commitment, he'll code in the evenings and possibly during the day. <br />
<br />
Shawn - Work until 4pm every day, code at night with Michael.<br />
<br />
Piper - Work on building between lecture (or late mornings when lecture isn't happening) and 7pm daily.<br />
<br />
Xavier - Work on building between lecture (or late mornings when lecture isn't happening) and 7pm daily.</div>Emolaguehttps://maslab.mit.edu/2011/wiki/Team_Six/JournalTeam Six/Journal2011-01-04T17:24:35Z<p>Emolague: </p>
<hr />
<div>__TOC__<br />
<br />
==January 3rd, 2011==<br />
<br />
First time writing the date this year, and I (Piper) got it right! W00! Anyway, our team began Maslab in an extremely sleep-deprived state, which made things very amusing. (I was incredibly giggly...) (I am journaling this sleep-deprived. Expect lots of exclamation points and smiley faces!)<br />
<br />
Problems we ran into with our code: our "Hello, World!" statement won't print without being in an infinite loop. We're not entirely sure why, but this problem didn't carry over to our Drive class (which we used to get our second component of the checkoff - the robot drove forward for three seconds). This is a good thing, because interrupting the infinite loop didn't work, and we can't make infinity last only three seconds :). After a little debugging, our code successfully drove the robot forward for three seconds and stopped.<br />
<br />
With the actual board, we were able to attach our wheels, motors, and castor to our base. We had trouble securing all our wires to the microboard, since the crimping didn't seem to clamp the wires down all the way. We also had to short our emergency stop (due to Maslab adjusting some of the code this year) before our robot could work. But worked it did! And we got a checkoff! And then it broke again! After replacing a fuse and soldering the insides of our battery clips, our attachments were more secure and the robot worked again :).<br />
<br />
<br />
'''Things we need to fix tomorrow'''<br />
<br />
[ ] Since one of our motors were initially wired backwards, our ground and power do not follow the standard color convention. We should rewire this.<br />
<br />
[ ] Double check to see that when our code decides the robot is moving forward, the robot is moving forward instead of backwards.<br />
<br />
==January 4th, 2011==<br />
<br />
Possible algorithm for robot:<br />
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 2 minutes, 56 seconds.</div>Emolague