A common measure of a team’s performance at competition is their OPR (Offensive Power Rating), a metric of how much a team contributes to their alliance’s score in an average match. This statistic is limiting: it only discerns between high-performing and low-performing teams. BPR is a new statictic that shows a team’s average contribution to a specific scoring target. BPR allows you to look at data beyond a team’s estimated contribution to their alliance’s score.
A team’s BPR in a scoring area shows the team’s average contribution to that specific scoring area. For example, a Steamworks robot that scored a large number of points spending the entirety of every match dumping fuel into the low goal would have a high low-goal BPR but a low climbing or rotor BPR. BPR is an entirely objective statistic calculated using data reported by the FMS and the same math as familiar stats like OPR, DPR, and CCWM. There are no human scouters, no subjectivity, and most importantly no delay in reporting BPRs, making it an essential tool for strategy during competition.
For the math nerds: BPR is calculated exactly the same way as with an OPR, DPR, or CCWM calculation: by taking a Cholesky decomposition of a matrix with number of times a team has played in a match with each other team in the event. The only difference is that the decomposition then gets solved with the FMS-reported match breakdown statistics like auto points or teleop fuel low, instead of the total score of the match.
Other FIRST Robotics Competition statistics services typically only show OPR, DPR (Defensive Power Rating), and CCWM (Calculated Contribution to the Winning Margin), and sometimes only show the top 15 teams. The BPR app shows you OPR, DPR, CCWM, and BPR in any numerical statistic reported by the FMS for all teams at any official FIRST regional or championship division.
Looks like a cool new tool! Have you run any tests on this? E.g., make a simulated regional/district event/etc where you know how well each team can do each task (e.g. each delivers a normally distributed number of gears per match, you know the mean) and see how well what BPR gives you matches up with the values you know.
I had done a few searches to see if anything like this existed yet, but I didn’t come across Component OPR. From a glance, it looks to be the same calculation, but in a Java/Android wrapper instead of Excel
The most in-depth “test” I ran was comparing my team’s rankings to what I remember of our performance over the past 3 seasons, nothing beyond “I remember us being great at this in this event”, “we were eh at this” and “we never did this on the field (ahem fuel)”, and the numbers seemed to make sense with my recollections.
I checked most of your fields against the 4536 scouting database’s, and the ones I could get data for matched. Some of the fields though gave me an error saying “Please select a numeric field.” A sample of these were:
robot1Auto
rotor4Engaged
rotor1Auto
These are all fields which contain boolean values when requested from FIRST’s or TBA’s API, so you probably need to add in a conversion to 0 or 1 for these fields before you begin calculations.
Yeah, I haven’t written the code to deal with booleans because the data they return can get kind of weird. For example, the touch plates are split into three booleans, one per touch plate. That doesn’t refer to the team in position 1, 2 or 3 but the actual physical touch plate location, so unless every team climbs using the same position every match, the statistic isn’t meaningful. Rotors is interesting though, because it is shared between all teams.
The best way to get a meaningful number out of those scoring targets is to use autoMobilityPoints, teleopRotorPoints, and autoRotorPoints respectively. If you want to play around with doing things differently, the Java library I linked has a really easy way to use a custom metric. Look at getForSupplier and MetricProvider.
There’s a COPR breakdown in Java, just check my signature.
It was useful for understanding robot capabilities at DCMP, WCMP and IRI. Based on it, I could judge whether it was worth the risk to go for 4 rotors. Yet it was not a good predictor of whether the full potential of the robot would be met in a given match.
That’s a fork of my frc-power-calc repository that I linked at the bottom of the first post! This isn’t a new project, it’s been around and public for about a year, I just never posted it anywhere so I assumed nobody had found it yet. I just spent a week or two updating it to the new V3 TBA API, made a huge performance fix, refactored some stuff, and wrapped it all in an Android app.
I’m so glad somebody was able to find a use for the library during competition! It looks like you’ve made some great modifications to it. If there’s ever anything you’d like to contribute, send over a pull request!
When analyzing, I made the assumption that the touchpads correspond to the driver’s station in front of them. Red 1 = red touchpad near, red 2 = red touchpad middle, red 3 = red touchpad far. Blue 1 = blue touchpad far, Blue 2 = blue middle and Blue 3 = blue near.
It isn’t the perfect alignment, but I’d estimate that 90% of the time, that corresponds to where a team climbed.
Thanks for posting this! There’s been a lot of discussion and work on component OPR, but I believe this is the first project that puts it online or in an app, calculated live. That’s very helpful!
None of this is perfect, unfortunately. To get perfect data you’d need a human scouting each match. If we assume that each robot climbs in front of their driver station, we don’t need to do any of the fancy linear algebra with the BPR calculation, we can just take the average of how many times we think a team climbed (how many times the touchpad in front of their DS was triggered) over how many matches they played. I’m curious to see how the effect of the uncertainty over where a robot climbs compares with the mathematical guesstimation that comes with the linear algebra, and how both of those compare to human scouting data.
But alas, it’s finals week, and I’ve already spent too much time choosing robotics over school…
Sorry I missed your post! There’s currently a bug in The Blue Alliance’s API that is preventing me from easily getting offseason event data. Instead of putting time into a workaround, I am going to try to wait for them/work with them to fix it (and they’re usually pretty quick at fixing these type of things).
