The OFFICAL 2003 FIRST Scouting Standard

[Jack]

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: webmaster@feds201.com

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.

[Jack]

Hey all. Since i think that no one objected to the 'offical' terms / how the data was collected, and people have been posting about what data should be collected, I'd think we could begin.

Now, remember we will be breaking data collected into three parts. Team Data, and Match Data (HP, AP, CP)

I'll post some of my ideas later, but you guyes can start now. - What do you think would be important to know? - What i want to go for is something like this. The data collected should give an overall trend of what each team does each match. Ex: Human players make 2 stacks of 2 ; AP- Robot knocked down wall in ~10 seconds. CP- Robot make ~3 stacks. Now, what are the main actions for each that we should have?

Robot Data - Traction on carpet, traction on ramp, traction on platform. Other data to be collected?

Yes, the robot data will be somewhat subjective.

Other Ideas?

Come'on! - Your input will make this system way better in the end.

Jack

[Jeremy_Mc]

I don't think XML is the way to go...

you can't get "real time" readings from it if you post it on a web site without sucking up major resources. a database (like mySQL) would be wayyy faster and wayyy more efficient.

XML is icky...


*jeremy

[Brandon Martus]

Originally posted by Jeremy_Mc
I don't think XML is the way to go...

you can't get "real time" readings from it if you post it on a web site without sucking up major resources. a database (like mySQL) would be wayyy faster and wayyy more efficient.

XML is icky...


*jeremy

the XML would be generated from a mysql database (or access, or SQL-server or oracle, or however you store data). not everybody can allow external connections to their database. You can fetch an xml file (which would be generated that instant from a php, or asp, or cgi script, or whatever) and then process that. Can't get more 'real time' than that. The XML is just a standard way of transporting data. The end user can do whatever they want with it, they just need to be able to read & process XML,.

[Jack]

Yes, allowing people to access my MySQL db would be a VERY bad thing.

What i (www.feds201.com) will be doing is this: We will allow people to upload/download data in both XML and CSV. This way, teams will be able to use MS Excel or Notepad to edit/view their CSV file. And... anyone who would prefer to use XML (also websites sync-ing data) would use XML. Once again: It won't be stored in a 'flat-file'. I'll have a script that you would call (ex: xmlteamdata.php ) which would then output/download the XML file to your computer.

Here are a few of my ideas in regards to Event Data:

HP: 1 stack, 2 stack, 3 stack, 4 stack
AP: Nothing, Under bar to defend, search and distroy stacks, knock down wall (If they do go to knock down the wall, we should have a field saying if they knocked it down first, or if the other alliance knocked it down first)
CP: Defended stacks, stacked bins, knocked down stacks, stole bins, sat on platform, little/nothing

For Robot Data:

Traction on Carpet: 1-5
Traction on Ramp: 1-5
Traction on Platform: 1-5
Max bins that can stack (In a game): 0-29
Go under bar: y/n
Speed: 1-5
Drive System: Wheels, treads, swerve drive, (***)
Steal stacks: y/n
Senors: Stack && || Line
Main AP action: See AP list above
Main CP action: See CP list above

These are just a few of my first ideas.

[Ben Lauer]

How about something like the order that they play the game

1st-

2nd-

3rd-

and fill in "knocked down opponent stacks," "pushed center stack," or "stacked own stacks."

It is kinda the same as above but could be organized differently

[Jeremy_Mc]

if you know how to use grants correctly, accessing a mySQL database wouldn't be so bad...

i just hate XML...you have to setup cron and just bleck...

it's just wayyy to icky for me.

[Jeremy_Mc]

hmm you could use server side scripting to generate it too...but our servers aren't that hefty if a bunch of people started hitting them...we already run two other sites on the same server...

*jeremy

[evulish]

One problem with scouting is that, I think, modularity may conflict with some stuff. Like you have 'ability to go under bar' or something. Well...what if they add/remove something that stops them from going under the bar. Maybe change it to Yes|No|Sometimes.

