Match Score Breakdowns 2022

Competition Scouting
1

I’m looking at the Match Score Breakdowns for 2022 on the TBA API Docs here: APIv3 - The Blue Alliance (scroll down and expand Match_Score_Breakdowns_2022_Alliance)

Here is a screenshot of the section I don’t understand:
image

In particular, I don’t understand the following categories:
autoCargoLowerNear
autoCargoLowerFar
autoCargoUpperNear
autoCargoUpperFar
teleopCargoLowerNear
teleopCargoLowerFar
teleopCargoUpperNear
teleopCargoUpperFar

I’m guessing that these numbers represent the number of balls that exit the HUB at various times and locations. This strikes me as a strange thing to track, but since I guess it is being tracked, then why does it only go halfway? There are 4 upper and 4 lower exits, but this breakdown seems to group the two exits near to the scoring table together and the two exits far from the scoring table together. At least that would be my interpretation based on previous year API usage of the terms “near” and “far”, which to my knowledge have always been used in reference to the scoring table.

Am I misinterpreting these fields?

I suppose that as is they can be used as a rough sanity check that balls are exiting in roughly even amounts to the left side as the right side (relative to the drivers). But why track left/right balance instead of red/blue side balance? I feel like it’s much more important to see that there is even balance of balls coming out on the red side vs the blue side, or better yet just provide a full breakdown of how many balls leave each exit instead of grouping them together for no obvious (to me) reason.

3 Likes
2

If I had to guess, the far and near side would tell you if the cargo is falling out on the side wall touching blue’s hangar vs. red’s hangar respectively. The cargo could be evenly split between red and blue, but always fall towards the side with red’s hangar. Agree with you that it’d make more sense to provide a full breakdown though, and extrapolate red vs. blue and near vs. far from there.

3

Maybe teleopCargoUpperBlue, teleopCargoUpperRed, teleopCargoUpperNear, and teleopCargoUpperFar each represent a unique exit? Or maybe they are each groupings of 2 (I hope not because that provides less data)? I guess I’ll just wait until week 0 to count up ball exits and see what makes sense.

1 Like
4

I haven’t fully dug into the all the fields, but it looks like it’s something like this:

image
image1513×778 184 KB

3 Likes
5

From what i understand, the endpoints in general are not official. It sounds like some TBA people arent even aware theyre on the site yet?

6

We just had the scorekeeping webinar. These are exactly this. “Near” refers to the scoring table side, “far” refers to the audience side, “red” is closest to Red Alliance Wall/Hangar, “blue” vice-versa.
There is a count for scoring. The FMS uses color sensors to determine which balls were scored, and uses the “elevation” (upper vs. lower) of the exit to determine number of points. The breakdown of which exit the ball returns through is just a sanity check to make sure the totals add up.

EDIT (Clarification): The “count” for scoring shows up as a total on the scorekeeper’s view (and on the audience display as x/20 or 18 if a QUINTET is achieved). The scorekeeper can also see the breakdown of individual exits to make sure everything’s functioning properly, so it looks like the FMS archives the breakdown to the API as well.

4 Likes
7

This makes sense. I thought the HUB exits were at 45 degree angles relative to the field walls which got me going down completely the wrong track in my thinking.

Got it, thank you.

2 Likes
8

This is certainly interesting. I wonder if different fields might spit balls out more/less evenly, and if you could find that out early in an event. You could also figure out which side got a bit of a competitive edge during a given match from the randomness of balls spitting out.

3 Likes
9

I know it’s theoretically random as to which exit cargo returns from, but if I notice one or two exits seem to be favored an extreme amount over others (like, 75% from two exits vs. 25% from the other two considering external factors such as timing of the shots) I may bring it up to an FTA personally as the scorekeeper. It would be interesting to see if teams notice trends beginning to develop in early weeks before there’s any updates to the field and/or scoring however…

1 Like
10

I like that we are getting a breakdown for taxi and endgame for each team. The question is should we scout for that or rely on the API?

