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

Yep. That's what i'll do. And thanks guys; I thought xml was much more involved that what it is. Very easy to do stuff in php.

PS: When outputting the data, should i just do some while( ) {} loops with echos, or are there any special xml output functions in php?

PPS: When people want to dump data from their palm and upload it to the site, should that be in CSV? or can palms (or whoever writes the program) do the dump in xml?

I'm the person on Jack's team (201) writing our Scouting app, so here's my input.

a) I'm writing my program right now for WinCE, not Palm. This is because our team is getting WinCE devices, not Palm devices. I could write a Palm version too, as long as I get a heads up.

b) XML is as easy to output as CSV, from a programming perspective, they're both text. The main advantage to CSV is that it can be learnt by anyone, and is smaller. On the other hand, the XML standard can be changed mid-season with fewer issues.

I haven't looked at XML a lot, but I'm putting it to the top of my project list, and it doesn't sound hard.

Just thinking about it now, I would output the match scores as a CSV file, and the robot data files as a XML file.

well I believe that XML is the way to go. I don't think there should be so many hard coded things in the XML file simply because it will be easier to generate with an ASP(or PHP if you prefer....yuck) script. Less hardcoded items the less I probably need to do. Just my opinion.

Just thinking about it now, I would output the match scores as a CSV file, and the robot data files as a XML file.

P.S. i think that this should be mainly a team info database if you want to put up match scores fine, but I don't think it should be part of the standard. It will just cause a hassle as my experience with this dictates.

Great! Now....
 

Ok once that is done we will have all the info in XML, but what about the ppl who have to bring that info back into an Access database (ME!!!) for their handheld application? Any Ideas?

Access + XML
 

If you're using Access, can't you write VBA code? I don't know VB, but I'm sure that there are either built-in libraries available to handle XML or you download one.

Or write your own, to taste.

The problem is this:

team 47 has data in the database.

import xml file

it has more (and different) data about team 47.


which data do you keep.
how do you merge.

etc etc.

Existing Programs
 

We can't make an XML standard to conform with everybody's existing DB + Interface. Won't happen.

On the other hand, once the standard is set, I'm writing a PocketPC app that should be able to handle all of this stuff, and I know that others are seriously considering writing a program for Palm. I'm willing to polish my program to a distributable form and post it under whitepapers. I'd also post a computer side front-end for it, though it would most likely require a web server + PHP + MySQL to run. I'm sure that someone could be found to write a Access frontend, and possibly even a standalone app. If the data was in XML format to begin with, that wouldn't be so hard. If I find the time, I might even do it myself.

Other issues that arise once we have this standard is once we have a central repository for all this info, what happens if conflicting reports are entered. Not necessarily on the subjective stuff, but if one person says that a robot has 4WD and another says it only has 2WD? These are all issues that have to be worked out.

The credibility of the source is something that has to be considered when viewing the data. Even it comes from a third party, it still must be taken with a grain of salt. If it comes from the team you want information on, it has to be taken with a big grain of salt. Anything not purely objective can be questioned, and, as we all know, human beings lie. If we do have a central repository, the only way to prevent this would be to control who was able to enter data into the central repository. Every team would be able to enter their own data, as well as downloading data from, for example, www.feds201.com, as well.

neal, i talked to Stephen who said he also would talk to the wash guy. I'll tell you all about what we decided tommorrow. :)

For any other teams trying to make a database to be shared with other teams / on the web. Here is a breif summery of what most likely will happen.

Team 312 will be making something like what they did last year. It will be a palm app to collect Basic Team Info, along with Match data. I beleave that they will also be making an Access interface to go with that. On their website, you will be able to dump the data from access and upload it. (http://heatwave.cat.pinellas.k12.fl.us/) (in XML format)

Team 201 will be doing the same thing (sort of). We will be making an app for Win CE. The app will collect the same data that the 312 app will collect. You may be using the same access frontend that 312 has, or I (201) may make their own. (but very similar) Then you will be able to upload data to our site. (www.feds201.com)

Now... A little magic will happen between the two sites every so often (15-30 min). The data between the two will merge and become one! :)

The exact data that will be collected will be decided on once the game is known. If you would like input on this, be sure to check CD over the next few days.

I am unsure what WASH is doing this year, but hopefully, it will go with the other two sites.

This way, you can use whichever site you prefer. www.feds201.com will be having some special things for Mid-West teams, and if your allready there, you can use this site. On the other hand, if your using the 'simulator' on 312, then you can use their site.

A little more info on the 201 site:

We also have a few other special features regarding scouting. Our system will be called the FBI. (no it's not with the team the FBI) it stands for FEDS Bureau of Intelligence. The other things we'll have are:

Team Profiles - I think that the ENTIRE first community will like this. It allows teams to have one person that can update data about their bot/team. It will have a 'free responce' section where you will be able to have ~1000 words. Then there will be another section where you will be able to place links to pictures either on your webserver or CD pic gallery. (The images can also be displayed in the page vi. a BB [img] tag) There will also be a section where teams will be able to fill in basic data about their bot. Ex: 2-4 wheel drive,...

Easy Voting (for lack of better name now :)) - Next to each team's profile will be a seciton where people are allowed to vote on what they think that bot is like. Ex: Traction, Pulling power. Yes, this is all subjective data. BUT... if you have 500 people voting, it can become accurate. This is not like the other scouting data that will be uploaded. It will just be local to the 201 site.

Team Forums - This is a place where any user (even people that are not registered to www.feds201.com) can post data in a format just like CD. They will be able to ask a team a question, give it a comment, or give feedback that isn't included in scouting data. There is a seperate 'Team Forum' for every team.

wow... That's a lot. 312 and WASH, and any other teams that want to describe their system, please post it here now. Or contact myself at: webmaster@feds201.com or Stephen Kowski for more info/joing the 201&312 partership. :)

I hope that this will assist a lot of scouting teams for the entire 2003 FIRST season by providing a huge amount of data from each team. Remember, you won't ever be sharing your 'stragity' with everyone. We're just pooling every teams resources so that when the time comes to decide on teams everyone has a lot of data. Bottem Line: It is much better for the ENTIRE first community if you are in this system & upload data, rather than just keep to yourself. :)

I'd just like to say the "FBI" name was my idea.... anyways, it sounds like a great plan, and I hope you'll all join in. Here's a picture of our FBI logo:

http://www.feds201.com/download.php?id=40