Diary

JEFF

JEFF

Date: 2-07-14

– The robot as completed the second performance test perfectly, so we are good for now! A must admit, I am very happy with the design. Even looking at other designs of the other teams, I think ours looks the best and has the least amount of problems to deal with.

Date: 3-07-14

-The robot is going well as possible, completing some objectives easily and others with difficulty. The notebook seems to be the weakest part, and I am very displeased with it so far. I have also been lacking in overall time maintenance, as my teammates have been forced to help me with projects assigned to me. Hopefully starting next time we meet, I will be able to make everything better. We have been lacking in minutes, diary entries, and updates overall. Overall, I am not content with my actions and my work. It must be changed.

Date: 3-19-14

-As of now, the first report draft has just been completed. In terms of the robot, it is on the verge of depositing the scoop and thus completing every task. I am not very happy with the notebook as of now; I believe it could be vastly improved. The draft of the report turned out fairly well, but it can most certainly be improved. I have to make sure to stop falling behind and rushing things at the last minute.

Date: 4-2-14

-Been a good while since I’ve updated this. Everything has been going fairly well. We placed well from the individual competition. The assignments could go better, but I plan for the end reports to be very good. The robot is running well, and it seems that we should be a lot more consistent soon. No worries other than getting things completed.

Date: 4-19-14

-All competitions are finished, the presentation is over, and all that remains is the journal and final report. I must say I enjoyed the process as a whole, though I do have some regrets. I would have enjoyed a little more input towards the design, though I am very happy as to how it came out. I also wasted much of our teams time with the assignments. I am just too lazy sometimes. My teammates deserved better, but as long as it works out in the end. The end?

AARON

AARON

Date: 2-7-14

– Today we tweaked the timing on our basic driving script. Our tests yesterday had the robot turning too much, then too little. Our new turn length worked, but we had to position the robot closer to the ramp at the start of the run. Once we did that, we were able to consistently complete the Performance test. Started to work on mounting the CdS cell and button pusher. Decided on erector set angle for both these parts, and then placed an order.

 

Date: 2-7-14

– Not mucch got done in class today. Just machined the erector set piece to mount the cds cell and wooden pegs for chain tensioners. Met up after classes, and immediately took a dive in the deep end with debugging code. Next time, we will make small changes and compile often. It was not fun. Once the code compiled, our CdS cell code worked perfectly and we never failed to start with the start light. We mounted a makeshift button presser and tried to push the button, but only did so once, because our turns were so inconsistent. I like where we are, but we need to be able to turn consistently if we want to do anything.

 

Date: 2-13-14

– Today we learned that our robot is shy. I class, we did the RPS and encoder lab. We met up at 5:20, Luke soldered, Dan mounted our new IR beacon, and we all programmed the new PT2 script with RPS. Worked great until we took a phone out and the robot got camera shy. We were chasing consistency issues all night, but finally got a few good runs in at the end. The robot also retreats rather shyly when you press its limit switch.

 

Date: 2-17-14

– After a poor performance test on friday, in which we failed to press the button 5 times in a row, we regrouped this afternoon to finish the lab, and correct our button-pressing situation. The lab was simple, and we got a pre-made, shaft-encoder-outfitted robot driving around with no hassle. We then ordered some erector set parts for a newly designed button presser that has a much wider are that it can touch the button with. It also has structual integrity, and doubles as the switch flipper and pin toucher. Jeff assembled the new structure while the rest of us finnished the lab, and when we tested the button routine again, it worked like a charm! We need to get shaft encoders on our robot by friday. Kevin gave us the idea of removing the shaft of the rotary encoders and using those. We will give it a go soon.

 

Date: 3-2-14