taxiRobot1 string
Enum:
Array [ 2 ]
endgameRobot1 string
Enum:
Array [ 5 ]
taxiRobot2 string
Enum:
Array [ 2 ]
endgameRobot2 string
Enum:
Array [ 5 ]
taxiRobot3 string
Enum:
Array [ 2 ]
endgameRobot3 string
Enum:
Array [ 5 ]

11

I think that depends on whether you’d rather know (1) what your scouts thought the teams scored, or (2) what the referees thought the teams scored.

That’s intended as kind of a silly answer on my part, but I think there may be times one might want to emphasize knowing one, the other, or both.

For another example, I have a hunch that the API data wouldn’t distinguish between a team scoring Traversal points due to G208 vs. a team getting to the rung themselves, but you might want your scouting data to do so.

12

Hey, Kim here. Speaking (for the moment) as a TBA Data Mod.

One of our admins (@Eugene_Fang ) confirmed that the 2022 model listed was one TBA got from FIRST. As far as we know, it’s correct, and if they change it at all, the model listed for TBA will change too most likely, so just a tiny heads-up there.

As to the location names in the API, per Eugene (again) that refers to the layout relative to the scoring table & field from that perspective.

Also for the far/near/red/blue question, that’s the hub exit
Far near are relative to the scoring table

Thanks for the patience :slight_smile:

EDIT: And speaking unofficially… it means we can see how lopsided the floors are in each venue :stuck_out_tongue:

5 Likes
13

That’s good to hear, I suspected as much but it’s nice to have it confirmed. Hoping the official FRC API documentation updates soon. It currently only has 2015-2020 FRC Events

2 Likes
14

So it depends on the referee panels ironically.

So some years both refs score the “movement” in auto in that case there is typically the team number on the panel and a “moved” button and both refs have to match on movement. This is rare and usually is only done for end game.

If this was the case then yes you “should” be able to trust the API.

However most of the time (it has been a few years since I have seen a referee panel and they do start to blend together after a while so I might misremember) only one side scores the auto movement in that case I have seen refs who just care the number of movements is correct (1, 2 or 3), not so much the “number” that moves. In that case the API can’t be trusted.

So we just scout because we don’t know how trustworthy it will be beforehand and collecting a 1 time movement is not going to make or break our scouts

1 Like
15

Here are the metrics I am planning to include in my scouting database and event simulator:
metric_descriptions.xlsx (13.0 KB)

There are a lot to be sure, and like half of them relate to cargo exits, which should have a very minimal impact. But hey, if FIRST is giving us the data, then I want to track it. I’m very intrigued to analyze how much the random ball exits from the hub impact scores, so it’ll be good to record all of these now for easier analysis later. Let me know if there are any metrics I am missing, or if any descriptions are unclear/inaccurate.

2 Likes
16

I personally haven’t used the API for scouting purposes myself (I’ve either relied on someone else’s program pulling from the API or used other data), but I can tell you that scorekeepers, refs, FTAs, etc. are ensuring that every piece of data that gets entered is 100% accurate before it’s committed (otherwise the match results could be affected), and auto and endgame are broken down by robot by the FMS since the refs need to score them individually. Assuming the API is 100% accurate to the FMS (I would assume, but us in FIRST know better than anybody that technology is weird) then yes you could rely on the API.

17

From what we’ve been told in scorekeeper training refs manually score taxi and hangar points on a per-robot basis.

18

I don’t think the question is around the accuracy or validity of the data – I have very little doubt about that. The first question is if you’ll have internet access to pull down the data from the API. Secondly, there can be situations where the scouts data is more representative of the robots capabilities than the official scoring. A good example of this is in 2020/2021 where a robot would successfully climb only to have their climb nullified by their partner contacting them in order to get a last second park. The scout should consider that a successful climb while the API would have that as a park.

1 Like
19

I did not even think of this, in that regard yes – scouting data is much more accurate. The API pulls directly from ref panels and from the FMS, so if a team’s hangar climb gets nullified or if they are awarded a free traverse the API would reflect that accordingly but scouts would not just like your 2020 example. Thanks for pointing that out!

20

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.