Re: Poll: Best Autonomous(read the 1st post before voting)
 

I have to say that I was amazingly impressed by all of the teams on this poll. I know at first I found the way 233 let the tube out to be inefficient (every time I saw a tube touching the pvc then getting pulled back off when the gripper released a little piece of me died inside). I was so glad to see them fix that movement by Atlanta to where it smoothly let go of the tube, and it always did a great job. The same goes with how great it was seeing 79 improve as time went on. Finally, of course 1114 just.. yea, wow. I was amazingly impressed by their consistency as well. Another great mention is 148, I loved the vex model they used in testing as well (watching the 1902 and 148 vex bots chasing the scale model of the 1902 FRC bot in the pits was absolutely adorable)

In the end, and I spent awhile debating this since I usually find it to be rude to vote for your own team, I did place my vote in for 1902. The primary reason (as I ended up being an onlooker in terms of programming this year with my busy schedule) was probably more of the backend. I was amazingly proud to see the way 1902 created a very methodical vex-based system in which every sensor system was thoroughly tested before ever making a decision. Seeing in the end the programmer's making a rational choice over a pride based one as they decided to take a chance with EasyC when all of the programmers were well-versed in C was one amazing thing to see (I definitely was one of those that had trouble with that change at first). Seeing the 7 different vex bots that were designed out of parts that students donated from their own kits they had received as christmas/birthday/etc. presents was very very cool. It provided a set of tools that we were able to exchange with other teams that were trying non-camera methods (i.e. IR/Ultrasonic/etc.). So, in the end, seeing both the inside and the outside of 1902s setup this year made me step back and say "The end result is just the showcase of the amazing backend that was used to develop it as well as a plan for future years." This poll does just ask for the end result, and I feel that the process did in turn make that impression both on and off of the field. I find that as my justification to step out of my comfort bubble and make that vote.

To the teams I didn't specifically point out in this post though, there isn't a single post in this thread I don't agree with so far and all of the people in the poll itself did a great job (I was curious how some teams such as 148 didn't get into this poll, they had issues in Atlanta because of lighting but their program itself was rock-solid). Great job everybody!

Re: Poll: Best Autonomous(read the 1st post before voting)
 

1425, maybe?

I believe they used similar sensors for their autonomous.

Re: Poll: Best Autonomous(read the 1st post before voting)
 

ours would have been good if there weren't major differences between our practice bot and our comp bot... it led to disaster (with the kPID gains). Also, our camera's smashing in SF1 at newton didnt help much either.

in any case, i found 111's auto to be very amusing... their method was awesome

Re: Poll: Best Autonomous(read the 1st post before voting)
 

I agree 111's autonomous was great.

Re: Poll: Best Autonomous(read the 1st post before voting)
 

when 340 was able to score after it got knocked...that was it.

Re: Poll: Best Autonomous(read the 1st post before voting)
 

It stopped working as soon as we got it to the Championship, but worked about 75% of the time in the finals at Vegas.

It seemed that 1902 had theirs working perfectly... Then in every match I watched at the Championships it failed, what happened 1902?

Re: Poll: Best Autonomous(read the 1st post before voting)
 

The first time we missed in qualifying was due to a broken camera that we did not catch until right before heading out to the match, and the second time we missed was in our last match we decided to try out a brand new mode that went for the side goal and the rack was turned away from us just a little too far.


During eliminations we ende up having to replace one or both of our Banebots controlling our arm several times throughout the tournament and were not able to be as accurate as we had been all year.

Thanks for everyone that voted for us! The programming team spent many hours working on the robot an was a huge key to our sucess so I know they appreciate all the kind words.

Re: Poll: Best Autonomous(read the 1st post before voting)
 

I would also have chosen Team 67 they had an awesome autonomous, although they might have not been one of the fastest in scoring, they were reliable and usually mixed it up between the middle and lower spider to keep the defending teams in autonomous guessing where they would score.

Re: Poll: Best Autonomous(read the 1st post before voting)
 