– A lot of stuff to catch up on. We passed performance test 4 with flying colors. The new button pusher, switch flipper and pin toucher structure worked well. Our robots biggest weakness is still the button pusher, once it pushed the button, everything followed without a problem. After the performance test, we upgraded the code to allow us to turn to an absolute angle using rps. It worked as well as – or better than – the previous setup where we turn a certain number of degrees from where the robot is now. We designed a servo-powered pvc forklift to serve as our pin puller and skid lifter, and machined the parts on Monday, 2/24. We also added a micro switch at the top to sense where the pin was. However, we found that since the pin kept spinning our of the way, it was MUCH more consistent to move the switch and sense the pvc tube. We passed PT5, and barely missed the bonus of moving the skid. Apparently, the servo is strong enough to lift the skid, but the skid has to be completely on the forklift for it to have enough torque. Luke and I are woking on getting a completely new code structure nailed down. Right now, we have pretty much all of the overhead done, and we just need to re-implement som eof the nuts and bolts. The new Command based structure looks promising for failure correction, and Luke is working on a pathing algorithm in case our robot goes off course.

 

Date: 3-6-14

– we’ve been tweaking PT6 all week, and we finally made some headway last night when Luke and I added a drive back command as the robot pulls the pin. The pin now comes out every time! Now, we just need to drive reliably back to the x position of the skid. which is harder than it looks. We tried two performance test runs on wednesday, and both were struck down by murphy’s law before we even got close to the skid. The robot sometimes lurches randomly at the beginning of its run and then starts driving off at an angle, ruining the entire run. Once we get the pin and get to the skid, however, the rest of the performance test is easy. We should be fine come friday.

 

Date: 3-19-14

– PT6 didn’t end up working too well (15/20 points, we missed getting it in the chiller). We learned a lot of lessons. In the end, it was the fact that the servo barely has enough torque on it to lift the skid that got us. I ended up adding some rubber bands to the arm over spring break to help with this. We also had issues with the bolts sticking out of our drivetrain getting stuck on field elements near the ramp and the chiller. Over spring break, I revamped the drive train, flipping the bolts inside and replacing them with shorter ones. We ended up designing and building a simple scoop dumper box out of hot-glued pvc (leftover pvc, so it was cheap). Works great, except for the structure holding it up. We will need to add structure before pt7. We had a really long debuging session with the new code on monday, and Luke and I decided to switch back to the old code. I think it will help us in the long run because it was much simpler to maintain. We will be implementing a script chooser in that code so we keep that benefit.

 

Date: 3-26-14

– Individual competition is in 2 days, and I’m very excited. We have now completed 3 perfect runs, and most of our run is very consistent. My favorite part that we added yesterday is PID (actually just P) control to get the robot to drive along a specific x-coordinate in order to get from the ramp to the switch. It also adjusts for the heading of the robot, so the robot arrives at the switch with the correct heading. The constants were tuned so that when the position error is large, that factor dominates, and when the position error is small, the heading factor dominates. We tried doing this same thing to get down the ramp, but it ended up being inconsistent. One reason it was inconsistent was that the RPS x-coordinate varied up to 4 inches between courses, which renders it almost useless for getting down the ramp. Some tweaks to the script: using line following to get to the SKID, and turning a bit to get the skid into the chiller. Getting down the ramp is still our biggest inconsistency, and we’ve tried multiple ways to deal with it. I’m stoked for the competition, and I think we can pull off a (near) perfect run.

 

Date: 4-5-14

– Final competition was today, and it was quite a roller coaster for us. We came in with high expectations, seeded 10th overall, and the 3rd seed in our bracket. We went out to test the lights on the course (after they changed the overhead lighting in the stadium) and had to change our thresholds for the CdS cell reading the scoop light. We made the changes, tested by recreating the values with my phone, and then went to do a full test run on the official course. It was perfect until we tried to pick the skid up, and we just didn’t have enough power. I also think that the skid was wedges under a piece of acrylic, making it hard to pull out. That ended our only practice run. We then made the rubber bands on the arm a little bit tighter to provide more torque when lifting the skid, tested it several times on the non-official course, and called the issue fixed. The next issue that we discovered was that dirt, etc. was getting on our wheels a LOT faster than usual, and it was affecting our turns a LOT. We decided for the rest of the day to manually wipe off our wheels before every match, and the problems didn’t happen again.

– Now onto the 3 round robin competition rounds. Our first round was a disaster. So was our second. And our third. In the first match we started out by immediately losing RPS connection, and overshooting the turn to the oven. Miraculously, the robot managed to navigate back to the switch, square up, and resume the pin pulling part of the script fine. We then messed up when we were squaring up to the chute to go down the ramp. We overturned, and the robot clipped the chiller, and missed the turn down the ramp. We watched as it drove blindly on the ramp, and then killed the run once it had the skid in the shop and the scoop on the shop floor. 40pts total. I later realized that the reason we lost RPS in this match was that I initialized to region D, when we were actually in region H (both were the blue courses). In our subsequent rounds, we made explicitly sure that we initialized the correct RPS region.

