Developing a standard
 

Scouting has really grown in the past few years from something one person does per team, into an entire division of the ‘FIRST Process’. Teams are beginning to share data, and creating custom programs to allow data collection on palms. Now, just as in any business, no team wants to give away 100% of their data, but sharing some of it is very good, and falls within the ‘gracious professionalism’ of FIRST. Currently, there are a few scouting databases on the web, <plug> www.feds201.com </> and teams are creating programs to share with others for data collection. However, the large problem is that every program has it’s own strengths and weaknesses, and every web database specializes in certain data. So, when it comes time to share data, there is no common format.

Therefore, I believe that we should try to decide on a common way of collecting data. The ‘scouting community’ should decide on what data to collect, and how to collect it. Ex: From last year a possible standard would have been:

1,2,3 Goals
0-10,11-20,21-30 Balls
1-5 Traction
1-5 Power
Y/N Mini-Device
1-10 Overall Rating

Having decided on a ‘standard’ teams them could have used whatever program they wanted to use, and when the time comes to share data, all the records are in the same format. We should also decide on what is a 1, what is a 2, … This allows an even and equal way to evaluate all teams.

Obviously, we can not decide on what data needs to be collected until after the game is announced (whee… only a few days away :)). Personally, www.feds201.com will be adopting the ‘standard’ once it is created, and I would hope that other programs will be do the same. We will also need to decide on a common way/file to import/export data from palms to the computer. Personally, a CSV or (comma separated values) is a great way to do this. This allows for easy editing in any text editor, MS Excel supports CSV, and dealing with the data using a web scripting language like PHP is much easier with a CSV. All that would need to be decided there, is what symbol to use to separate the fields, and in what order they would go.

What do you people think?

and---

Go 2003 FIRST SCOUTING!!!! :cool: :D :] :)

There is a problem I think with this rating. It sounds like it depends on opinion more than fact. It would depend on who is doing the rating:)

Yep. That's the problem. To me, I would know what a 5 ment or what a 10 ment. But to anyone else, who knows?? That's why i think it is important that we create some type of way to establish what everything is. :)

Not a problem
 

This problem can be almost eleminated if you work in pairs, that way the two people comprimise, and you also have to have a standard, like "ok team, our robot is an 8" something like that

Also, the thing with this standardized scouting is that each team needs to scout different things, last year a ball handling team's scouters were looking at completly different things than a goal handling team's scouters, although it is a nice idea, i think that if there is a standard it needs to encompas much more information that you proposed standard for last year's game.

Re: Not a problem
 

Of course, we really don't need to focus on what needed to be collected last year, but could you give some examples? :)

Developing a standard
 

]

This was your proposed standard for last year.

Our team's scouting included many many more things:

Speed 1-5
Reliablity 1-5
Shifting Yes - No (box for describing mechanism)
Crab Steering Yes - No Parttime - Fulltime
Problem's (box to describe problems)
COmments (box for writing any final comments on robot)

The list of other catagories we had goes on and on, and these little things that other teams overlooked in their scouting gave us a major advantage.

Re: Developing a standard
 

CSV is good. XML would work just as good, as well. Not sure which would be better, but its one to keep in mind. Anybody know of any advantages/disadvantages to XML vs CSV? Just curious.

Re: Re: Developing a standard
 

the fact that i've never worked with XML would be one! :) - sorry for pointless post, i couldn't help.

PS: Brandon, is there a good site where i could read some basic XML interaction with PHP?

Re: Re: Re: Developing a standard
 

There are a few links on the 'Extras' page http://www.chiefdelphi.com/forums/mi...?s=&action=xml along with an example script.

Too ambitious?
 

XML I'd think would be easier to agree on as a scout system (i.e. other teams won't start adding categories to it without getting everyone else in on it). We could have a centralized DTD or something, at CD maybe? :) And if someone has a suggestion for the system, we just change the way a scouting file is read by altering the DTD. For example, if some new thing of note comes up, like how last year 'go-home devices' were all the rage, we'd just alter the DTD to add that category. That's probably the only way we could make and maintain a true standard. No XML experience isn't much of a problem; it's fairly easy to learn (assuming you know HTML syntax).

On the other hand, there's nothing really wrong with the CSV suggestion. The advantage to that is that anyone could learn it in a second. Am I making sense?

Re: Too ambitious?
 

Yep.
Now that you mentioned it, XML would be good because of the DTD. Keeping the data types the same type, etc.

A few good links:
Introduction to DTD
Introduction to XML

w3schools is a site I found today, and seems like it has pretty good tutorials & explanations of XML, DTD, HTML, CSS, etc.


[EDIT]Yes, we could host the DTD, if needed.[/EDIT]

Can we get someone to do Palm 4.X support (or 5.X) for a database software of FIRST teams?

Someone else on my team is making our palm software. I'll check in with him to see what it runs on. (I would assume palm 4-5.* or something like that)

Whatever it is, it will be able to be used on the feds201 system.

PS: jonathan lall & Brandon have convinced me to look into and use an xml format. Sorry, can't say anymore about that now, because i don't know a thing about xml. :) (but... don't worry, i picked up php in about 4 weeks :) - XML shouldn't be that hard. )

Here's what I mean. This is an example of how a simple XML-based scouting sheet could look:

All elements here are concrete values, whereas the attributes are more subjective. Since it's extensible, missing info shouldn't be a problem. There are a few ways we could do its DTD. All the attribute names are type, name, boolean, and number.

just tossing in 2 cents...

you can divide the information you gather from a robot into 2 categories. objective and subjective

in the objective category are facts and statistics, such as:
how many goals can they control?
how many balls?
how long does it take them to empty their ball load?
how fast are they? (easy enough to measure in feet per sec with a stop watch.)
how much pulling power do they have? (*NOT* how much can they pull... i saw videos of robots towing cars last year... THAT IS NOT AN ACCURATE MEASURE OF POWER! hook a hanging scale to your robot with rope and let it drive away from you. look at what the scale reads. this is your pulling power.)
how many motors do they use to drive with?
can they shift gears?
and so on...

in the subjective category are opinions about the robot, such as:
how durable / reliable is the robot? (has it broken in matches? would it shatter if you coughed too hard on it?)
how would you rate it on a scale of 1-10?
how are their drivers?

when i send students out to scout, i try to keep the subjective questions to a minimum. i suggest we do the same when creating a standardized system. *especially* for stats like speed and power. true, these can be difficult to find out once at the competitions, but not impossible. for speed, some thing like "time to the goal at the start of the match" would have been a fine estimation of a teams speed last year... if it took one team about 3 seconds to get to the goals and another team 7 seconds, then the second team clearly needs to think of some strategy other than a mad dash to the middle goal, for example. as for power, some teams (SPAM, team 180, comes to mind) actually brought with them to the competition platforms that teams could come by and test their pulling power on.

so, a quick wrap-up... objective = good, subjective = bad
keeping the categories objective makes this system appealing to many more people