FIRST please fix....

[rich2202]

Originally Posted by engunneer

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

G39 is "remain in contact". While he kept a foot in the area of the blue box, there were times when that foot was off the ground.

I interpret those times when a part of the body is in the area bounded by the box as "Exceptions will be granted for ... momentary". That allows for a player to jump up to catch a ball, while fully staying in the box.

[Tom Bottiglieri]

Here are some DS logs from matches where this happened to us. Q92 and QF1-1 at SVR.

I've also attached a log from team 118, who saw the same bug at Alamo.

[Jared Russell]

Originally Posted by Adam Freeman

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.

I would be very surprised if CheesyVision was responsible. There are only ~30 payload bytes (plus TCP overhead) being transmitted to the cRIO per second on one of the open ports listed in the manual. That is peanuts compared to the live video streams and Network Tables data that teams have used successfully for years. Besides which, we have evidence that this bug occurred prior to CheesyVision ever being used. I am confident that this problem is unrelated and will be fixed before Championships.

(But just in case, we are going to make our autonomous routines robust to the problem...)

[Tom Line]

I'm glad Greg was there to see it and record info on it. We were all questioning what would happen if they were unable to fix the bug - indefinite replays or just let the defective matches stand? Yikes!

I am ALSO very glad that Marjie Jenkins took the microphone and called out booing after the the second replay was announced. It doesn't matter which team in particular, but I hope the mentors on that particular team have a long talk about gracious professionalism with their members. I'm sure their students would have felt differently had they been on the other side of the field glitch.

I believe Greg grabbed our DS logs as well - we had actually shown him some earlier when he was looking at the field networking.

[Gregor]

Originally Posted by Jared Russell

(But just in case, we are going to make our autonomous routines robust to the problem...)

