Scouting program in the works, need ideas!

UPDATED. NEW VERSION, PICTURE POSTED

I have embarked on a quest :yikes: . My quest is to make a simple Breakaway 2010 scouting database program for my team and others who want it.
I figured that before i finalize what data it collects, i should ask all you fine folks here at Chief Delphi for some input.

Here is what i have so far:
http://img714.imageshack.us/img714/5336/scouter.png

Ideas for removing/changing/adding new inputs are welcome!

NOTE:
-each numeric control now goes up to 5 (lowered from 10)
-it will take more than one input for each team and average them into an overall score using a formula.

Way, way more objective data. Subjective data is so much less useful. How many kicks 1 zone forward, 2 zones forward, 0 zones forward into goal, 1 zone forward into goal, 2 zones forward into goal.

How many successful bump climbs, how many failed bump climbs.

Okay, you’re right. i think that would yield more accurate results being that it isnt based on opinion. Im liking the successful and failed bump climbs idea.

Probably a little bit on the failing bump climbs is if the team has something on their robot to get them up right again. And if they do, how long it takes might be another factor.

I like the idea of a checkbox for if they can right themselves if flipped. thanks RookieWookiez

Welcome, glad to be of help.

Come on guys, keep the ideas coming!

Another idea might be what’s the farthest they can be and get the ball to their own zone.

You mean like kicker power? i am adding that.

maybe instead of just can they hang, can they hang from other robots? can other robots hang from them?

Program language for your scouter? Labview?

runs on machine - netbook? iphone? regular laptop?

going to need how many programs/machines per match?

BTW - what happened to the wii-mote input devices?

To keep it simple, we are just going to have can they hang(meaning from another robot, or the tower). But having a checkbox for if other robots can hang off of them is a possibility. Thanks for the input!

1.I am writing the data entry program(the one in the picture) in visual c#, and we are going to have an excel spreadsheet designated for the output (it will come with the program).

2.It will run on any laptop running windows.

3.you could get away with just one, but you can use any number of laptops to speed up the process. I’m thinking of making a file merger that will take all of the data files from the laptops and merge them into one.

  1. And i know what you’re talking about but i don’t know what happened to the wii-mote scouting software.

What about adding an area for comments? This way the scouter can input more information as they see fit.

Will you be making this software publicly available?

Idea:
Have a hotkey to add score zone 1,2,3
Buttons for the same thing + flip, hang, allows hanging, etc.
Then calculate ratings when writing to the database based on how many they scored from what zone, and give them a point value with long shots prioritized. Or have it mapped to many game controllers (say 6, 1 per team) to have one person focusing on each robot with only one computer (requiring no network).

Then write a phone app (or something of the like that does not require a full laptop, a pen and notebook (paper not computer) would work), for pit scouting. Have checkboxes for features, and an area for comments. Then feed it into the database and calculate the features score of the robot.

When you get the data, you need to know what kind of robot you want. If your robot can already support other robots, then having another robot to do so has priority 0. If you can’t and they can, that might help if you can hang from them.

I began working on such a system, but stopped because I had to develop code for the actual robot. I developed mine in PHP because I could easily network a few of the programming laptops to scout, and it worked nice with MySQL. I used PhpMyAdmin to read the raw data, but never had a working ranking page.

The scouting system we used last year involved pieces of paper with 4 boxes on each side, with check boxes and tally counts for things + comments. We asked the scouts (freshman) to total the tallies at the end, so the data enterers would not have to, but being freshman they didn’t. The data enterer would sit somewhere with power and type in all of these sheets, and had a runner to deliver them from the scouts. The data system was an Excel spreadsheet, with linked sheets for Human data entering (what we focused on), ranking, and various calculations. Our robot scouting system was much less technical, involving Chet and Norman writing notes in their notebook for when it came time to come up with the pick list. This system, while labor intensive, worked really well.

maybe a button for if they allow for other robots to hook on for the 3 point bonus.

How about “How do they hang”

options could be on the top tower, platform, or from a side bar.

Another thing – would you be setting this up for other teams to use individually, or have you considered having it link together so people could upload for anyone at an event to see?

Also, penalties teams caused?

Before I jump in to the advanced stuff, I think you need to have more control/list boxes for Ball control (including shooting and possesing/herding mechanisim), Drive train (Mecanum, six-wheel drive, SPIRIT etc…), and End-game (Hanging mechanisim, suspension mechanisim (what allows other robots to hang on him)).

In order to store information the information in a database - I say SQL FTW, if you’re into it.

Last year, I wrote my own “database” for my (first) scouting application, including serializing the info into byte-size code and saving them into text files which were later deserialized etc…

I’d sugest having two main databases - One is for general information about the team and the robot (usually information gathered in the practice days, about what mechanisims are built into the robot), the second being information about robot preformance in every match.

Eventually, information for tactics for upcoming games need to be given to the drive team very quickly, for the intervals between games are quite short. Having your scouting system having an automated analasyis-of-information system will allow you to give a summarized version of the teams preformance.

But as I see your current application state, I’d say this is an addition you could work on after you’ve done with the basics.

EDIT: Also for elimination (or even for the quals) - put a “Role” indicator, where you write you analysis about the team’s ability to play a certain role in the field (defense, mid-field, scorer, lifter etc…)

The Inventivity wiimote scouting parameter are summarized in post #54 of this thread: http://www.chiefdelphi.com/forums/showthread.php?t=75784&page=4. Preliminary wiimote button assignments are included as an attachment.

We will also include importation of match data (and possibly images) from www.thebluealliance.net, a robot image database, and printable strategy sheets with team stats and a field diagram.

As a general rule, stuff that’s objective that you can get in the pits you don’t include in the stand scout sheet. That doesn’t mean you take everyone’s “we can score 10 balls” seriously in pits and don’t check, but you don’t need to put whether or not they can hang on the stand scouting sheet, or how far they can physically hit the ball.