Web-Based Crowdsourced Scouting App for 2014

Competition Scouting
1

Team 4030 is developing a web application that will allow teams to scout through a simple and fast user interface. Data from scouting is then aggregated from all the teams that use the application and different statistics from it are displayed. Last year, we just had averages for different matches, but this year we are planning on adding more advanced statistics and graphs to make it even more useful.

If you’d like to check it out, you can visit http://dev.ingrahamrobotics.org where it is currently hosted. This is not the final version and there will be bugs, are we are editing it on a daily basis. More statistics and features will be added as the build season draws to close.

If you’re curious, you can check out the source code on Github.

EDIT: login page is being fixed right now

2

Understand that you can’t use WiFi inside the arena to access web-based systems in real time during competition. We’ve created on work around that we’ve written up a white paper on, and will be implementing another approach this season.

3

I am aware of that, we have enough students with smartphones that we can do it that way. I do see how it could present an issue though if a team doesn’t have smartphones with data.

4

This looks great! I created an account, and plan to monitor the progress of this. Our team has been developing an Android app, but the same set of programmers are currently working on the robot, so that app’s development has been slowed.

Are you at all interested in help on this, or are you guys all set? Looking forward to seeing where this goes…

5

Many venues also have issues with getting good cell-phone signal for data use

6

looks good, would add the ability for teams to score more than 1 ball in autonomous though.

7

Thanks, I will work on that.

If anyone else has suggestions as well please feel free to voice them.

Eventually we hope to create an android app that has the same html-based interface but instead stores values in an offline database until internet access is available.

8

Do you have experience running through an entire event using students’ smart phones? Have you run into any problems with students’ phones running out of battery and not being able to scout?

9

Smartphones work pretty well for the most part, we have run into this issue a little bit last year, but we plan to bring extra battery-powered chargers this year to remedy it.

We ran into that once last year; but if we can get any signal at all, it is built to be very lightweight so that slow data connections should not cause issues.

(I will probably restructure team profiles so they don’t have to load pictures)

10

I think most of the UI stuff is mostly set for this year, but what would be really helpful is advice for what types of statistics would be most useful to scouts on other teams. So far we have averages, and plan to add more measures, but any input on tables/graphs that you think would be good is awesome.

11

Some potential changes I would like to see (and logic why):

1: Change the “Assist” category to “Balls Possessed”
It will be difficult to track what is actually counted as an assist on the fly, and random alliance match-ups may result in some teams having to possess a ball more than once per cycle. This change will simplify the scouting, make it more accurate, and most likely more useful as a predictive tool. Keep the received and passed categories separate, though.

2: Add a balls missed category in autonomous
Missing shots in autonomous will have significant impact on when a cycle can start, and should definitely be tracked. A missed shot is worse than a team who simply didn’t attempt a shot. This could be simple integration with the multiple shots in autonomous change. Simply have three sets of rows, with the selection for each being “No Attempt,” “Missed,” “Low Goal,” and “High Goal” with a “Hot Goal” modifier underneath.

3: Add some criteria for goaltenders, both in autonomous and tele-operated
They may not be a popular design, but they’re still part of the game, and shots blocked should be tracked

4: Consider defensive metrics
Defense will be a big part of the game, but is difficult to scout objectively.

I really like the simple interface and quick data entry. Great work so far!

12

Thanks for your feedback and for trying out the app, I really appreciate it! I will work on implementing those changes in the order you put them (simply because it’s simplest -> most difficult). I’m not sure how to implement defensive metrics - last year we just did it in the comments, but perhaps something like a “can defend” toggle button and then leave comments?

13

A few ideas come to mind for this.

  1. an “Only plays defense” button on the last scouting page.
    Yes this could be done in the comments, but as a drive coach, I’d like to be able to easily sort the teams that are only defensive to help with alliance selection.

  2. include a “Shots stopped” button to count how many times they directly caused an opponent to miss a shot.

  3. a defensive rating scale that would allow the scout to rank them between 1 and 5 on how good their defense was. Their average rating would be displayed on their profile page.

Now for other suggestions.

  1. Aiding drive teams in determining their strategy would be a big help.
    If each teams profile page could have their percentage of made shots, trusses, catches, etc… That would make it easier to determine what your partners and opponents are capable of.

  2. Knowing what zone each robot usually stays in during a match could be beneficial information for determining strategy.

  3. A sorting system that would allow someone picking an alliance to easily select traits they want in a partner and then ranks all robots at that regional in a list which is based on those traits. (This would be amazing!)

  4. A pick list page where teams can store their list of teams they want for alliance selection. This would need the ability to cross off teams that have been picked by someone else.

I would love for our team to use your web page during our regional! I’m just worried that due to a potential lack of internet access, the system won’t work as well as intended. Some way of having this run off-line for short time periods would be amazing.

Keep up the good work, we’re very appreciative of teams that make stuff like this available to teams who don’t have the resources.

14

Thank you for the response and the suggestions! We are on a bit of a time crunch but I will take as many into consideration as possible.

For ideas:
1, 2, and 3 would all be fairly easy to implement, I can definitely do that

Other suggestions:

  1. percentages of made shots and other similar statistics are going to be on the team profile pages eventually, I will be sure to add those specifically

  2. Do you think comments are sufficient here? I could add a text field or something.

  3. That’s a bit more complicated - but we’re trying to implement such a system. Stay tuned :wink:

  4. perhaps… unfortunately there are other things that we have to prioritize more for the time being…but we’ll see.

The offline thing would be amazing, and there’s now an android API that I believe lets you embed webpage-like objects and basically make an app off them. The only missing piece is a local database that pushes when desired. I will look into it.

15

