2009 Finger Lakes Regional!!!!

[Doc Wu]

On behalf of Team 1507, the Warlocks, I'd like to say thanks so much for giving us the opportunity to represent the Fingerlakes Regional as a champion. We are in truly elite company.

Our alliance mates, Team 188 and Team 174 were awesome and a pleasure to work with. We couldn't have asked for better teammates.

All the teams in the finals were close in skill and quality. We would have been proud to have teamed up with any of them, unfortunately, each alliance can only have three teams!

We’ve really gotten to know so many excellent teams and to be honored in winning the regional championship among them is not only an honor, it’s humbling as well. To think our little team from Lockport can rank among so many great teams we’ve looked up to, is mind-boggling.

Thanks for a great time. We'll see you all at other regionals, or next year.

[rees2001]

We had a great time at FLR. There were some issues with the system but everyone worked to make sure everything was FAIR. THe ref's were great, Liz was an amazing FTA, & Pete was an awesome addition to the feild team. Thanks to all of the volunteers who worked to make sure all teams were able to compete. It was unfortunate that the field caused some losses. It is part of the game.

On behalf of 340, thank you to 1511 & 316 on being such great alliance partners, good luck at your next Regionals.

On behalf of 424 thank you to 1126 & 2228 on also being such great alliance partners. That was a tough loss & you all handled it with class. You should be proud.

1547, congrats on your IE. 1511 congrats on your CP&B Award, Good luck at your next 2 regionals. I know you will rock!

1507, 188, & 174 - Congrats on the Regional victory. You guys were amazing! Good luck at your future events.

[OScubed]

2009 Regional photo gallery: http://rollingthunder.smugmug.com/ga...86420135_VbijZ

2009 Regional video gallery: http://rollingthunder.smugmug.com/ga...87958214_NB6Sr

Courtesy of Team 1511, Rolling Thunder!

[Kricu]

Originally Posted by SlimBoJones

This was a brilliant move. We simply got baited into an extremely vulnerable position, and paid for it dearly. It was a perfectly executed reversal, and cost us the match.

I made the call to try and score on 3015 as they were stationary at their own airlock delivering an empty cell to their payload specialist. Normally you'd think this is a good opportunity to strike a stationary target...

We thought so too, and it ended up costing us the match.

Great work 3015, 2053 and 3003! We learned a lot that match, and that sometimes the best shots in Lunacy are the ones you DON'T take .

I'm not going to lie you guys were a great alliance. You definitely deserved to win it all. I did cry a little bit when 174 changed their autonomous so it turned in the beginning so we couldn't pin them from the start. I'm glad we taught you not to get stuck in the corners and to make sure you didn't get pinned during the autonomous so I could score 15+ shots on 174. Anyways nice job winning it.

[Pat Fairbank]

Originally Posted by esquared

1503's Robot Signal light would go fully out, then blink fast, then come solid again. Once they began to try driving again, the RSL would go out, blink fast, then solid again over a period of roughly 30-45 seconds. While they were located at what was eventually found to be a faulty console location, the robot symptoms they experienced are not possible if the robot was being E-Stopped intermittently. If that was occurring, their RSL would be solid, then go to a slow blink, then solid. If it was an intermittent radio communication issue, the RSL would have gone into a fast-blink mode if the bridge lost contact, then come back solid once regained. I spoke with 1503 immediately following that match, and their drivers agreed that the RSL was doing precisely as I explained above. We then powered up their robot, and showed them the process the RSL light goes through after a reboot. While the robot was on, I showed them what would happen if the radio modem power/ethernet was pulled loose/plugged back in, and the process was also as described above. They seemed satisfied that the symptoms of their robot out on the field matched a poweroff/poweron rather than an E-Stop.

To the robot, the E-Stop button is a disable/enable condition no different than using the dongle normally attached to the competition port. This was evident from the match in finals where the faulty E-Stop was diagnosed. Team 188's robot would sit with their RSL light slowly blinking. This indicates a successful link with the Driver Station, either through the field or when tethered. If the E-Stop was rapidly toggled/intermittent, 1503's robot would have been going in/out of enable mode, thus the RSL would be solid/slow blinking.

I regret not having the chance to follow up with 1503 to determine exactly what their situation was once they were in the pits. If anyone from 1503 could contact me/post if you found anything specifically wrong with your robot following that finals match it would be appreciated. I can add your situation to a list of common robot 'gotchas' being compiled.

I'm afraid we found nothing. We checked every terminal and every wire from the battery all the way to the cRIO. We then tethered up and drove the robot around (with the same battery); it worked fine. We rammed it repeatedly into a wall to see if there were any loose connections to dislodge; nothing. We always run electrical checks between matches, and we always zip-tie our battery connectors, and we didn't experience a single electrical problem at FLR up to that point. I guess I don't believe in coincidences...

[esquared]

Originally Posted by Pat Fairbank

I'm afraid we found nothing. We checked every terminal and every wire from the battery all the way to the cRIO. We then tethered up and drove the robot around (with the same battery); it worked fine. We rammed it repeatedly into a wall to see if there were any loose connections to dislodge; nothing. We always run electrical checks between matches, and we always zip-tie our battery connectors, and we didn't experience a single electrical problem at FLR up to that point. I guess I don't believe in coincidences...

Pat,
Thanks for the followup. I will add your issue to the list of things to try and reproduce given what we saw on the field with regards to the RSL and the eventual situation with the center console's E-Stop.

If you were able to watch the robot's operation from your position in the audience/driver station, do you agree the Robot Signal Light was behaving as specified in my post? I'd like to have everyone on the same page regarding robot symptoms to ensure that NI/FIRST have accurate information regarding what happened.

