The Viper scouting app https://viperscout.com/ is entering its 5th season. In this thread, we will document our development process, take feedback, and share releases.
Viper has the following features:
Web based
Online or offline (local battery powered wired intranet in the stands)
Supports laptop and android clients (we recommend six scouting tablets, but phones work too)
Un-tethered scouting (clients can unplug to scout and only plug back in to upload data after several matches)
Built-in data analysis with graphs
Alliance selection app
Match planning whiteboard with stats
Pit scouting with robot pictures
API and blue alliance integration to import team lists and schedules for events
While Viper can run on a wide variety of servers and clients, we maintain a list of the hardware that we actually use the system with. We recently updated that list.
In 2024, the server hardware including network, cables, battery, and case costs around $300. Client tablets, charging, and cases can be as little as $900.
Development for this season will be done in the 2024 branch. One of our students created the branch already and started on the user interface for the scouting in the branch.
We need to have the 2024 version ready to go by week 0 which is our team’s first competition.
They are one of the best visual representations of scouting data. If you have never encountered them, they have boxes and whiskers that tell mins, maxes, medians, averages (means), and quartiles at a glance. Here is an explanation taken directly from Viper’s instructions:
Hey Viper 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 Viper and join the wider network of collaborative scouting data?
Hi, number neighbors! (1073 to 1072) We love collaboration, and this seems reasonable.
What does “shared database” mean? Is there an API for the purple warehouse where we can upload and download data from within our app? How would that actually work, would each team using our app need to sign up for an API key?
What do we do for data that we collect that isn’t in your data format? This year we are likely going to collect the following which you don’t have listed:
The locations of the game pieces that are picked up during auto. (eg, not just “center line”, but specific position picked up on the center line.)
Full cycle timing match average and minimum, where a full cycle is defined as a trip from pickup in the opponents wing (not pickups elsewhere), to success place in amp, speaker, or trap, and then back to pick up another game piece. OR start with the place, then pickup, and then another place.
There is also a bunch of data in your format that we wouldn’t collect because it is too subjective or not worth the effort to scout. I assume that can all just be omitted.
We started implementing our pit scouting questionnaire.
Last year, the number of possible auto routines was pretty small. We had a question about which lane you were using for autos and whether you would dock. This year there are far more possibilities with 8 possible game pieces to grab in various combinations and two places to score them.
Our pit-scouting question about which autos your team can do is going to have to be a lot more open-ended this year. Here is how it is currently looking. The options for “Has it succeeded?” would be “No”, “Practice only”, and “In a match.”
The order of the driver stations matches the game manual p30 for the red alliance. The blue alliance stations are usually directly across from the corresponding red alliance stations, but I can’t actually find the official order for the blue alliance drivers stations in the game manual or field drawings this year.
Currently working on the scouting interface for scouting during auto. We want to know exactly which pieces each robot picks up, so the interface needs a button for each note laid out on the field during auto.
The interface needs to look different if you are scouting a bot on the red alliance vs scouting a bot on the blue alliance because the field has center line mirror symmetry not rotational symmetry.
Right now the rings on the buttons are just unicode text with font color orange. I suspect that one of our students will change this to nicer looking SVG images.
Like other checkbox buttons in our interface, it turns green when you click it to indicate that it is selected. You can click it again to deselect it back to gray.
CSS is used for the size of the field image, specifying the image as a background element with a fixed aspect ratio and swapping it out for the red and blue cases. The buttons are positioned with absolute positioning compared to the field image with CSS rules to show different buttons in the wing for red and blue, and to rearrange the button positions for red and blue.
The counters for placing in the amp and speaker have not been implemented yet.
Full cycle tracking is now working in the 2024 scouting interface. We define full cycles as round trips from one end of the field to the other where you pick up a note from the source, deposit it in the amp, speaker, or trap, then go back and pick up another note. Full cycles could also start with placing a note, then the pickup, then placing it.
In this example once full cycle was completed Source → Speaker → Source which took 19 seconds. It is currently tracking the time of the second cycle which could be completed by placing, then going back to the source.
Actions such as dropping a piece, or picking up a piece that isn’t at the far end of the field interrupt full cycles.
I imported a field render from here for the match planner whiteboard.
Drawing on the whiteboard is very similar to last year. I don’t think we’ll need a game piece stamp this year since there is only one type of game piece.
The match planner will eventually show stats about the six teams in the upcoming match, but that part of it isn’t ready yet.
The user interface for the end game scouting is harder to simplify than I would have thought.
One option I considered was a series of radio buttons like
[parked]
[parked, climb failed]
[onstage, not spotlit]
[onstage, spotlit]
[onstage, harmony with one other bot, not spotlit]
[onstage, harmony with one other bot, spotlit]
[onstage, harmony with two other bots, not spotlit]
[onstage, harmony with two other bots, spotlit]
but that gets unwieldy. Radio buttons for [parked] and [onstage] with additional options conditionalized on which if of those is selected works better:
We are currently collecting data about traps in the teleop scouting section with other note placements (scroll up from here to get to it). I’m debating whether or not it would be good to have a way to increment that counter by one here in end-game.
In 2022 and all previous years, scouting a match was all on one page. You would scroll down the page to move between auto, teleop, and end game. Last year we debuted a two screen interface with auto one one page and everything else on the teleop page.
Our scouters unanimously liked clicking between pages over scrolling, so this year we have taken that further and implemented a tabbed interface with separate tabs for each of the three sections of the game.
For the “shared database” yes there will be an API available this week through The Purple Warehouse (which has an existing shared database of scouting data from people who use our app), and you’ll be able to use this API to automatically upload the data into our shared database or pull data as needed. Each team would need to sign up for an account on our side so that we can link API submissions to their team number, but beyond that, they wouldn’t need to generate any special API keys as we’ll have a login flow that can hand off an API key to your app in the background (this can be a one-time action to link the accounts together depending on how your app wants to handle it).
As for the data collected, the goal of TPS is to be completely flexible and customizable regardless of what each scouting app is collecting. None of the properties are required, and if you want to collect data that doesn’t yet exist in the TPS properties, you can simply open a PR for it! The hope is that app developers can look at TPS, see if properties exist that they are collecting (and if so, use the existing format to maintain interoperability), and if those properties don’t exist they can simply contribute them to the repo.
Please let me know when the API is available and I will check it out.
If teams want to use Viper with the FIRSTFRC API, they already have to sign up for an API key and put it in a config file. Probably can do something similar with TPS.
We have a new method for recording the robots starting position. You can click on a diagram of the starting area to place the robot there or drag the robot around.
Because Viper is responsive, we can’t record the starting position in pixels. The size of the diagram changes based on your devices screen size. Instead, the position gets recorded as a percentage in the X axis by a percentage in the Y access. For example, a robot starting in the exact center would be 50x50.
The origin is in the corner of image near the source. For the red alliance, that is on the top left of the image and for the blue alliance that is on the top right of the image.
To visualize this data, we envision creating a heat map on top of this image. At this point, that isn’t implemented yet.
The code for this is powered by two methods. One of them, setRobotStartPosition, listens for mouse events, draws the robot on the board in response, and records the percentage position in a hidden form field. The other one, initalRobotStartPosition, is triggered when the scouting form is loaded with data already filled in and handles drawing the robot where the scouter had placed it.
In addition to the six scouters per match, our strategy team usually has one scouter doing “subjective scouting.” That scouter records data that would be inconsistent if collected by six different scouters. The subjective scouter needs more experience and training than the six match scouters.
The subjective scouter watches a single team per match and tries to scout each team number at least once during a competition. We don’t do this type of scouting for every team in every match.
In previous years, subjective scouting has been done with paper and pencil. This year, the strategy team would like it to be done electronically in Viper. Here is a mockup for the data we would like to record for subjective scouting this year:
That is somewhat better, but I don’t like how many “show more” links there are. I should probably be just one. This is going to need another revision.
Box Plots
to 1072) We love collaboration, and this seems reasonable.