Could you go into detail about how you plan on doing that (because 254 apparently hasn't helped our auto enough yet this year)?

[RufflesRidge]

Originally Posted by Gregor

Could you go into detail about how you plan on doing that (because 254 apparently hasn't helped our auto enough yet this year)?

I'm sure 254 can go into detail on their particulars but here are some general principles:

• Add a hasRun flag into autoInit to sure any macro initialization runs once (resetting gyros and encoders for example)
• Make sure any PID with an I component behaves appropriately if the robot is disabled briefly. This may be the case already or it may require making sure that the PID is disabled when the robot is disabled or resetting it when the robot is enabled to avoid integral wind-up.
• Implement the auto routine as a state machine (as opposed to a hardcoded sequence). If using Iterative Robot, you're probably OK already in this regard. If using Simple Robot you may not be. I'll have to go back and look at some of the details of the Command Based implementation to give proper advice there.
• If using the Simple Template in C++ or Java, make sure to save the above state data in global variables (not in the auto method itself). This allows the state to be maintained if you drop out of the auto method.
• Again if using the Simple Template, make sure you have implemented the state machine above as a loop which checks that the robot is enabled. This is important to make sure that you are not taking actions and moving through states which have no external feedback with the robot disabled (and therefore not actually able to take these actions).

[fox46]

Is this bug localized to one single robot or an entire alliance? We had an instance in Calgary where our autonomous shot one ball then the shooter failed to reload, (to shoot the second ball) the intake mechanism seems to cycle yet cannot due to the shooter arm blocking it, then rather than pausing, triggering the shooter and then driving forward for mobility- as soon as the intake appears to deploy and retract, it immediate skips to driving forward. We were unable to reproduce the behavior off the field in practice mode and never figured out what caused it. It only happened the one match. I wonder if this was this bug in action.

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

Our typical autonomous follows:
*enable*
>open pneumatic latch releasing spring-loaded shooter arm to fire 1st ball
>reload shooter
>>activate loading arm to charge catapult
>>when latch limit switch triggered by catapult, close pneumatic latch
>>reverse loading arm to move it out of way of catapult until it hits limit
>deploy intake mechanism with intake wheels running
>retract intake mechanism and turn off wheels
>pause 1.5 seconds for 2nd ball to settle
>release pneumatic latch to shoot second ball
>drive forward 1.5 sec

In that match it seemed to follow: (Red=skipped steps)
*enable*
>open pneumatic latch releasing spring-loaded shooter arm to fire 1st ball
>reload shooter
>>activate loading arm to charge catapult
>>when latch limit switch triggered by catapult, close pneumatic latch
>>reverse loading arm to move it out of way of catapult until it hits limit
>deploy intake mechanism with intake wheels running
>retract intake mechanism and turn off wheels
>pause 1.5 seconds for 2nd ball to settle
>release pneumatic latch to shoot second ball
>drive forward 1.5 sec

When teleop enabled, the driver was able to click the fire button and the system reloaded automatically as usual. This means that the shooter's reload mechanism had not moved from its home position on the limit switch and had not even attempted a reload cycle after the first shot. It's almost as if we had forgotten to put the machine in 2-ball autonomous however, the intake mechanism cycling proves that it was indeed trying to go for a second ball.

[SilentStryk09]

Originally Posted by fox46

Is this bug localized to one single robot or an entire alliance?

At MSC, it was the entire red alliance in QF1-1 and QF1-1.1. They appeared to replace every connection to the FMS (all the green Cat5e cables) before eventual third and successful run of the match. I know they were on the horn with FIRST HQ to help troubleshoot the issue. Hopefully this is something that gets resolved before then. I can't believe a system was designed that doesn't allow them to kill a match early.

[RufflesRidge]

Originally Posted by SilentStryk09

At MSC, it was the entire red alliance in QF1-1 and QF1-1.1. They appeared to replace every connection to the FMS (all the green Cat5e cables) before eventual third and successful run of the match. I know they were on the horn with FIRST HQ to help troubleshoot the issue. Hopefully this is something that gets resolved before then. I can't believe a system was designed that doesn't allow them to kill a match early.

They can. See Adam's post above for why it wasn't the second time (the first time presumably the FTAs were not aware there was an issue)

[SilentStryk09]

Oh, i realize they "can", but i find it odd it doesn't write the logs when they call a field fault and kill the match. Then again, I'm not a programmer and have no idea what that entails

[cgmv123]

Originally Posted by SilentStryk09

I can't believe a system was designed that doesn't allow them to kill a match early.

The issue isn't an inability to kill a match early; it's the inability to find out what went wrong (by looking at the logs) if a match with an error is killed early.

[Zebra_Fact_Man]

Originally Posted by Tom Line

I am ALSO very glad that Marjie Jenkins took the microphone and called out booing after the the second replay was announced. It doesn't matter which team in particular, but I hope the mentors on that particular team have a long talk about gracious professionalism with their members. I'm sure their students would have felt differently had they been on the other side of the field glitch.

I'm pretty sure no one individual team was responsible for the booing, but rather a collective disappointment from a large portion of the audience. It wasn't directed toward the teams or the staff, but rather HQ itself.

I fully understand that everyone involved with FIRST gets nothing in return for sacrificing their time to make this a possibility except for the satisfaction of helping a lot of students, and I am eternally grateful each of their services. This couldn't be done without them. I myself am a volunteer, both within my own teams and at the events. But come on guys, it's week 7 already! FRC is a product that we all buy into and expect to work, and this kind of problem this late in the season is simply unacceptable. Chances are it had nothing to do with any of the volunteer staff on site; they're just doing their job the best they can. Maybe it's just because I'm getting old enough to finally noticing these problems, or maybe this is actually new, but while all the foot soldiers plod along at each event doing their jobs excellently, quality from the top of the organization seems to have declined.

I'm not mad at the GDC for some of the questionable decisions they made this year regarding the unnecessarily large responsibility allocated to the refs, or some of the penalty values (or the refs for enforcing these penalties), or even the large push toward heavy defense or 1 game-piece games, but this kind of technical failure bothers me greatly.

Keep in mind I have no horse in this race (I was completely unaffected by any of these technical failures and my teams were eliminated from Championship contention weeks ago). I just feel bad for all the alliances including MSC QF 1-1 that have gotten screwed by the the field system we were given to use. I'm just frustrated that while all the other teams are doing their best and working their darnedest, considering the pedestal lights, the hot goal timing, match length discrepancy, and now this, the FMS we were given doesn't seem to be fully debugged before being released to us for use.

disagree with me or not, these are my individual feelings. I don't know any of the facts, so I may be entirely in left field. Thank you event-staff FMS guys for working your butts off to get it fixed. You guys are troopers. This kind of problem is WAY over my level of understanding.

[Jon Stratis]

Originally Posted by Tom Bottiglieri

Here are some DS logs from matches where this happened to us. Q92 and QF1-1 at SVR.

I've also attached a log from team 118, who saw the same bug at Alamo.

We saw this exact same issue at North Star! There were two matches where our autonomous drove forward, put down our arm in order to shoot, and just stopped. We spent half a day trying to figure it out, and the only thing I could see were gaps in autonomous that looked exactly like that - with no apparent cause. It seemed to "fix itself" after those two matches and never happened again, so we pretty much forgot about it.

[Joe Ross]

If you think you were affected by this issue, please run the following tool against your DS Logs: http://www.chiefdelphi.com/forums/sh...67#post1373367

It should be much faster then manually looking at log files and much better then guessing from video evidence.

[Jared Russell]

Originally Posted by Gregor

Could you go into detail about how you plan on doing that (because 254 apparently hasn't helped our auto enough yet this year)?

What RufflesRidge posted is basically correct. Persist autonomous mode state across mode changes so you pick up from the same place you left off. In our case, we use a lot of timing from the start of the match that was thrown off by the false start of teleop.

Also, for those that asked: In our experience, the entire field experienced this issue simultaneously.