– Our second round robin was slightly better. We got the oven button and bonus, pulled the pin, and then failed when we were line following towards the pin for the second time. The robot pulled back like normal, started line following like normal, and then inexplicably stopped. It timed out, went into failure mode, and then had no chance of finishing, so we stopped it. During line following, the robot should never stop even if it is incorrectly reading the line. It couldn’t have even been stalling against anything. Also, because we had to crouch as we watched the match,, we didn’t have a vantage point to diagnose the problem. We never found the cause of this, didn’t make any changes, and it never happened again.

– In our third round robin match, we were perfect until we picked up the skid. The pin had fallen on the floor, causing us to square up the the wall behind the skid improperly. We then clipped the chute on our way to the ramp, almost corrected the run, but then clipped the chiller on our way down the ramp. The robot then went crazy, going down the ramp, up the ramp, and down again. We stopped after the skid was in the shop, but the scoop had been dumped in the factory, so we got a total of 40pts, 8 of which came from the button. In all of our round robin matches, we never made it down the ramp as planned, so we had a lot of improving to do. The error in our 3rd round robin was deemed random and out of our control because of the way the pin fell. We made no major changes going into the elimination tournement.

– Finally, after three rough, stressful, disappointing matches, something went right. Everything just worked, and we got a perfect run, minus hitting the charge zone button. 89pts. Also, the charge zone button on course A (which we were on) had been known to be unusually stiff, and many other robots had failed to press it. The judges were very nice explaining that they didn’t hold it against us. We advanced to the Sweet sixteen anyway.

– In the sweet sixteen round, we got 88pts. Perfect, except we misread the red scoop light as blue. We were all extremely excited when we found out we were going on to the finals. It must’ve been our luck because our scorer for this match (and the finals) was Kevin, our TA.

– The final four. The atmosphere was incredible, with all eyes on our four robots. We had exactly the same run as in the sweet sixteen: perfect except we misread the scoop light. We finished last, with 8 seconds to go, but we knew we had a good run. My favorite part was when all of the scorers asked the course master how many button presses each team got. He yelled out “4 [button presses] all around,” and everyone cheered. It was pretty awesome that we played against some amazing competition. In the end we got 3rd place in the finals. 1st place, team F3, got everything except the skid in the chiller, and beat us by 1 point. 2nd place, team G1, got exactly the same score as us, but beat us on time. 4th place, team F8, had some issues with their scoop and scored in the 70’s. No one was perfect, but it was still an incredible match. Great sportsmanship all around from the other teams, and we had a blast. Talking to F3 after the match, it seems they had a similar day, where they didn’t do well in round robin, but then found their stride in eliminations. Congrats to them.

DAN

DAN

 

Date: 4-19-14

This has been a very successful robot design project. After weeks of hard work by the whole team, we did well in the individual competition and won third place in the final competition. Our presentation of our work and progress this semester towards the robot went very well too. Overall, this project has been a very positive experience.

 

Date: 3-21-14

We passed the performance test for this week with full points, including bonus. After two initial runs in which the robot lost RPS signal and was slightly off in position at times, the third run worked perfectly. With all of the performance tests completed, we now have to prepare for the individual competition next week. Part of this requires creating one script that includes all of the tasks the robot has to do, as now we have a different program for each task. The robot has performed well overall, and it is looking good for the individual competition.

 

 

Date: 3-7-14

This week’s performance test involved lifting the skid and carrying it down the ramp and into the chiller. The robot worked perfectly numerous times in practice runs, but didn’t get all of the points during the official performance tests. For example, the robot would lose the RPS signal, get caught on the walls of the ramp, or not have enough power to lift the skid once the arm was placed in it. To fix this, we will load the arm with rubber bands and replace the outside springs with shorter ones.

 

 

Date: 2-28-14

We put a lot of work into the robot this week. Most of the time was spent on designing and building the servo arm that was used for this week’s performance test, in which we had to start on the light, touch and remove the pin, and then drive down the ramp. After building the arm, we found we had trouble with our approach: the microswitch on the end of the arm was not consistently pressing when it touched the pin, because the pin kept rotating when touched. Aaron had the idea of having the switch make contact with the back tube, which was stable. We moved the switch to the top of the end of the arm, and this strategy worked very well. We were able to remove the pin and drive down the ramp. We got full points on this week’s performance test, besides the bonus points of moving the skid: the servo wasn’t strong enough to lift the skid like we had planned. We will have to figure out how we can get enough power to lift the skid for next week’s performance test, but this was a very productive week.

LUKE

LUKE

Date: 2-7-14

–

Date: 2-10-14

-Today, we spent most of the time focusing on trying to get the robot to touch the oven button.  It would touch occasionally but the turns of the robot were incredibly inconsistent so it would only touch the oven 1 out of every 7 times or so no matter how much we tweaked it.

Date: 2-13-14

-yesterday we mostly focused on getting the robot to touch the button on the oven and integrating the RPS system.   Previously, when we tried getting the robot to touch the oven button the turns that the robot made were incredibly inconsistent and it was nearly impossible to touch the button.  The RPS helped a lot in that respect, but the robot still isn’t exactly consistent when it comes to touching the button.  It should suffice for the test tomorrow.  The robot is still pivoting exclusively around its back wheels.

That can be a good thing for consistency but, theoretically, a 4wheel drive system should pivot around the center (lengthwise).  It is probably due to the fact that the back wheels have a lot more friction than the front wheels.  We should be careful not to add too much weight to the front of the robot in order to keep the robot’s turning patterns consistent.  The 4-wheel drive should be allowing the robot to drive in very straight lines, which it is doing very well, but I would like to see if the robot would still drive straight without the 4-wheel drive in place.  If it still does we might want to consider scrapping the drive chains as the could very well be more trouble than  they are worth at this point.

 

Date: 3-28-14

 

Today was the first individual competition.  overall, we did well but bad luck prevented us from doing better.  The first run we scored 20 points and completed the button, and pin tasks.  The line following, however, failed on the skid and we drove into a corner and got stuck.  On the second run we only got 5 points becuase of an RPS error that cause us to turn 180 degrees too far.  On the third run, we got 40 out of 50 points, getting everything except for the charge zone and button.  that was the highest score in our class, meaning that we got 15 extra credit points added to our grade score for a final grade of 55/50.  Overall, pretty good day.

We are still tweaking things, eliminating bugs, and increasing the margin of error wherever we can.  current plans involve adding a sponge to the button presser so that we are less likely to miss it by a fraction of an inch.  We are also considering having the robot constantly keep track of its own calculated heading, as opposed to using the RPS heading data, in order to eliminate a handful of bugs in our turns which are currently primarily RPS based.  We are looking strong heading into the competition, but we will continue to tweak the robot and its code in order to decrease the chances of any small hiccups, like those that happened at the individual competition today.

 

Date: 4-19-14

The Robot competition is just about over now.  The final competition has passed.  Our robot preformed very well, we got about 40 points in each of the round robin runs, and we managed to get third place in the elimination round.  The final oral report went very well.  We finished on time and the TA’s we talked to said we did very well.

 

The DROID “Millennium Falgon”

The original idea (given by our professor Mr. Clingan) was to have a diary from the perspective of the robot. This did not come into fruition however, as the head of journalism for the team did not put too much thought into the idea. Instead, here is a small summary on the life of the robot.

-First named R.O.B. by Jeff, based off of the popular Nintendo character/peripheral.

-Name changed to Millennium Falgon by Luke, based off of an inside joke.

-Another unofficial name was given to the robot as part of the joke: Captain Falgon.

-The robot has been adorned with two flags in its life, first by the “OSU Banner” and then the “Falg”.

-EPA Estimated Mileage by the robot: 64,000” = 1.0 miles.

–-Aaron calculated that the robot squared to a wall over 1000 times during its life.

-Aaron also calculated that the robot picked up –34 lb of total SKID weight.

-We are working to keep the Millenium Falgon operational without the proteus. Currently, It has full driving functionality, and is controlled by an Arduino.