Well… just a note to begin: When i use the word ‘offical’, it really isn’t. No one will be forcing you to use this. However, if you are planning to share data with other teams, then you should design your system to use what we come up with. While whatever site that will be used the most isn’t decided, if you want to decide to do your own thing, I’d think it’s a pretty good guess that it won’t be used that much.
First, a few general thing, because different sites will be used to upload data, there needs to be a way to ‘sync’ data between them, and a common way to upload / download so that people that design the palm apps will know what they need to do.
The standard will be using XML with DTD. This will allow for fields to be added easly thought the season. Along with that, XML is becoming the ‘standard’ for web data, and will only be used more in years to come, so lets begin with it. IF you would like to also import/export in CSV or another format, you may do so as long as you support XML.
We need to decide on commen terms to use for describing the field/ collected data. Here are my thoughts:
Based on the poll in the General FIRST forum, i suggest that the term ‘Bin’ is used to describe what FIRST offically calls ‘Containers’. This seems to be popular along with describing them quite well. (‘Storage Bin’)
I think that the only term used so far for the Stack of Bins on the ramp is ‘Wall’ Therefore, i suggest that the term ‘wall’ is used to describe that.
Next, i think that the term for the platform be ‘Platform’. This will be defined just as in the manual, which is the white HDPE section. The term ramp will be defined as the two wire sections leading from the ground up to the platform.
As much as we may all want to say ‘Tower’, I would recommend using the correct term ‘Stack’ because it can be “verbed”, and SHU (Stack Height Units) is what FIRST will offically be using.
The ‘Starting Alleys’ should be shortned to ‘alleys’. When describing which starting alley, use the color of robot that begins there. NOT what alliance is is closer to. The bars that seperate the alleys should just be called ‘Bars’.
The scoring zones should just either be called the ‘Red Zone’ or the ‘Blue Zone’ depending on the color. This just drops the word “scoring”. Finally, the Gray or No score zones that back the driver stations should be called the ‘Dead Zone’. (It’s a really cool name :)). When needing to specify which one, use ‘Blue Dead Zone’ or ‘Red …’.
If anyone dislikes the terms used, then please post because this is one of the first things that needs to be decided.
On to Scouting:
I would recommend that scouting is broken up into sections. The sections that i have in mind are: Team Data & Match Data.
Team Data would contain info about robot design that is not going to change. This could be how the stacking works, what sensors it uses, the drive system, etc. This data would be collected only once per event.
Match Data would need to be collected every match. Because of the game this year, i would recommend sub-divideing this section into three sub-sections:
Human Player peroid (HP), Autonomous peroid (AP), and and controled peroid (CP). Different ammounts / types of data will need to be collected for each section. The data should focus on what happened. Example: HP - 2 stacks of 2. AP - Search and knocked down 2 stacks. CP - Stole bins, returned via. Bar, stacked, defended, went ‘home’.
Finally, an overall rating of how well did the robot complete its tasks should be added. (1-5 or 1-10 ) This should be the only subjective data. All other data should deal with what a robot did. This is the most useful when attempting to form a stragity.
How to do this on a palm/computer:
Have a ‘list’ / buttons of commen actions. The list will be updated to reflect the possible actions during the correct peroid. Then, all the scouter needs to do is to click the action that the robot is doing, and it will be added to a comma or semi-colon seperated list. The best way to do this would to actually store the actions as numbers. However, have the data displayed as the correct English action.
On paper:
Assign each action a number / letter. For the first few matches, a handy-dandy card will have the corasponding actions with the number. After that, the scouter will have the numbers memorized and can go much quicker. A paper form will be printed that will have a section for each peroid. In the end, a list of numbers will be generated.
A similar system will be used for Team Data. The differences will be that instead of creating a list, there will be seperate fields for the key design features. Once again, it would be better to use numbers to represent the different choices.
I know that we have not discuessed what choices there should be / fields for the Team Data, nor to I want that to be discuessed at this time. I would however like feedback on what you like/dislike about using this type of system.
I will try to carry on most discuession about the Standard here on CD, although some of it may occure on www.feds201.com too. If you would like to contact me personally, you may do so either though a CD PM, a www.feds201.com PM, AIM: knehcsa (I’m not on a lot), or email: [email protected]
If you do plan to create a palm / web DB for this year, would you please contact me with your team number & email so that i can create a list of all the people that are working on this project. NOTE: This list will be just of designers, not users of the system. Therefore, every scouter should not be doing this. I would assume that most people will be using the systems that we create. However, users, please put input into this discuession. The designers need as much input as they can get. Also, please do not create a system just to do it. There is nothing wrong with using something that someone else made. (I’m sure that 201 will be using apps that other people make)
Thanks,
Jack 
PS: Please remember, scouting is NOT the same thing as stragity. People can and should share their scouting data with others. This makes it better for all of FIRST to create their team stragity which most likely not be shared.
- The site would have a script (php or asp) that would pull the data from the DB and export it in xml or csv. Then, you could write a script that would take that output and update your DB.
and would need to be able to be done all on Thur. from talking to teams in the pits. Also, while our team has 6 ppl that will do nothing but scouting, most teams aren’t that way. SO, the collecting needs to be able to be done by one person.