Developing a standard

Competition Scouting
1

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: :smiley: :] :slight_smile:

2

1-10 Overall Rating

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:)

3

*Originally posted by wysiswyg *
**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. :slight_smile:

4

*Originally posted by Jack *
**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. :slight_smile: **

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.

5

*Originally posted by Gope * i think that if there is a standard it needs to encompas much more information that you proposed standard for last year’s game.

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

6

*Originally posted by Jack *
**
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
**
]

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.

7

*Originally posted by Jack *
Personally, a CSV or (comma separated values) is a great way to do this.

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.

8

*Originally posted by Brandon Martus *
**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. **

the fact that i’ve never worked with XML would be one! :slight_smile: - 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?

9

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

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

10

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? :slight_smile: 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?

11

*Originally posted by jonathan lall *
**Am I making sense? **

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.

12

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

13

*Originally posted by JosephM *
**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. :slight_smile: (but… don’t worry, i picked up php in about 4 weeks :slight_smile: - XML shouldn’t be that hard. )

14

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


<?xml version="1.0" encoding="utf-8"?>
<scoutinfo>
	<team number="188" name="Woburn Robotics"></team>
	<robot name="Blizzard 3" type="goalbot"></robot>
	<goals number="2">excellent</goals>
	<balls number="0">N/A</balls>
	<traction>excellent</traction>
	<speed>good</speed>
	<motorpower number="6">excellent</motorpower>
	<gearbox type="one-speed"></gearbox>
	<gohome boolean="true">poor</gohome>
	<comments rating="8">
That's one nice robot. Fairly fast, really powerful, won't let go of goals involuntarily.
	</comments>
</scoutinfo>

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.

15

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

16

*Originally posted by jonathan lall *
**Here’s what I mean. This is an example of how a simple XML-based scouting sheet could look:


<?xml version="1.0" encoding="utf-8"?>
<scoutinfo>
	<team number="188" name="Woburn Robotics"></team>
	<robot name="Blizzard 3" type="goalbot"></robot>
	<goals number="2">excellent</goals>
	<balls number="0">N/A</balls>
	<traction>excellent</traction>
	<speed>good</speed>
	<motorpower number="6">excellent</motorpower>
	<gearbox type="one-speed"></gearbox>
	<gohome boolean="true">poor</gohome>
	<comments rating="8">
That's one nice robot. Fairly fast, really powerful, won't let go of goals involuntarily.
	</comments>
</scoutinfo>



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. **

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?

17

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.

18

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.

19

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?

20

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.