Our team had great success last year at St. Louis with tablets and using google based table app. Scouts collected data on tablet in arena, stepped out of arena between matches to transmit and then back in. Not ideal, but worked well with pits being so far from arena. Looking forward to checking out this app.

16

Ideally we’d have an offline version of the app that can store information in local databases and push when available – but we have to start prioritizing at this point, and that’s just not at the top of the list. However, I will look into it!

17

Some notes:

  1. While I’ve only skimmed the code, it looks like the PHP you’re using has a couple “gotchas”. Firstly, research and begin using prepared statements. You’ll thank me if you ever run into a case of http://xkcd.com/327/ Secondly, store passwords as some hash (ideally hash + salt). Not as big of a deal in a robotics context, but if you ever do professional development, you’ll want to have experience with that as it’s considered not only standard, but pretty much a mandate in my experience. Thirdly, and the biggest issue by far, don’t send my password in plaintext over http://. I say that in bold to push a point, I’m not at all trying to be rude, but let’s take a look at the POST request:

teamNumber=3138&scoutName=Josh&teamPassword=<THIS IS MY ACTUAL, PLAINTEXT PASSWORD>&teamType=frc&location=Cincinnati

Again, is it the end of the world in a robotics context? No. But it’s definitely a habit you won’t want to be in should you decide to do professional development (assuming I’m speaking to a student here of course :o) I’d recommend crypto-js or similar for doing this client-side, and the standard crypto libraries PHP/SQL have to do it server side.

  1. I’d definitely appreciate the textboxes on the calculations page being similar to the Location field on the homepage in functionality - I have the benefit of using my desktop browser and having the team list up simultaneously as the input page, here, but if I’m a drive team trying to use a phone/tablet quickly before the start of a match, that’s an unnecessary evil.

  2. While predicted scores are interesting, and my own system, FIRES (formerly IPA) includes them, as a drive team, what does this provide me? Can I use this to formulate a per-match strategy? Can I use this to say, “Oh, I can defend the other alliance for more points than my personal offensive contribution is worth - I’m gonna be a defense bot this game!”? Can I use it to avoid traffic holdups and potentially get more cycles in by avoiding statistically known location bottlenecks? Does one of the teams I’m against react in a significant way to defensive pressure? If so, which of my alliance partners can most significantly shut that bot down? These are all questions I feel a drive team would benefit from knowing the answers to. I’m aware you said you wanted to add some stats and graphs to this, and as a developer myself I fully understand Rome wasn’t built in a day, but these are things you might want to look into.

Some food for thought on a purely implementation level:

  1. You’ll want data problem resilience. 3138 scouts on 4G tablets and before implementing some client-side safety mechanisms, we were losing 25-33% of data. We now lose <5%. Definitely a problem you’ll need to have an answer to.

  2. There’s lots of points that, as a UI developer, threw me for a loop. Bugs, and early in the season, so I can totally understand things not working quite to “production” yet, but some links don’t seem functional for the most simple of functionality (going back to Scouting Home I seem to recall being one).

  3. Relying on the scouter to input things such as the match number, team number, color, etc. can be a lot of burned time, and has an inherent human error component. Consider making this use a JSON array of matches to the effect of:



    {
        "match": 1,
        "red": [0000, 0001, 0002],
        "blue": [0003, 0004, 0005]
    }
]

There’s potential here. I’ll be interested to see where you take this, and how it pans out over the season. I hope I didn’t come across as too harsh - I mean everything in a constructive sense here from the perspective of someone who’s in year two now of doing stategy-oriented, real-time HTML5 webapp scouting :o

18

I am using prepared statements for everything that hasn’t been “whitelisted” as OK ahead of time, I understand the dangers of SQL injection - if you look closely you will notice that I only inserted strings where I had to (because MySQL didn’t support prepared statements in the context) and I would always filter them first (example)](https://github.com/terabyte128/first-scout-2013/blob/master/ajax-handlers/login-ajax-submit.php). This seems like the safest way to me but if you have any suggestions I would be happy to hear them.

As far as passwords – I have been hashing, but I figure for this for this context it’s not really worth the time to salt them (if I really cared about security, I would use something better than md5, lol). That’s definitely something to look into though. I will also see about using crypto-js for client-side hashing though, that sounds cool.

Do you mean a dropdown of all the registered teams? Or what exactly? I’m not sure what you mean. I know the buttons become weirdly spaced when clicked, but that’s a different issue.

I will do that. Any suggestions for fairly easy things to implement as far as useful results go, is also much appreciated. I was thinking averages, z-score or something along those lines but have yet to formulate exact measures.

Definitely, do you have any suggestions for how to go about doing this? Right now we store data in localStorage until pushed to the database, which seems to provide a bit of resilience if an internet connection is lost, but we’re always looking for ways to improve it.

Hmm, I was not aware of that one. Any other bugs you noticed?

We have a script to parse the match data from a specific FRC event and hope to implement this type of system at some point in the future.

Thank you for all the feedback! We built a very rudimentary version of this last year and are always looking for ways to improve it. :slight_smile:

19

Hi there, I am the one who wrote that page. I just wrote it today, as before then it didn’t even do anything at all. (the phrase “Rome wasn’t built in a few hours” might be more applicable…) The thing that it does do (adding up the teams’ average scores) is more or less placeholder functionality until we can figure out more detailed statistics that will be actually useful to teams. Thanks for those suggestions though, we will definitely try to incorporate those to make it more useful to teams.

20

NO HOME BUTTONS FROM COMPARE ALLIANCE PAGES

sorry for the shout

I faked a scout but it wouldn’t let me back to home without discarding data.

should I be trying a fake/testing location rather than a real one? seems logical now that I think of it. :smiley: