[Greg McKaskle]

I think Mark's point is that measurements result in data, numbers, etc. They are independently verifiable and repeatable. Anecdotal data is valuable too, but you need to apply valid statistics to it and work hard to remove bias. Engineers act on hunches and anecdotal data all the time, but that doesn't make the data they acted on to be measurements.

If a team member walks to the FTA and points out that five of the field lights are not working, that is an easily verifiable, quantitative measurement. We all have sensors/eyes for making that measurement. We also have experience helping us to evaluate the impact -- are the clustered or spread, where are they pointing, do we have spares, which should we replace to make the most impact, etc.

If humans had RF receptors, comments about a dead spot would probably be acted upon similarly. But since we don't, I'd hope the FTA would scale the reports by a credibility factor and file it into the "something to watch for" bin. I suspect that if they also saw consistent secondary evidence of a dead spot, they would call Manchester and see how they can make a hard measurement, or verify their hunch, or switch to an alternate setup recommended by FIRST.

RF is complex and not intuitive to those not specifically trained in it -- including myself. Wifi builds on RF, and adds its own 30 years of protocol complexity. The robots have their complexity as well, and as I've said before, the majority of the time, the issues can be demonstrated to be a robot or DS issue.

In the best cases, lets call them category-one, we can make primary and repeatable measurements that everyone can learn from. We can measure the battery to determine if it was at fault. We can jiggle wires and show a particular wire that causes the issue -- because I can reproducibly cause the fault and we can all see it. We could also scope it if necessary and measure the circuit fault and give numerical data to the circuit fault, but that usually isn't necessary. Problems like these result in good learning opportunities.

Other times, category-two, we can only eliminate and verify that common issues aren't present. We replace components until the lack of a fault gives us a likelihood that we have identified the issue. These are far less satisfying and prone to misinterpretation. Often we replace components and the issues doesn't go away. Does that mean the component that was removed was good, or simply that it wasn't the only bad component. In a system where multiple elements can fail and the symptoms look similar, this can be frustrating, and it is hard to make it into a good learning opportunity. Whenever possible, direct and independent measurements of the simplified system will help turn this into the former case where we are all learning more and more satisfied with the outcome.

I believe 364 did a very good job trying to troubleshoot their situation. I wasn't at the event, but I believe that both they AND the FTA and FIRST staff were drawing conclusions based on an educated interpretation of sketchy data. I am trying to be objective and glean what I can from the data. I am reviewing their logs, the logs of other teams at the event, and making my own logs of known failure points to try and identify a set of likely causes and eliminate others. If nothing else, I would like to put the right tools in place so that more of the category-two issues turn into category-one issues. If other teams have logs they would like to send me, PM and I'll give you an email destination.

Greg McKaskle