NJ Elim Yellow Card Oddity

[Danny McC]

Yeah. It was our fault and we know that. We changed our autonomous and we didnt know it was going to do that.

[mtaman02]

Originally Posted by TdorTheBnator

Yeah. It was our fault and we know that. We changed our autonomous and we didnt know it was going to do that.

Yea but see thats why we have a practice field and if you can't get on it then you can just chock it and count the sec's that go by and adjust from there. Ok it's an honest mistake but it was correctable before this should've even happened. Thankfully enough the teams that play in FIRST are cool headed people and just get upset at the mis-fortune and don't try and retalliate back.

[thefro526]

Lol we did that and it was a mistake from our programmer/possible IR interference. We personally as the alliance did not get bothered by the yellow card.

[Elgin Clock]

Originally Posted by thefro526

Lol we did that and it was a mistake from our programmer/possible IR interference. We personally as the alliance did not get bothered by the yellow card.

Not to be harsh to you, but it doesn't really matter if you weren't bothered by the bad call, or penalty assignment given to you.
I know exactly where you're coming from with that statement though, and felt the same way when some calls were missed or made against us and didn't affect the match.
When it does affect you that's really when you start to care though.

It was wrong, and I am glad Kevin caught this.

When things are caught in week one then that leads to updates changing the game from week to week... This is (kind of) inevitable, but also a gray area as well due to an unfair advantage/disadvantage seen by some earlier competing teams when rules change/get more clear.

Bottom line, a bad call that doesn't effect you per-say is still a bad call, and the teams watching the competitions with a fine tooth comb on the rules, and trying to get a feel of how the game will be played (especially in a week one regional setting) are confused when they are made no matter how it affects the outcome of the game, or even just your one match it just happens to take place in.

[dpc131]

Just some additional clarification on the situation. There was some comment on test prior to loading new code. If we can remember 2006 was infamous for changing code on the fly to block good shooters. This was extremely effective a lot of the time. There is some risk with using this approach and this is what can happen. 816 added in some last minute changes so we didn't collide in autonomous and some unexpected results happened.

What frustrated me most was the FIRST's IR receiver implementation and the unexpected results when using in a match. I think alot of the hard crashes were robocoach's signals not being received due to range/interference. Like anything, this is an engineering issue to be looked at during design of the robot, but this is a topic for another time. But again I see FIRST has sent something to the teams to implement that has not been proven (IR receivers in 2005, Camera in 2006, etc.)

[pakratt1991]

I saw this same thing at the Oregon regional. A teams hybrid mode hit the other wall at high speeds and it tossed a teams controller to the ground. There were no yellow cards given and the refs just said that teams needed to secure their controllers. We used 3 long strips of Velcro and that worked fine.

[chaoticprout]

Originally Posted by mtaman02

Yea but see thats why we have a practice field and if you can't get on it then you can just chock it and count the sec's that go by and adjust from there. Ok it's an honest mistake but it was correctable before this should've even happened. Thankfully enough the teams that play in FIRST are cool headed people and just get upset at the mis-fortune and don't try and retalliate back.

Firstly, I wasn't there so this may be off. However, I respectfully think this statement is insulting to the teams. When in competition with people screaming at you telling you the robot needs to get to competition, and not having the ability to go to the practice field, how does counting the seconds let them know if they have gone too far. If they were at home testing code I would agree, but this is during the stress of competition, and it's bound to happen. It's a part of FIRST , not something that should never happen. Not all mechanical elements of robots work, why should all the software? Don't blame the programmers. =(

[Matt H.]

I personally believe that with the amount of potential interference etc such a call should not have been made. As noted in earlier matches the lap counters are IR emitters and it often becomes uncontrollable. With the number of variables involved in coding it is unreasonable to expect a program to work perfectly after having been warned once.

On a side note why not have lips on the player stations. This would stop OIs from falling far more effectively than velcro and would enforce the size limits as prescribed in the rules.

[mtaman02]

Originally Posted by Matt H.

On a side note why not have lips on the player stations. This would stop OIs from falling far more effectively than velcro and would enforce the size limits as prescribed in the rules.

I thought about that yesterday exactly. Don't be surprised if a control deck specification comes out in the '09 game. Right now the specs say it must fit the current level deck. I think it's time that deck had like a 1/2" lip on it and lock down bars to keep the controls from jumping up. Velcro will wear out too easily if every team used it.

[thefro526]

Also on of the things we thought was that you had one warning before a yellow card. Our programmer made a small adjustment to give the robobees time to clear and we had no idea that the entire system of timers messed up so thats what put us into the wall. It was strange because our auto had worked flawlessly throughout the competion

[mtaman02]

Originally Posted by thefro526

Also on of the things we thought was that you had one warning before a yellow card. Our programmer made a small adjustment to give the robobees time to clear and we had no idea that the entire system of timers messed up so thats what put us into the wall. It was strange because our auto had worked flawlessly throughout the competion

thats odd then, I don't think I remember talking w/ the FTA personell about how well the timers were performing. They couldn't have been that bad since they still were using them this entire event. I mean they had a manual counter as well to make sure that all was ok. Hmmm... Well if the Counters could be whats causing some issues then maybe they'll be a fix for it by week 2. *ponders now*

[thefro526]

lol our programmer put our wait sequence in the wrong spot he told me so himself our other auto still works great, and it was my decision to add the wait in the program so yeah... I like the yellow card though it gave us character lol. Also our auto had been so successful earlier in the competition because we didn't have to worry about other people running. For dead reckoning (no sensor input) we did pretty well getting our three lines.

[mtaman02]

Originally Posted by chaoticprout

Firstly, I wasn't there so this may be off. However, I respectfully think this statement is insulting to the teams. When in competition with people screaming at you telling you the robot needs to get to competition, and not having the ability to go to the practice field, how does counting the seconds let them know if they have gone too far. If they were at home testing code I would agree, but this is during the stress of competition, and it's bound to happen. It's a part of FIRST , not something that should never happen. Not all mechanical elements of robots work, why should all the software? Don't blame the programmers. =(

If the robot is on chocks, you can watch the motions of the drive train and count down 15 secs. Mark a part of the actual tread / wheel and count the rpms and if it appears that the drive train is too fast and has gone no where but in that direction then adjust the program accordingly to try and slow down the robot OR put a turn command in that way it'll at least nail the side barrier and not the player station b/c to be honest there's not much holding that player station in place to start with but it's little bit of weight, some support from around the field and velcro. Why do you think it moves so much when ever it gets hit? I personally think better re-inforcement of the player stations will solve some problems of the decks being flung to the floor after being nailed by a robot doing 30mph. Look at the team who lost their entire OI b/c the Comp Port ripped right out of the OI after the wall took a hard hit from one robot.

I forget which team and what local event I saw this at but it worked... The practice field was unavailable for w/e reason so they chocked it, had a person with a stopwatch, had another person watch the drive train movements and guess how fast it was moving and adjusted accordingly... In the end they managed to get the robot where they needed it program wise w/ using only wood, a basic watch and good eyes. I'm not trying to say that stuff won't happen but if it does there are multiple ways to do correct it before you get to the Queuing box and even still you can try and tether before we get a hold of you to get on the field like some try and do. Sorry if I insulted the programmers out there . Just trying to say that there's more then one way to fix something w/o having the right tool for the right job available for you to use.