FIRST please fix....

[johnr]

First please fix auton- telop - auton bug before worlds. If you can't fix it at least get the old fog horn to see it and stop the match. Thank You

[Jared Russell]

We are in the process of gathering our driver station logs from SVR to hopefully help FIRST hunt down the bug. I recommend that you do the same.

The behavior we saw was that 1.5 seconds into autonomous mode, the field would transition into "teleop disabled" for 0.5 seconds, then resume auto mode for 8 seconds. This happened in two of our matches, and has apparently happened at other events as well (for example, we saw this issue in 118's logs from one of their events).

[mikemat]

Originally Posted by Jared Russell

The behavior we saw was that 1.5 seconds into autonomous mode, the field would transition into "teleop disabled" for 0.5 seconds, then resume auto mode for 8 seconds. This happened in two of our matches, and has apparently happened at other events as well (for example, we saw this issue in 118's logs from one of their events).

This is the same behavior we saw in MSC QF1-1 and it's first replay.

[tStano]

http://youtu.be/HH_CG-Jmpr8?t=1m

I think that might have happened in QF1-2 at Milwaukee. It looks like all the robots stop at once, and then we(1675; big yellow PVC forks pointing up) ram our alliance partner. Same code, stopped in match 1, not in 2. This behavior didn't make sense at all to me, or anyone on our team at the time, but this field issue might explain it. Perhaps it screwed up our Timer or something.

[JohnFogarty]

This happened to me not once or twice but every single time we played on the field but i also seem to have the bug within my practice mode of my DS. Ill be sending my data as well. I did some figuring with a dumb luck trick involving the delay command in java in order to prevent the bug from causing major issues. I can't exactly explain it very easiily because im not sure how or what I did to fix it. Ill post my logs and code in this thread to see if you all can benefit from it.

My guess is that any time the delay command is running it ignores anything its told from the fms.

[Jim Zondag]

Greg McKaskle from National Instruments was on site at MSC this weekend. He and the event FTAs were able to capture a log of this glitch event happening in QF1.1. Hopefully this will provide sufficient detail for FIRST to root cause and solve this issue.

[SkittlesCharge]

I think that might have happened in QF1-2 at Milwaukee. It looks like all the robots stop at once, and then we(1675; big yellow PVC forks pointing up) ram our alliance partner. Same code, stopped in match 1, not in 2. This behavior didn't make sense at all to me, or anyone on our team at the time, but this field issue might explain it. Perhaps it screwed up our Timer or something.

From the other alliance's point of view, I could see this being a possibility as well. One of our alliance partners, 2039, drove a bit farther than they usually did, so they missed their shot. Our team, 537, also experienced problems as our robot never fired its ball during autonomous and drove a little bit farther than normal. Maybe the encoders on 2039 and 537 were reset part way through. I could see that possibly causing these problems, as 2039 drove farther and we never reached the encoder value that we fire our ball at.

[Iaquinto.Joe]

Shouldn't the FTAs call a field fault and stop the match right after the glitch occurs? The second replay of QF1-1 at MSC should have been stopped much earlier.

[stefanp]

Is this the same as auto being disabled after a second? I might have the logs for this but I don't know why autonomous would just be cut short 9 seconds. Additionally the match wasn't replayed(would not have changed outcome).

Here is a link to a match video where auto was cut short to 1 or 2 seconds. No robot shot a ball this match and I have seen working autonomous from our robot and others in previous matchs.

http://www.watchfirstnow.com/archives/90605223

[Bryan Herbst]

Originally Posted by Iaquinto.Joe

Shouldn't the FTAs call a field fault and stop the match right after the glitch occurs? The second replay of QF1-1 at MSC should have been stopped much earlier.

If they catch it, yes. However, we don't know if the FMS is reporting this hiccup (I didn't see this at all at 10,000 Lakes or Lake Superior). If the FMS doesn't show it and no one reports it, the field staff won't know that anything happened.

The other issue is that if it is an FMS glitch that happens in every match, they really have no choice but to keep playing the matches with the glitch (with reasonable warning to the teams of course).

[Iaquinto.Joe]

Originally Posted by Tanis

If they catch it, yes. However, we don't know if the FMS is reporting this hiccup (I didn't see this at all at 10,000 Lakes or Lake Superior). If the FMS doesn't show it and no one reports it, the field staff won't know that anything happened.

The other issue is that if it is an FMS glitch that happens in every match, they really have no choice but to keep playing the matches with the glitch (with reasonable warning to the teams of course).

They replayed QF1-1 twice due to the issue. Any observer could have predicted the possibility of the glitch reoccurring and seen the effects of it if it did. Instead of stopping the match after the red alliance missed once more, the FTAs decided to let the match run it's course.

[John]

I think this explains what happened to us in QF-2-1 at Northeastern. Auto appeared to reset a couple of seconds after the match started. Our robot ended up driving into the wall (the encoders reset at the beginning of auto) and never shooting (since it never got to the correct number of encoder ticks). I think 1761 missed their auto too. No replay, but luckily for us we won the second two matches. As far as I know it never happened to us again.

[engunneer]

Originally Posted by stefanp

http://www.watchfirstnow.com/archives/90605223

Off topic: that blue human player went just a bit out of his box...

On topic: I guess the one advantage to the java template we used was that if auto was started and interrupted (either going to disabled or teleop) it would actually pick up where it left off when it was enabled again.

[Adam Freeman]

Originally Posted by Iaquinto.Joe

Shouldn't the FTAs call a field fault and stop the match right after the glitch occurs? The second replay of QF1-1 at MSC should have been stopped much earlier.

We asked that question to the FTAs. They told us if they stop the match then no match log files are created. So they kept the match going to collect additional data to help determine the root cause of the problem.

They told us before the third match that they would stop it early if it happened again since they weren't going to learn anything new by continuing with the match.

The second time the issue showed itself slightly longer into auton (maybe 6-7s in), it almost seemed to be some sort of interaction between our CheezyVision timing and the field....since both times it seemed to occur right when we selected the HOT goal. We were going to stop using it, but the FTAs wanted us to keep everything exactly the same.

We ran the same auto for about 8 qual matches and every single elim match....so I don't know why the outcome would have changed.

It'd love to know when the true root cause is determined and see the data that proves it.

[pntbll1313]

Originally Posted by engunneer

Off topic: that blue human player went just a bit out of his box...

Sorry to derail the thread but there are no rules that say he can't go outside of his box per G39. As long as he is in contact with the human player area he started in, I can't find any rule that he is breaking. Unless you're saying he lifts his left foot every once in a while and loses contact. You may be right about that.

G39
During the MATCH, TEAMS must remain in contact with the area of the FIELD (ALLIANCE STATION or HUMAN
PLAYER AREA) in which they started the MATCH. Exceptions will be granted for inadvertent, momentary, and
inconsequential infractions and in cases concerning safety.