Okay, there is a poll out there for the best autonomous, which typically means that the robot accomplished what it was SUPPOSED to do… like scoring keepers and stuff like that.
But every now and then something goes just a bit unhinged and… well… the robot gets “creative”. We had the pleasure of putting on a show for the opening ceremony crowd at Portland… first weekend… second match of the tournament… that set a high standard for creativity and drama… if not -unfortunately - effectiveness.
Take a look here as we demonstrate mastery of the pirouette. (Thanks, by the way, to our partners (360, I believe) for putting us back into action.)
Then, perhaps, post some links to other auto modes that – if not effective – were at least entertaining.
As for the “what the heck”? Well, this is what happens when you don’t quite give the programmers enough time to test their code (a well-established tradition amongst many teams, I am sure). We had three sonar sensors on the front of the robot that were to detect the base of the rack and position us to score. Unfortunately the mecanum drive code used PID speed controls running off encoders… and used the user routines timing loop to keep track of time, but that loop was missing in auto. So while the sonar was working (I think… we didn’t usually hit anything) the robot had no clue what the wheels were really doing. Or at least that is what the programmers tell me… they had it working pretty good in telop mode, but this was our first real try at full auto. We considered a few fixes, but eventually settled for just driving forward a bit and setting the arm into position to pick up a tube. But if only the “claw” had opened and we had scored this keeper… what a way it would have been to start the year!
Wow! Those are some great clips! How 1114 and 862 did that… (the whole match is linked here http://www.thebluealliance.net/tbatv/match.php?matchid=968 ) is well… I’d say it was a fluke, but having had the honour of playing 1114 three times at GTR this year (yeah, ask how much I like that match scheduling algorithm…) I don’t think much of what they do is based on luck. That is one skilled team.
And for 340 overcoming the block… wow… that is some solid coding to deal with unexpected interruptions like that.
What I don’t see is the drive team… were they dancing along, too?
And big thanks, by the way, to the people who have been cutting and encoding and hosting the video, so that we have the luxury of saying “take a look at THIS”. It is a real treat and really appreciated!
I would like to nominate 668’s “wavy arm dance” from SVR. I don’t know which match it was, or if it was even intentional, but it was amazing. I’ll try and find on soap if I’ve got time…
i would like to nominate the joint team 8/1425 from LVR semis. We shook the rack, took off a diamond plate, and 1425’s ringer bounced onto the rack. That said, we were on different alliances.
I don’t have a video of it, but in one of our first practice matches in Atlanta our robot “Break Danced.” Those who saw it will agree that it was one of the most extraordinary auto-modes of 2007.
Our robot raised its arm to full height and bounced in a circle for 30 seconds - at each moment almost loosing contact with the ground :ahh:!
It was one of the most terrifying sights I have ever seen…
This was NOT supposed to happen, and it resulted from mechanics related turning problems that were later solved with omni-wheels.
you beat me to it, i was just about to post that but i wanted to find it first. That was pretty much amazing, that ended up being the highest scoring match of the regional, it was pretty exciting! you guys were really great, team 8. and thanks yet again to error code and the poofs! we were cheering for you guys in atlanta! it was almost as much fun as if we had been picked! we hope to see you all again next year!
Lol that first one is good. We had one in the first match of finals at UCF. We accidentally left it in “Kill Mode” which was meant to go across the field and cut across the rack. But we meant to “do nothing” here. So instead it took off in high gear and nearly took out both alliance partners by and inch, but somehow didn’t hit anything. This match we discovered our arm was broke from the previous match as well, and had to play some defense.
Our robot did something “entertaining” during an early match in St. Louis. We had just finished up our drivebase PID tuning, and had a simple “drive forward six inches” mode selected as a final test. Apparently, one of our wheel encoders developed a broken connection, so the software acted as if one side of the robot was nailed to the floor. What we saw on the field was this:
The 'bot deployed the arm, did at least two full turns in one direction while managing not to scrape the gripper against the field boundary, stopped, did it again in the other direction, ran diagonally across the field, barely missing both alliance partners and the rack, then stopped a few inches short of crashing into the field boundary on the other side of where it started – not intentionally, but because autonomous mode was over.
“Drive forward six inches” had turned into “drive forward enough to measure 6 inches even with one side not moving, turn in place trying to correct the measured yaw error, overshoot because the robot is actually spinning twice as fast as the software thinks, turn in place the other direction trying to correct the overshoot, get the correction right this time because the too-fast turn is compensated by a too-fast correction, then take off at full speed trying to correct the accumulated position error.” That was what I eventually decided was going on in the program, anyway.
The most entertaining autonomous of all-time is 229 robot Irrational at FLR last year driving forward and suddenly turning on a dime and firing all of it’s balls at Steve.
Comedy gold!
Jason, that certainly is a standard to aspire to. We had a post-hook dance which we kept under wraps until we were sure of our autonomous. Since it was inconsistant (due to the field lights, not to the programming), it will have to stay hidden. Probably all the better. I will keep the video for future study and when the programming crew needs a project.
I like the one you guys did at Purdue better. Andy told me the plan was to go around the rack to the backside but when your robot went screaming into the spider leg at full speed I thought the whole armory shook. What was amazing was that the whole top of the robot didn’t come off. Great construction.
We had this automode, code named “Back in Black”. We would back up, full speed (13 fps), stop, and then look for the light. The plan was to place a tube on our opponent’s side of the rack. The only time we would ever plan to use it was if we were opposed from a robot that did not move (would not want to ram them), and our partner was going for the middle column in auto.
So… during one of our Q matches at Boilermaker, our drive team decided to try this. The robot went full speed, backwards, and hit the left side spider legs. The spider legs resisted the impact and tipped the robot over. Either the drive team did not aim the robot correctly, or the robot veered to the right too much while backing up.
The head ref was ticked at us for that one, and said that if our drive team did it again, they would be DQ’ed for field damage.
We did not run that mode ever again, even at the Championships.
I have still not seen a video of that match. If I find one that is digital, I will post a link here.
The unfortunate thing about this was that a reporter from our hometown newspaper just happened to walk in to the arena at this same time as this match. While we explained what exactly happened, and what “automode” was, he could not understand that this was simply an aiming error. In the next day’s paper, the writer talked about our mistake in how we wrote the code, and how the drivers should have chosen to drive during this part of the match. He just could not get past this dramatic wreck and didn’t understand that we actually meant to send our robot backwards that fast.