Are you referring to Einstein? I think 1902, and others, had trouble with the additional lighting, although I may be wrong.

Re: Poll: Best Autonomous(read the 1st post before voting)
 

Hey all, in case you didn't get a chance to see our autonomous mode in action, here it is, minus the scores from the New Jersey regional and the Championship event, those will be included later on.

http://www.chiefdelphi.com/forums/sh...d.php?p=621018

Thanks for watching,
/dan

Re: Poll: Best Autonomous(read the 1st post before voting)
 

I know we had no issues tracking the light, the way our code is set up if it hadn't seen the light it would have stayed home (a safety measure we put in the code to avoid the autonomous doing something silly). From everything I saw I think that in the end the 1" tolerance rules probably was what hit us. I feel pretty safe in that for the fact that our camera alone has like an entire sheet of "pre-match" checks to make sure it's in specific alignment each time (since obviously a degree or two off can significantly effect calibrations) Something on Einstein was physically out of skew a little bit, but I couldn't tell you what or how to be honest. The light may have been an inch lower (which at those angles would effect the calibration the most) than it should have been or the chain a little taught on one of the spiders, I'm not sure... but something was different on Einstein from the calibration values we've used throughout the year at regionals/Galileo/practice fields/etc. and I think it caught us off guard.

At that point, when you are on Einstein, to risk an untested code change to hopefully fix that problem is too high of a risk for the possible benefit, hence why the same problem occurred in the same way each time. It's ashame, but that's part of the game! :)

Re: Poll: Best Autonomous(read the 1st post before voting)
 

Everyone that went to Boilermaker should know the answer to this one...1730!

Re: Poll: Best Autonomous(read the 1st post before voting)
 

As engineer over 1902 and over auto mode, Einstein was frustrating. I don't think anyone made an auto mode in Einstein.

Reasons for us:
Round 1. We were having arm problems and needed to adjust. Fixed it.

Round 2 and 3. Arm ok. Didn't realize this until I reviewed the tapes. Our partner hit the rack just as we did and knocked the rack ringer over just enough to make us miss. both rounds 2 and 3, they hit just perfectly 1/2 second before us and since it was right next to us threw the ringer off. In hind sight we should have run our 5 second delay which is one of our auto options.

Going from 80-95% to zero in Einstein was and is frustrating, but all part of the game.

Now I got to decide between voting for 1902 or 386. 386 had an exceptional consistency in getting lower rack and would try again if missed and got hit and still made it. 1902 was fast, could do low and middle. Oh the big decisions.

Re: Poll: Best Autonomous(read the 1st post before voting)
 

That's who I thought of but they turned it off for the championship.
Why isn't 1126 on this list?

Re: Poll: Best Autonomous(read the 1st post before voting)
 

Actually, 1425 didn't turn it off. Our lower ultra sonic sensor wasn't working correctly (possibly due to a change we made to strengthen the front end). Looking at the video, I think it almost worked in one match after we made some adjustments, but that match a defensive auto mode pushed the spider legs towards us so we were too close to score.

We really didn't want to change much since we were doing so well in all other respects. In hind sight, the reward may have outweighed the risk.

Our system consisted of 4 ultra-sonic sensors. One low on the robot, aimed to detect the base of the rack. 3 right below our gripper to detect the foot. The basic program for auto mode went like this:

deploy the gripper/tube
start to move the tube to scoring height
start moving forward - timed -
this lets us ignore our lower sensor while it calibrated
and prevented false readings in case it saw the gripper deploy.
using the lower sensor - drive to within scoring distance of the rack
using the upper sensor pod, center the robot on the nearest spider foot
robot turns right/left to seek the foot
If foot found, lower gripper - release tube - wait for auto to end
else release tube regardless at 14.5 seconds

The upper sensors were read by a custom curcuit which fed back 2 bits of target data
to the RC. The data that came back represented the possible foot locations from the
sensor pod's point of view:
Center
Right
Left
Unknown

The original plan was to have more info go back to the RC but our first cut at the communications
did not work and we ran out of time.