Our team is looking to create an app for scouting what are some ideas that you can think of to include? We have ideas based on last year but I’m curious about what else we can add.
IMO your scouter app interface should be as minimal and “chunky” as possible. You want your scouters to focus on the match, not finding the right touch target. Your analysis on the other hand should have a good way to filter to the teams in your next match for strategy purposes.
Even better your app should look ahead on the schedule, see who you are up against and give you their stats front and center with a recommendation for how to stop/counter their OPR
5985 runs a collaborative scouting program, where teams work together to design and create a system they can use together - sharing scouting duties if they’re at the same event. It’s great training in how to design a system. Some teams stay with us, others move on to their own design.
Send me a PM if you’re interested and I can run through the details.
A Scouting System is a combined system of multiple parts:
- Data collection
- Data aggregation/summary/visualization
- Method of getting data from your collection to your aggregation
^That third bullet point is the difficult part that recently teams have started solving with QR Codes & Scanners, although there are other ways.
Your Data Collection (can be an app, can be other things) should be:
- Easily configurable by non-programming types
- If it’s anything more complex than a settings file, it’ll be hard for anyone else on your team to maintain or change in the future
- Flexible in the types of data you can enter
- Counts (nice to be able to click button or tally rather than mentally count and enter number later), Select from options, text entry, checkboxes, etc.
- Works without wifi, lightweight
- One of my favorite things about QRScout is that once you load the webpage once, it never needs to load again, and it’s ridiculously lightweight, so it can run on any device with a web browser made in the last decade (for us, these are 2015-era Amazon tablets with ads
)
- One of my favorite things about QRScout is that once you load the webpage once, it never needs to load again, and it’s ridiculously lightweight, so it can run on any device with a web browser made in the last decade (for us, these are 2015-era Amazon tablets with ads
Your Data Aggregation should be:
- Easily configurable by non-programming types
- Excel and Sheets are excellent for this, because they allow you to easily add new metrics to look at that are more valuable for the current moment, like weighted averages, medians, quartiles, maxes, mins, standard deviations, etc.
- Have Graphs
- One good graph tells you so much more than a list of numbers sometimes
- Graphs make it easy to compare teams along multiple metrics at once
- Easily accessible
- Drive team should be able to use the data, scouts should be able to look at the data, and it shouldn’t require one specific person who has all the data to be present.
- This can be difficult to do without an internet connection, so we usually have at least one person in the stands either connecting to venue wifi or tethering to their phone (NOT a hotspot, just tethering), as well as a laptop in the pits doing the same thing.
- Our strategy and drive team will frequently pull up the data on their phones for use in match strategy discussions
There are other features that are “nice-to-haves”:
- Match reference tab hooked up to the match schedule
- I usually manually pull the schedule in, but it’s totally possible to do this automatically. I like doing it manually to reduce total data usage
- Team reference tab with all of that specific team’s match data, comments, and graphs
- Data validation
- Many ways to do this, from simple checkers that make sure you haven’t missed a team while scouting to checking total game pieces scored against data from TheBlueAlliance API
- Note that constantly pulling data from TBA does slow down the app considerably
- You’re also never going to have perfectly accurate data, as there’s way too many variables keeping it from being accurate. This is mostly useful to identify egregious mistakes
- You can even use TBA API to scout specific things that are either reported directly (who balanced in auto and endgame this year, for example), or things that are difficult to scout visually
- It was much easier to automatically pull fuel scored/match in 2017 than to try and count the hundreds of wiffle balls going into the goal, and few enough teams were shooting that the automatically reported numbers were pretty decent approximations of what teams were actually scoring.
- Many ways to do this, from simple checkers that make sure you haven’t missed a team while scouting to checking total game pieces scored against data from TheBlueAlliance API
If you are already doing full 1 scout per robot system, I’d be hesitant to completely rely on TBA for things like auto balance. We used it for data validation, flagging matches/robots where our data doesn’t match the official scoring. When I reviewed the inaccuracies for Thursday of the championship, I’m guessing there ~10 matches flagged but ~7 were instances like where a robot was completely up and balanced but their partner was touching the charge station, meaning it was scored as a Dock but the robot responsible for the charge station auto was successful.
A nice to have feature is to load the match schedule into the tablets/phones so you can pre-populate the team numbers (ie: when you hit submit for a match, the next match number and team auto-populates). Without this you’ll get duplicates and team numbers that don’t match teams at the event.
I agree. I will say our scouting of the mobility bonus would have been MUCH more accurate if we automated it. For whatever reason scouts constantly mess up who did and didn’t get mobility in auto this year!