CSV does already have applications that work with it, and XML does require an application to be modified to work with the data. How much work, then, do you have to do to interpret the same data in CSV vs. XML?
As for the toolchain: Yes, a toolchain would help significantly. No, I don’t think it will the ultimate definition of success or failure. Data can, and should, be shared without everyone using the same application. Don’t forget that teams 537 (?) and team 768 both have their own applications already. On top of that, there’s STAMP. I cannot commit myself to my definition of a full-on scouting application just yet, but that’s not necessarily a ‘no’.
For those teams that really want blow-by-blow autonomous, that could potentially be stored in the match results, particularly if they are per-team.
Now that I’ve given a reaction, let’s introduce some new material to digest/make-the-thread-more-confusing-with:
I was thinking the file data should be stored in XML. We could make CSV work, but I strongly suspect that it would be more work to interpret the data, especially considering the XML parsers for just about every language. From there, data could either be in one file, or split across files. I prefer split for things such as a team list, match list, and competition list, and pit data, but all-in-one for each competition’s match data. To allow all-in-one, we would have to have tags for each data type, with the year as a property:
<ScoutingData><MatchData year="2004"></MatchData>
<PitData year="2004"></PitData></ScoutingData>
Different years in the same file could be valid, but would at the very most be useful in a limited number of cases.
A team list would be very straightforward:
<TeamList year="1970">
<team number=314159 name="Example Team Here" />
</TeamList>
A competition list would follow the same idea. It’d use name=" " and possibly location=" " and date=" ".
Pit data is slightly more complex. First, a certain number of teams have to agree as to what is useful pit data. Which team is specified using . For each bit of data stored, either the property is the tag name () or a property of a pre-defined tag (). If the value property isn’t specified, then it is assumed that the data between the opening tag and the closing tag is the content. The next sample would be valid for max speeds on various gears:
<PitData year=1970>
<teamData number=314159>
<maxSpeeds>
<maxSpeed gear=1 value="4m/s" />
<maxSpeed gear=2 value="9m/s" />
</maxSpeeds>
</teamData>
</PitData>
Match Data has similar problems. First, teams have to agree what is useful for match data. The basic outline would then be:
<MatchData year=1970 competition="That One Regional">
<match number=19 type="Practice 1"> <!-- ... --> </match>
<match number=19 type="Practice 2"> <!-- ... --> </match>
</MatchData>
In all the games I remember, points have been scored by placing objects in a certain place, or by doing something with object(s) in certain place(s). Based on that, one set of tags we can guarantee is:
<fieldState>
<score team=1234 pos="(1, 2, 0)" type="type-id" />
</fieldState>
The pos indicates relative position of the thing that was scored. Example, Rack ‘n’ Roll could use first two to indicate which leg, and the third to indicate whether the object was closer to the center or farther away. More score-related tags:
<totalPoints alliance="red" value=125 />
<penalties alliance="red" value="20" reason="safety violation" />
<finalScore alliance="red" value="105" />
I tried to make that self-explanatory.
Just so everything is clear: certain groups of teams will have to agree what data should be included in their files and applications. Not everyone will be able to share their data with everyone else. I’m not about to try and do anything about it.
Sorry for the length, thanks for reading the whole post through. What do the readers think?
)