---
HP: 1 stack, 2 stack, 3 stack, 4 stack
AP: Nothing, Under bar to defend, search and distroy stacks, knock down wall (If they do go to knock down the wall, we should have a field saying if they knocked it down first, or if the other alliance knocked it down first)
CP: Defended stacks, stacked bins, knocked down stacks, stole bins, sat on platform, little/nothing
---

I don't quite understand what you're doing with HP...by saying 'stack', do you mean how many bins in a stack? or how many stacks? If the first, you can have 8 bins in a stack, if the latter, you can have 8 boxes not in a stack.

For AP, you could add something like 'prepare'...I'd imagine that there may be some teams who seem to do nothing but position themselves to be in an ideal places.... Maybe I'm stretching.

You could also add 'remove boxes from field' Quite possibly a robot could be designed just for that purpose.

Drivetrain knowledge is also nice. 2wd or 4wd?

Add 'dead reckoning' or whatever to sensors. And possibly a rating on how well their Autonomous mode works.

Does it look like it could get DQ'd by anything?

Durability is also nice to know. Most people can get an idea after looking at it in practice. I've seen robots that say they can do everything (and probably can)...but they tip over before they have the chance to. Also...how well does the bot take hits?

Just a list of ideas of changes/additions. There's way too much to include on a scouting form, but I'm just throwing out some ideas to see if anyone else finds importance in them.

[Jack]

Originally posted by Jeremy_Mc
if you know how to use grants correctly, accessing a mySQL database wouldn't be so bad...

i just hate XML...you have to setup cron and just bleck...

it's just wayyy to icky for me.

Well, on a shared server, their isn't anything that i can do. Other than that, most people won't be updating regurally. They will upload their data and download the data only before they go to a regional.

HP: Ya. Pretty bad (sorry). What i mean is the number of stacks they made (1-4) or we may do an alliance thing (1-8)

It will be a little hard to figure out everything that we need, but we can have quite a few things in the Team Data.

more ideas?

[apk]

Will the database allow for multiple entries about one team?
>Will this be compared?
Can all of the information be trusted?

[evulish]

Yeah...here...I've got my data sheet for team 84!

WE CAN DO EVERYTHING PERFECTLY.

Turn that into CSV or XML and you now have boosted your team a little bit of other people use that.

Hmm...it would be interesting to have a server setup at the competitions with a drop point every so many pit stations. (Or wireless...but I was thinking wired for the people who don't want to spend $100+ for a wireless card that will be going into a free 486 laptop ) I don't know if this would be a feasible idea or anything...but just a thought.

[Rickertsen2]

I like the MySQL idea. I was thinking a kind of peer-to-peer network where everyones websites could sync w/each other. Each server could have a read only database user which could be used for synching purposes.
I think that SQL is a much better way of exchanging data. It has not only beed around longer and had more time to mature but also i think more people understand it. (im clueless about XML)

also i think it would be very helpful to have a notes field where a breif description could be stored.

[Jack]

Originally posted by Rickertsen2
I think that SQL is a much better way of exchanging data. It has not only beed around longer and had more time to mature but also i think more people understand it. (im clueless about XML)

also i think it would be very helpful to have a notes field where a breif description could be stored.

I'm not sure if you get this 100% - 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.

- Also, does anyone know about internet at the regionals this year?

[pauluffel]

The HP seems as though it will be really difficult to scout for, because humans are very unpredictable and can do almost anything with a box. It might be good to have a listing of everything each team in the opposing alliance has ever done in a match, and also have a diversity rating. This could be in the form of a ratio or percent, say (# of differnet things done with boxes in HP)/(# of matches involved in). If this isn"t enough, then you could classify the different things a team has done in the HP as to how different they were from their other HP actions. Placing two stacks of four in the center of the sconring zone would be very different from placing one stack of four on top of each of the white lines in the scoring zone, but not very different from placing one stack of 3 and one stack of 5 in the middle of the scoring zone.