While I'm not privy to the design details of the cRIO or the DS (I'm just another mentor), the only way I know of to remotely restart a cRIO is to issue a 'reboot' command on a console connection to the RIO, given your confidence level in the power system and ability to ram your robot into the wall (understandable after what happened).

While I don't normally believe in coincidences, your bots behavior matched a brownout or reset condition on the cRIO. I did go over the robot's power and data connections with your drive team immediately after the match to try and identify if there was anything loose, possibly anything that was wrong with your bot on the field was fixed when checking the connections. That's a pretty farfetched theory however, as while they were doing that I did not see any sketchy connections

[kevin.li.rit]

Everything seemed ok... The only think I'm scratching my head about is the one time our autonomous did not go off.

[esquared]

Originally Posted by Coffeeism

Everything seemed ok... The only think I'm scratching my head about is the one time our autonomous did not go off.

Depending on whether all DS's are detected during the initial match setup (before robots are out on the field for the next match), the FMS seems to briefly toggle through Auto-Disable, Auto-Enable, then Auto-Disable as it sets up. This caused a number of teams using both WindRiver and Labview who did not take special precautions to ensure that enabling and disabling in autonomous mode would fully reset their code each time to malfunction.

Specifically in WindRiver, if you do not override StartCompetition() and extend RobotBase instead of SimpleRobot for your main class, it is possible to begin executing code in your Autonomous() function somewhere in the middle, or to be caught in the "while (IsAutonomous() && !IsDisabled()) Wait(.01);" line in StartCompetition. This occurred with both 211 and 229 in the same match, and after they updated their code to cover this case did not experience a problem again.

Teams can test this in the pit by having the DS in Auto-Dis, turn their bot on, then toggle to Auto-En, quickly back to Auto-Dis, then back to Auto-En and verify their program works as expected. Also, teams should verify that after this occurs they correctly enter teleop code after going to Auto-Dis, Teleop-Dis, then Teleop-En. When reproducing this in the pits, 211 malfunctioned exactly the same way as they did in the field. Once updated they drove correctly in auto and teleop.

[Bongle]

Originally Posted by esquared

If you were able to watch the robot's operation from your position in the audience/driver station, do you agree the Robot Signal Light was behaving as specified in my post? I'd like to have everyone on the same page regarding robot symptoms to ensure that NI/FIRST have accurate information regarding what happened.

Which match did this problem occur in? I wasn't able to watch the finals, but someone else on 2702 managed to go down and take some HD footage of some of the quarterfinals. I might be able to pass along some footage if I can find this problem occurring in what I have.

[esquared]

Originally Posted by Bongle

Which match did this problem occur in? I wasn't able to watch the finals, but someone else on 2702 managed to go down at take some HD footage of some of the quarterfinals. I might be able to pass along some footage if I can find this problem occurring in what I have.

QF3 Match 2

[Tetraman]

Originally Posted by Kricu

I'm not going to lie you guys were a great alliance. You definitely deserved to win it all. I did cry a little bit when 174 changed their autonomous so it turned in the beginning so we couldn't pin them from the start. I'm glad we taught you not to get stuck in the corners and to make sure you didn't get pinned during the autonomous so I could score 15+ shots on 174. Anyways nice job winning it.

That match was the highlight of the entire regional, and probably the entire week 2. It was just as incredible as watching 71 and 1114 getting defeated. You three teams deserve so much more credit for that tactic then you are given and I tip my hat to you for the accomplishment. As much as I love my old team 174, I was so excited to see you win that one match and I did root for you the other matches.

It will be one of the many great moments of this regional that will be talked about for years.

[petek]

Originally Posted by esquared

Depending on whether all DS's are detected during the initial match setup (before robots are out on the field for the next match), the FMS seems to briefly toggle through Auto-Disable, Auto-Enable, then Auto-Disable as it sets up.

According to FIRST this is not the case. Rather, what is probably happening is:
1. The robot is powered up before the driver station acquires a DSlink (which occurs within a few seconds of plugging in), e.g. before plugging in;
2. The driver station's Auton/Teleop switch is set to Auton;
3. The driver station is plugged in, immediately links to the already powered-up robot and sets Auton-Enable;
4. The driver station acquires a DSlink from the FMS and sets Auton-Disable.

This could be prevented by ensuring that the driver station has a DSlink (it will show FMSMode on the display when it gets it) before powering up the robot. Setting the driver station Auton/Teleop switch to Teleop before plugging in should prevent jumping, but the robot might still get a brief Teleop-Enable if it was powered up before the driver station linked.

[Bongle]

Originally Posted by esquared

QF3 Match 2

I have it, but I only have a stable shot of 1503 and their RSL for 5-10 seconds total throughout the match. The camera man was concentrating on the moving robots, and would only glance at 1503 periodically when they were not moving. If you think it'd be useful, I could edit the 1503 portions tonight.

[esquared]

Originally Posted by petek

According to FIRST this is not the case.

Thanks for the update here Pete. Anyone reading this thread should be aware of this and ensure your auto and teleop mode code can handle this occurring and not flip out!

Originally Posted by Bongle

I have it, but I only have a stable shot of 1503 and their RSL for 5-10 seconds total throughout the match. The camera man was concentrating on the moving robots, and would only glance at 1503 periodically when they were not moving. If you think it'd be useful, I could edit the 1503 portions tonight.

It would absolutely be useful, thank you!

[carbuff]

thanks alot 1126 and 424 you were great alliance partners sorry our robot broke down