This past week, the Scouting and Strategy Team worked to further analyze the game as well as begin work on our scouting app for this year. Below you can find a summary of what we have accomplished, what we have found useful, and what we haven’t.

Strategy

Throughout the week, we looked at ways to gain further insight into the game as well as possible adjustments to our priority list. Early on, we looked at the Monte Carlo simulation made by Team 4926, which can be found here. When using it, we found that we were unable to extrapolate meaningful information from it when the distribution of performance was flat, as opposed to on a curve. We are looking to modify this in the near future, both so we can project how the game will play out with it, and also so we can generate mock data for our analysis systems with it.
We have also been looking at ways to predict the amount of cargo on the field as a match progresses with robots of certain capabilities. We attempted this using a sort of excel algorithm, however we found this to not be able to take in enough data to give useful results. We think this sort of analysis has potential and we are looking at python solutions.

We have also discussed and listed below our adjustments to our initial priority list. If you click on any of the changes, you can see our reasoning. Being able to go under the low bar: Should Have -> Must Have

• Being able to go under the low bar: Should Have -> Must Have
  • As more and more Open Alliance and Ri3D information comes out regarding the cramped nature of the Hangar, we believe it will be very important to be able to approach the hangar rungs from the middle of the field as opposed to having 2-3 robots enter from the side, turn 90 degrees and awkwardly slide into place.
  • We expect cargo to make its way over into the hangars and it will be greatly beneficial to be able to enter from either side of the hangar.
  • We expect defense to be strong against robots who are taller than the low rung who enter a hangar and get trapped in an artificial chokepoint with a defender between the hangar trusses.
  • It’s only a few inches of height sacrifice

• Active Cargo Settling: Should Have -> Could Have
  • From our own early prototyping as well as other Open Alliance teams, we have found intakes that settle balls that are bouncing more than a couple inches off the ground to be challenging to say the least. We feel currently it may be better to focus on having an excellent ball-on-ground intake.
  • We don’t expect bouncing cargo to be as much of a plaguing issue as we did on kickoff weekend. Pre-Champs, we expect to able to thrive without this capability. We may assess pursuing this later in the season depending on how early events look.

• Score cargo in lower hub rom tarmac: Rephrased to “Score cargo from on robots length away from fender”
  • This was more or less the intended understanding from kickoff, just a clarification.
  • Goal is to be able to “score over defender,” similar to 254 2014.
  • Further back on the tarmac seems unnecessary and unreliable/unrealistic.

• Score cargo from one robots length away from fender: Must Have -> Should Have
  • Having more than one position of scoring low may hinder other aspects of the design and we don’t believe it is absolutely necessary to have a good low scoring robot

• ‎ High Bar: Could Have -> Should Have
  • From early prototypes from other Open Alliance teams, we expect this challenge to be slightly easier than some of us originally foresaw.
  • We expect a large portion of teams to have a mid climb and a high climb + a mid climb = bonus RP. In order to retain control over our destiny as much as possible in the rankings, we would like to not require 3 robots to climb for the rank point.

• ‎ Umbrella: Won’t Have -> Could Have
  • Umbrella refers to a mechanism that can selectively prevent cargo from entering an open hopper. If the goal is to allow bouncing Cargo to fall into the robot, we would potentially want to be able to prevent undesired Cargo from doing the same.

• ‎ Operation Double Trouble: Unlisted -> Could Have

• Wearing a Mask: Must Have -> Must Have

• 5 Cargo Auto: Unlisted -> Unlisted

These have likely settled into place for the most part as we are quickly approaching the main archetype discussions of the robot. We will have a post prior to our Week 1 event to share our strategies going into it.

Scouting

We have been working hard to get our scouting app off the ground quickly as we share a large amount of student resources with the programming subteam. To start off, we compiled a list of data points that we want to be able to collect both in match data as well as pit scouting data. This can be found below. 

• Match Data 
  • Alliance color
  • Start position (tap for location)
  • Taxi
  • Ratings (intake, driver, defense, avoid defense)
  • Shooting position (tap for location)
  • Upper success/failure
  • Lower success/failure
  • Climb level (attempted, success)
  • Climb time (for each level) (collected in background)
  • Penalties (#)
• Pit Data
  • Team #
  • Picture
  • Climb level
  • Height
  • Dimensons
  • Multiple Drive Teams?
  • Shoot high? low? both?
  • Auto mode
  • Start preference
  • Shoot from fender? tarmac? launchpad?
  • Drivetrain type
  • Holding capacity

One of the more unique aspects of our data collection is that we are taking in the “precise” location that robots scored from, as well as their accuracy from that position. We are doing this by having scouts select the field image on their tablet screen on the place where they believe they scored from. Then a pop up comes up near where they pressed, prompting them to select how many were scored and missed by hub height. We are, in the background, collecting the timestamp data of each scoring action, as well as climber timings. We are unsure as to how we will use it or how accurate it will be, but we are moving with the principle of collecting all the data we have access to that doesn’t impede the collection of other data, and selecting what we want to use later down the line.

We have spent more time than I think any of us are a fan of figuring out the most effective ways to display the field in the app. Getting the dimensions of field elements and scaling them into our app was annoying.

We want this degree of precision so when we collect scoring location x,y data, we can overlay it onto an image of a field and have it be accurate-ish.image (3)1920×938 61.4 KBPXL_20220115_2154578863072×4080 2.88 MB

App Field Status as of Saturday. You can probably see the slight imperfections in the Hub deflectors and tarmac lines. Trust me, it bothers us as much as it bothers you.

We have started looking at some ways we can use the substantial amount of data we are collecting. My 3 personal favorite are below: 

• Density/Heat Map of scoring locations/accuracy by team/event/driver station
  • Since we have access to every team’s scoring location as well as their accuracy from that position and their driver station, we can model this to our heart’s content. Below is an example of a model that looks kinda like how we imagine this could look.

• Accuracy of event or team over distance from the goal 
  • This is certainly less useful for low goal scorers, but as more robots try to score from range, we can model their accuracy from range and potentially know where they are the most effective, and take appropriate in-match actions.

• New York Times Spiral Graph

If you want to take a look at what we have going on code-wise, our repo can be found here. The 2022 specific code can be found in the Ayush branch, found here.

As always, any questions, comments, criticism, or suggestions are highly appreciated.