Chief Delphi - Web-Based Crowdsourced Scouting App for 2014

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)

- Scouting (http://www.chiefdelphi.com/forums/forumdisplay.php?f=36)

- - Web-Based Crowdsourced Scouting App for 2014 (http://www.chiefdelphi.com/forums/showthread.php?t=126161)

Re: Web-Based Crowdsourced Scouting App for 2014

Quote:

Originally Posted by ORF4450 (Post 1341602)

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.

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!

Re: Web-Based Crowdsourced Scouting App for 2014

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.

2) 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.

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

Code:

[

    {

        "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

Re: Web-Based Crowdsourced Scouting App for 2014

Quote:

Originally Posted by iv597 (Post 1342125)

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.

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

Quote:

Originally Posted by iv597 (Post 1342125)

2) 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.

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.

Quote:

Originally Posted by iv597 (Post 1342125)

3) 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.

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.

Quote:

Originally Posted by iv597 (Post 1342125)

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.

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.

Quote:

Originally Posted by iv597 (Post 1342125)

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

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

Quote:

Originally Posted by iv597 (Post 1342125)

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:

Code:

[

    {

        "match": 1,

        "red": [0000, 0001, 0002],

        "blue": [0003, 0004, 0005]

    }

]

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.

Quote:

Originally Posted by iv597 (Post 1342125)

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

Re: Web-Based Crowdsourced Scouting App for 2014

Quote:

Originally Posted by iv597 (Post 1342125)

3) While predicted scores are interesting, and my own system, FIRES (formerly IPA) includes them, as a drive team, what does this provide me? ... 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.

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.

Re: Web-Based Crowdsourced Scouting App for 2014

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. :D

Re: Web-Based Crowdsourced Scouting App for 2014

Quote:

Originally Posted by Bill_B (Post 1342841)

We will delete all match data before the season actually starts, we're just doing testing right now.

~~The way it's built atm, going back to the homepage will clear match data.~~

I fixed that issue. Wasn't sure what you were talking about until I tried it myself.

Re: Web-Based Crowdsourced Scouting App for 2014

Quote:

Originally Posted by terabyte128 (Post 1342874)

We will delete all match data before the season actually starts, we're just doing testing right now.

This app continues to look great! It looks like you have continued to work on it.

When do you plan to delete the test data? We were thinking of doing some pre-event "pit" scouting this week through robot reveal videos and week zero event videos.

Re: Web-Based Crowdsourced Scouting App for 2014

One comment I have is, I would like to see the ability to select multiple robot roles(I envision buttons like the robot abilities working well) and removing offense/balanced. Also renaming thrower to truss shot.

Re: Web-Based Crowdsourced Scouting App for 2014

Zaque: I was thinking about that as well when I designed that page, but then I thought that it wouldn't really differentiate from the robot abilities section very well. Maybe there's a way to make that work, though. I definitely do want to implement multiple roles in some sort of meaningful way though, because filtering by role is not very useful right now. I can see removing "balanced" if multiple roles are allowed, but I'm curious as to why you wanted to remove the "offense" role.

rwodonnell: We will probably delete test data soon, probably later this week, because we're also planning on using it this weekend. I don't want to do anything drastic without lead-developer-guy's approval, though (he's been out of the country recently.)

Re: Web-Based Crowdsourced Scouting App for 2014

With all of the multiple ball autonomous(s)? out there you may want to include something for that for match scouting.

Quote:

Originally Posted by rwodonnell (Post 1349171)

Since events begin on Thursday,
we will delete all test data Wednesday night.

Re: Web-Based Crowdsourced Scouting App for 2014

Quote:

Originally Posted by terabyte128 (Post 1349427)

Since district events begin on Thursday,

we will delete all test data Wednesday night.

As I said before I really like this idea, but as of right now I would not use this for scouting. There is still no way to show a team scored more than 1 ball in auto, and this is extremely important, the multiple videos showing multiple ball autos can attest to this.

Re: Web-Based Crowdsourced Scouting App for 2014

Quote:

Originally Posted by EricLeifermann (Post 1349435)

We will work on that and should have a solution before competitions start on Thursday.

Re: Web-Based Crowdsourced Scouting App for 2014

Quote:

Originally Posted by terabyte128 (Post 1349460)

We will work on that and should have a solution before competitions start on Thursday.

We are seriously considering using the app this weekend in Nashua at the Granite State District event. Our thinking, if you don't add multiple autonomous, is just to put that info in the descriptive comments. Other things we planned to add to the descriptive comments were number of cycles the alliance finished and a driving skill assessment, 1 to 5 or something (which is obviously subjective.)

We will likely go with a paper backup system if data connections are weak in Nashua. We had been developing our own app that would use bluetooth but ran into some trouble and it won't be ready by this weekend.

One other note - I can no longer "authenticate as administrator" - not sure what happened but the password I was using is not working for that. I'm pretty sure I am typing the same one. The reset page doesn't seem to work either - it says "unable to update database."

Thanks again for the great work!

Re: Web-Based Crowdsourced Scouting App for 2014

We have added the ability to count multiple autonomous shots.

We have also created a release version, which is now hosted at frcscout.com.

If you'd like to play with the development version, it will be hosted at dev.frcscout.com. This version will use the same databases, but will contain new features in development which potentially may not work correctly. Therefore, use this site at your own risk!

Release information will be hosted here. The main website will run the latest release; the dev website will run the latest code which is updated on a daily basis.

Once versions with significant enough changes are known to be stable, they will be pushed to the master branch on Git, and a new release will be created which will be pushed to the main site.