Scouting system maintenance

Just out of curiosity, the teams that make their own scouting system,
what is your approach to maintaining it?
Do you create a completely new project every year? or just add more features/fix the existing one?
This year was our first with our own custom system, and it has been incredible,
it took around 6 months of development before it was competition ready,
and currently we are adding more features to it

1 Like

Due to our scouting app’s programmers graduating we’ve written a scouting app almost every (or every other) year. I think well documenting everything and passing on the knowledge to newer members is important for maintining a scouting app. This year, me and my friend are going to be rewriting our teams scouting app (Yet again!) How did you guys go about writing yours. Is it publicly available?

1 Like

As long as we don’t want to change direction, we keep the existing systems, update them for,the new game, and possibly change/add/delete features. Updating for the new game is the most significant maintenance. Scouting question development and analytics interface modifications can start on kickoff day. It’s always a race against time to incorporate the new FMS scoring schema that is usually revealed around week 0 into the backend. We do what we can to guess at what this is going to look like and do as much maintenance in advance of the schema reveal as possible.

Our system is not publicly available, for now, but there is a plan to make it available for other teams in the future, I might release the 2024 version of the app to the team’s github in a public repo.
Our approach is to add more features to our existing app rather then create a new one.
I am also currently in the process of training new students on the team to also work on the system

We got about the same approach but the code for our scouting system is very modular and allows us to update for the new game within a couple of hours (this year we almost fully updated our system in the kickoff evening)


If you take a look back through threads, stuff RARELY lasts beyond 3 years upon public release.

Don’t try to predict the future, it will lead to an unmaintainble mess when operating in a high turn over environment. Make what you need and move on. There is a lot to learn about SE based on the number of stale scouting project on CD. If open source doesn’t meet your needs: keep it simple, keep it light.

Here is a good content creator (out of South Dakota!) Giving reactions to bloated “mastermind”/“future proffed” projects…

we recently started using our own scouting system (2023 I think), so we only have one or 2 seasons worth so far, but from 2023-2024, we kept the same overall format with an online system feeding into an excel document but revamped it to be compatible for the crescendo and track the data we wanted. As for whether we created a new project, I’m not sure. We also completely overhauled our pit scouting system (we DID create a new project for that one). Both years, our scouting system was incredible, with data collections in the upper 90 precents.

The system 1293 used 2019-2022 (and is still around should I want to revive it) is a Google Sheets document. Each year I’d simply clone the previous one and start editing for the game tasks or to scrape TBA for relevant API endpoints. Best way to capture steady improvements.

1 Like

We add a scouting interface for each year to our scouting system, Viper. It is fully functional for every year since we built it. You can click on any of these links to try the interface for the different years:

We have about 10,000 lines of code and documentation that are evergreen and don’t have to change from year to year. That includes code for events, collecting data, transferring data, visualizing data, and planning matches.

Each year we write up to 1,500 lines of code to support the new game. For example here is our code for 2024. It includes the scouting interface, how to aggregate the data fields for the year, and which fields should be displayed as graphs.

Wow, that is a lot of lines for updating it to the new game…
Because our system is so modular we barely wrote 300 lines (and Flutter has been amazing in helping doing that),
I will definitely look at your systems, seems interesting

The scouting interface for 2024 is only 255 lines long

The most code (1,000 lines) is in aggregate-stats.js which has verbose naming of each piece of data we either collect directly, or build from other data.

var statInfo = {
		name: "Match",
		type: "text"
		name: "Team",
		type: "text"
		name: "Location where the robot starts",
		type: "heatmap",
		image: "/2024/start-area-blue.png",
		aspect_ratio: 4,
		whiteboard_start: 0,
		whiteboard_end: 13,
		whiteboard_char: "□",
		whiteboard_us: true
		name: "Exited the Starting Area During Auto",
		type: "%",
		timeline_stamp: "L",
		timeline_fill: "#BB0",
		timeline_outline: "#888"
		name: "Score for Exiting the Starting Area During Auto",
		type: "avg"

I am in the painstaking process of making documentation currently because I am a senior, and when I graduate I hope we can keep using the same system. The scout leads before me didnt do a great job of that and so I have been working on my own system since hoping to maintain it through the years. It’s probably going to be my main project for the rest of the offseason and the coming year because I have to do so much lol.

We build our own data collection app.

We have some sort of skeleton that contains basically everything we’ll need to start a new season, so we only need to write the relevant questions for the game.

During the off-season period we update and upgrade the skeleton to contain new features, types of questions and etc.

Our systems are completely rewritten from scratch every year because of how we consistently choose to use the data. This is also the standing plan for next year!