Using the code from Team 842, Falcon Robotics, scouting code from 2013, our Software Development and Strategy team has been modifying and improving this system.
This system uses 6 Xbox controllers connected to a single laptop
Software includes the DynoScout system, SQLite for the database, and Excel for match preview report.
Benefits of our system versus other traditional systems include
Using controllers, scouters do not need to take their eyes off their robot to record data, reducing the chance of scouters missing data.
With other systems like tablet scouting, teams would have to worry about keeping the tablets charged and making sure to check each battery constantly, with our system, you only have to worry about a single laptop and the charge of that system.
Students learn about developing systems and get experience with C#, they also learn some database programming and developing skills about analyzing a game and braking it down to its components efficiently.
Did a bit of searching and might have found what you were talking about with the Wii and scouting
Also looking at the other posts you shared were interesting, 2338’s system looks interesting considering it is similar ours with the controller but also needs manual input like match number and team numbers, which ours gets from blue alliance directly.
It’s still cool to see the different ways team decide to scout throughout the years.
Really neat idea to use 6 controllers. How much granularity of data are you collecting with access to so many buttons and inputs? Have you found a good balance where scouters can focus but you still get detailed information? Curious how intuitive it is. Also, does cable management in the stands become a concern?
We tend to be able to get a high amount of detail using this method. In the match preview report above you can see the type of data we are collecting but one of the biggest benefits of using this system is not needing to look away from your robot and being able to input the right buttons based on memory. This allows us to collect information like how long it took a team to engage. Tablet scouting can use a timer as well but the time it takes to find the button on the tablet will almost always be slower than muscle memory on the controller.
There is a high skill ceiling to learn the system but that’s why the first students that learn the system tend to be the ones developing it. This way they can learn quickly because they tend to have a baseline of all the controls since they are the ones who made it, and then we can start bringing others from the robot building side and train them. Some years are easier to learn than others, it just depends on the game and how many students we have on the team.
Cable management is something we try to accomplish but it can get hectic in the stands at times so the 6 controllers do tend to turn into a birds nest. During our lunch break we do untangle all of them to give us a clean start for the afternoon section.
You mentioned there is a high skill ceiling to the system. How long does it normally take your scouts to get used to the system and how many scouts do you normally have rotating in and out?
We try to ensure that our system is ready for Week 0 as this is the first time we can simulate an actual event. I would say the students who developed the code took about 10 hours and the robot builders around 20 hours. The number of scouts we have rotating depends on how many people get trained in time. The more people that are trained the less each person has to scout and can explore the rest of the event.
To allow more teams that do not have enough scouters, DynoScout can now switch what box on the interface scouters will scout.
After ending a match, the system will ask if you want to switch scouter locations, saying no results in going to the next match normally with no change, while saying yes will bring up an interface with 6 drop down options. Allowing teams to change where scouters are.
If you want to reset scouters back to the original locations, you can just leave all the drop downs blank.
The code is on a separate branch in the repository labeled devScouterLocations. Has not been tested through an actual event which is why it is on a separate branch.
Hey DynoScout team! In an effort to increase interoperability between scouting apps, we recently announced The Purple Standard (TPS), a unified, community-driven standard for FRC scouting data (see https://chiefdelphi.com/t/the-purple-standard-a-unified-and-community-driven-standard-for-frc-scouting-data/449394 and https://thepurplestandard.com), paving the way for collaborative scouting across apps (which benefits smaller teams and rookies). TPS is modular and completely customizable based on the data you want to collect in your scouting app. Would you be interested in integrating TPS into your app to benefit teams using DynoScout and join the wider network of collaborative scouting data?
The idea is cool, but unfortunately, we store all of our data on a SQL database and it seems like it would be a lot of work to convert that database into a submission. Also some of the points you are looking for we will not be tracking, and there are other parts that we will be tracking you are not looking for.
No worries! To clarify, TPS is just a data standard to describe the format of the scouting data, there isn’t a strict set of properties to collect (it’s fully flexible so you can add your own properties that you are tracking and ignore ones that you don’t plan to track). The goal of TPS is so that for properties that are being tracked by multiple scouting apps, there is a unified way to parse those properties so that the data can be interoperable. Also there isn’t a requirement to store scouting data in a TPS format in your app, rather there could be an export option (or automatic API call upon scouting entry submission) that formats the data into a TPS entry on the fly using a short function.
Since your scouting app is open source, I’m happy to take a quick look and see if there would be a place to easily integrate TPS without changing much of your existing data processing pipeline if you would be interested in that!
