FIRST please fix....

[johnr]

It would have affected everyone in the match at MSC but it only affected red alliance because their auton was based on time and not sensors. Well, something like that.

[RonnieS]

I have no clue if this would be something that the field caused but 3 times throughout the season(last time being at states), our auto runs twice for some reason. We tried to replicate it over and over again prior but could never do it...now I am curious if it was the field that caused it.

[nuclearnerd]

Something like that happened in QF1-2 at NYC. Our bot (far right in the link below) drives forward in Auto, stops, and then plows into the low goal without shooting. Prior (and subsequent) to that match, our Auto stopped the bot 1 ft shy of the low goal 100% of the time. Our alliance partners' auto was also interrupted (though its harder to see because they didn't have a ball).
http://youtu.be/DoGdrFZtdEI?t=2m2s

Sorry I don't have logs to post.

[pathew100]

I was the scorekeeper at MSC and was an FTA for 3 FiM districts this year. I don't have the answers but I can clear up/confirm some things.

As some have mentioned, yes, you have to finish the match and commit the scores before the match logs are saved. That's why we had to complete the second match. FIRST HQ wanted the logs from both matches.

As Adam stated, we were going to stop the third match if we saw the same behavior.

Right in the field monitor logs it clearly showed that FMS transitioned the robots from Auto to Teleop back to Auto. It affected all 6 robots on the field. As mentioned in this thread, the actual outcome of that incorrect transition is different for each team based on their code implementation.

This is one of the purest definitions of a 'field fault' and is a replay no matter what teams are on the field, what match it is, or whether or not the match is played for 10 seconds or the full 2:30.

The 'signature' of the fault is known and when it occurs the data confirming it can be found in the field logs and the driver's station logs. I can't speak to whether or not FIRST can fix this before Championship but I'm sure they will try.

[Tom Line]

Originally Posted by nuclearnerd

Something like that happened in QF1-2 at NYC. Our bot (far right in the link below) drives forward in Auto, stops, and then plows into the low goal without shooting. Prior (and subsequent) to that match, our Auto stopped the bot 1 ft shy of the low goal 100% of the time. Our alliance partners' auto was also interrupted (though its harder to see because they didn't have a ball).
http://youtu.be/DoGdrFZtdEI?t=2m2s

Sorry I don't have logs to post.

It's a pretty fair bet it happened there too - see the blue bot on the opposite side of the field that appeared to drive forward much further than it should have, then fired the ball into the wall?

[Chris Hibner]

Originally Posted by John

(the encoders reset at the beginning of auto)

Our software protects against this kind of field fault so I guess it's possible this happened to us but we wouldn't know. We've been doing it this way for years for various reasons.

Here's how we do it (in case anyone is interested):

1) All of the sensor zero-point calculation and resetting is done in disabled.vi

2) We keep a global variable called "VisitedEnabled" which gets initialized to FALSE. As soon as the robot becomes enabled, this variable is set to TRUE and can never become FALSE again without a cRIO reboot (or a debug-mode override).

3) In disabled.vi (or your disabled mode code) sensors are rezero'd/cal'd ONLY if VisitedEnabled is FALSE.

[apalrd]

We always reset everything when we exit disabled mode (disabled bit goes from low->high). This is done as a safety features, so that the robot will never do anything when entering enabled mode. Autonomous is also reset when this happens. This is also a development feature, as we frequently run auto many times during calibration and we don't want to have to reset anything in the software realm to run again. If we are ever in a situation where the field disables us and robs us of a second of our 10 second autonomous mode, we will contest it as a field fault to the highest level required and demand a replay.

FMS stands for Field Management System. Its job is to Manage the Field, its FIRST job is to make sure the match runs properly (secondary tasks include saving scores, audience displays, ranking calculations, ...). This includes correctly forwarding communications between all teams playing (which it failed at the 2012 Championships), and correctly time the match (which it has failed at every event this year). There is absolutely no technical reason that the FMS should be more than 20ms off on any time event that happens during the match - The enabling transitions of the robots, the actuating of the hot goals, the lighting of the pedestal, etc. and yet the FMS still manages to screw it all up. We can get timing accuracy of 10ms on our robot controls, and we could achieve 5ms if we wanted to. I have systems at work and in FSAE that go down to 1us or less, on processor hardware that has been in production for around 15 years. Why can't the FMS maintain time to half a second?

FIRST is telling the teams (and the poor refs) that they are held accountable to every plane in space and many totally subjective calls, yet they can't maintain the match or hot goal timing to any reasonable accuracy by week 7. This is absolutely unacceptable. I am happy that the decision was made at MSC to replay the match as many times as necessary.

[DjScribbles]

Originally Posted by Adam Freeman

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.

With the advantage of hindsight, it seems to me that they could have disabled all 6 robots after the faulty autonomous and let the match timer run out, this could have saved a lot of people from the emotional roller-coaster, and reduced the fatigue for the teams on the field.

