Creating a scouting app

I’m a mentor with team 571 and for a personal project I’d like to create a cross-platform scouting app.

I did some scouting this year and I know what I would want, but realistically the students probably do most of the scouting, so I’m coming to you to ask what kind of things you’d want and more importantly what things would not be very useful as app features.

Scouting parameters would need to be dynamic so they can change with every game every year without necessarily requiring a brand new app or extensive changes every year.

I’m thinking about having fields that can be one of multiple types: Boolean (check box), Product Type (multiple check boxes), Sum Type (radial selection), and numeric (number box).

Each field should be able to be weighted based on what your team needs (for example, if your robot could score really well in L2 and L3, you might want to scout robots who are good at scoring in L4 or the reef).

Teams could specify as many fields as they would want to scout for.

Since the rules change every year and therefore so do the scouting parameters, it makes sense to allow teams to enter whatever parameters they want. Not sure if there’s a way to auto-populate these because the WPI API doesn’t seem to have actual game rules (probably for the same reason).

Maybe it would make sense to have a way to share scouting parameters? That might make it so that the scouting parameters become to homogenized though…

The entire thing would need to work offline so that hotspots won’t be needed at competitions (which have more than enough wireless interference as it is). Some kind of online sync might still be a nice feature though, potentially.

Another idea might be using the WPI’s API to automatically fill team numbers based on competition location and match number.

One thing I don’t know is what the best or most useful views for all of this data would be. What would you display? Graphs? A sorted spreadsheet? Or something else?

It’s just an idea I’m brainstorming but I’d still love to work on something like this.

1 Like

Are you sure you would need to make a whole new scouting app? There are many scouting apps out there that offer a wide variety of features, and you could probably find one on CD that meets all of those parameters, and use that.

Just a suggestion

True. Part of the reason I am interested in an undertaking like this is that I want a project that would benefit the community and also something that I could use to learn some contemporary app development. I mostly do embedded stuff and I figured I could learn something new and build something useful.

This year, I took on the task of making a new scouting application for our team, and I set it up with configurable metrics (boolean, made-missed, numeric, multiple choice, etc…) and I really like that part of it, so I recommend doing that. I prefer it to having to hard code individual scouting metrics for each game. Each team has their own metrics they want to track or not track, and scouters of different skill level.

Here’s my OA post on it.

I don’t have an offline mode, we’ve never really had an issue with that, though I think I’ll probably add a feature to switch it over to QR mode in case there are issues.

I’d definitely recommend pulling FIRST/TBA API data so scouters can’t accidentally put in the wrong team number. Even if your app is offline, you can hopefully pull the match schedule the night before when it’s released.

That being said, the display views part of the metrics was definitely the trickiest. I have a big table type view with sortable columns. I only setup the barest minimum amount of weighting (for scoring L1-4) and it kinda worked. The issue is that your weights change depending on quals vs elims, and they change depending on first pick or second pick, or if you’re going for triple offense vs a defense third bot.

I would also recommend having a raw reports view so you can check out what happened in a specific match

I’m also a fan of comparison views, where you can select multiple teams and metrics, and compare them. Both in table form and a radar graph


I ran out of time to do other graphs/tables, and I focused on what I felt the most useful ones would be. The next thing I’m going to be working on this summer is feeding the data into an AI LLM and have it analyze the data, and correlate what metrics lead to scoring high, and figure out the weighting for me, then apply that weighting to the tables and see how it would rank the teams.

I can share how I work with your requirements in Viper:

Scouting parameters would need to be dynamic so they can change with every game every year without necessarily requiring a brand new app or extensive changes every year.

Most of Viper is evergreen and used between seasons. All past seasons that have been implemented continue to work because each season has it’s specific code in a directory for that year.

Evergreen code includes:

Some portions require very small bits of code each year:

The scouting interface is different enough each year that new HTML, JavaScript and CSS are created for it. There is a core JavaScript code for scouting that gets re-used each year, but it has the flexibility to use season-specific code to customize the scouting interface for the game.

I’m thinking about having fields that can be one of multiple types: Boolean (check box), Product Type (multiple check boxes), Sum Type (radial selection), and numeric (number box).

Add a field to the scouting interface in Viper only requires a couple lines of HTML. The back end server doesn’t need code changes to store whatever data the front end supplies. The field name in the HTML carries through to the back end and downloadable CSV data from the app. Supported data types include:

  • Counters with up and down arrows (the up and down arrows can be removed if desired, in 2025, the interface has an undo button rather than the arrows.)
    <div><img class=count src=/count_up.svg></div>
    <div>Amp<br><input type=text class=num value=0 name=auto_amp size=1 disabled max=9></div>
    <div><img class=count src=/count_down.svg></div>
    
  • Checkboxes that show up as selectable buttons
    <label><input type=checkbox name=end_game_climb_fail value=1><span>Robot attempted to climb, but failed</span></label>
    
  • Radio buttons where just one button can be selected
    <label><input type=radio name=end_game_hang_location value=middle><span>Centered</span></label>
    <label><input type=radio name=end_game_hang_location value=offcenter><span>Off-center</span></label>
    <label><input type=radio name=end_game_hang_location value=end><span>Near an end</span></label>
    
  • Timers
  • Timelines
  • Text entry

Teams could specify as many fields as they would want to scout for.

This is currently not that flexible in Viper, but I’m thinking about how to make each field configurable or allow teams dynamically add their own fields.

The entire thing would need to work offline so that hotspots won’t be needed at competitions (which have more than enough wireless interference as it is). Some kind of online sync might still be a nice feature though, potentially.

We recommend a portable battery powered server and self-contained intranet for about $300. Tablets can be connected to it for data upload via wired USB ethernet.

Another idea might be using the WPI’s API to automatically fill team numbers based on competition location and match number.

You probably want the FIRST FRC API. Viper can use it to download match schedules, it just requires an API key on your Viper server. If the API is down, not updated, or you don’t have any internet at all at your event you can use data entry for the match schedule. Either way, the people scouting just have to hit the “next” button and are automatically set up for the correct bot in the next match.

It’s just an idea I’m brainstorming but I’d still love to work on something like this.

If you want to collaborate on an existing system, I’d love to have some help with Viper. :slight_smile: It would be nice to have somebody driving the customizable scouting fields work. I’m happy to spend time getting somebody up to speed in it.

This alone is a valid reason to try.


Having done the whole “for the community” thing there will be a small handful of users that find it useful and very few returning unique users, it takes YEARS to build up a core group of teams that want to use it season-to-season. Most apps seem to die in 2-3 years after release from lack of maintenance (especially non-web-based ones). Removing barriers to entry is key.

If you decide to head into this space on your own I would focus on

  • What you find useful (as in types of data, level of detail, updates real time to drive coach/strategy, etc)
  • Ease of update season to season (it is convenient to be able to just put in 2-3 hours of work and have a minimum viable product for scouting week 1 so you can focus on other things)
  • Data export functionality (let other software handle the visualizations, at least with your first season with it)