Having to keep strategies, robots, and people fresh after a grueling 5 matches in quarter finals doesn't sound fun to me.

[Joe Ross]

Originally Posted by Chris Hibner

Our software protects against this kind of field fault so I guess it's possible this happened to us but we wouldn't know. We've been doing it this way for years for various reasons.
...
2) We keep a global variable called "VisitedEnabled" which gets initialized to FALSE. As soon as the robot becomes enabled, this variable is set to TRUE and can never become FALSE again without a cRIO reboot (or a debug-mode override).

When testing autonomous modes back to back, do you always reboot the robot or use the debug override?

[Chris Hibner]

Originally Posted by Joe Ross

When testing autonomous modes back to back, do you always reboot the robot or use the debug override?

We use the debug overrides to reset everything back to power-up states. We do most of our autonomous testing while running through the play button so we can tweak PID gains while we run, and also so we can see what is going on internally in case we need to debug something.

The biggest reason we do it the way we do is we often use sensors in both autonomous and teleop and the robot is often moving at the end of autonomous. We don't want to do sensor re-cals in that brief period between modes just in case the robot is moving.

Note: we've had problems in the past with the WPI encoder reset and gyro zero/reset so we have our own encoder reset and gyro zero software that runs in disabled.vi. That's why it's important for us not to run that code between auton and teleop: the gyro re-zero code could screw-up our gyro zero-point if that ran while the robot was moving.

[Blackphantom91]

So as I was FTAAing/CSAing at Oklahoma regional I saw this same exact problem creep its head out in Final 1 though 3 with team 3528. Checked every safety config, every log though out all the matches. The interesting part was that auto either stopped then ran Teleop flawlessly or kept it in a disabled state.

The Question really for me is after knowing what teams like 33,254,1718 all do for optimization to the most. Why is it all at the same packet loss and CPU spike to entirely skip it and what in the framework provided by FIRST would allow the FMS to respond the way it does? This is all languages across the board.

My thought is that it has something to do with the Autonomous disabled transition to the Teleop enabled. I am very curious if it was from the software update that FIRST released after week 2?

[AllenGregoryIV]

Originally Posted by Blackphantom91

My thought is that it has something to do with the Autonomous disabled transition to the Teleop enabled. I am very curious if it was from the software update that FIRST released after week 2?

Alamo was a week 1 event, so the log file from 118 above proves that this has been happening all season.

[Blackphantom91]

Ah thanks for that clear up.

[magnets]

Originally Posted by apalrd

We always reset everything when we exit disabled mode (disabled bit goes from low->high). This is done as a safety features, so that the robot will never do anything when entering enabled mode. Autonomous is also reset when this happens. This is also a development feature, as we frequently run auto many times during calibration and we don't want to have to reset anything in the software realm to run again. If we are ever in a situation where the field disables us and robs us of a second of our 10 second autonomous mode, we will contest it as a field fault to the highest level required and demand a replay.

FMS stands for Field Management System. Its job is to Manage the Field, its FIRST job is to make sure the match runs properly (secondary tasks include saving scores, audience displays, ranking calculations, ...). This includes correctly forwarding communications between all teams playing (which it failed at the 2012 Championships), and correctly time the match (which it has failed at every event this year). There is absolutely no technical reason that the FMS should be more than 20ms off on any time event that happens during the match - The enabling transitions of the robots, the actuating of the hot goals, the lighting of the pedestal, etc. and yet the FMS still manages to screw it all up. We can get timing accuracy of 10ms on our robot controls, and we could achieve 5ms if we wanted to. I have systems at work and in FSAE that go down to 1us or less, on processor hardware that has been in production for around 15 years. Why can't the FMS maintain time to half a second?

FIRST is telling the teams (and the poor refs) that they are held accountable to every plane in space and many totally subjective calls, yet they can't maintain the match or hot goal timing to any reasonable accuracy by week 7. This is absolutely unacceptable. I am happy that the decision was made at MSC to replay the match as many times as necessary.

I agree. With our robot, our code is written so that after the first autonomous mode runs, we must launch our debugging/tuning application and request another auto mode. Why should we have to remove safety features so that our robot works? The Fms seems like a horrible hacked together piece of software that isn't accurate or maintainable. I'm also curious as to why they decided to make the software delete logs from stopped matches. When a match is stopped, it is because of a field fault, so wouldn't it make sense to sAve logs from matches where the field didn't work? It would also be really cool if first was at least a tiny bit transparent about some of these issues. They could at least formally acknowledge that hot goal timing, pedestal timing, and match timing are all still flawed instead of just hopng that if they ignore their problems that they will go away.

[wireties]

This auto-stop-start might explain problems we had in OKC. But it did not happen at Dallas. We are looking at logs and will forward them to Joe Ross.

In our case the symptoms were a killer because of a custom script-driven auto sequence algorithm. We finally put the auto behaviour in its own task that would continue execution and pause/restart in a more robust manner.