2020 ZEBRA Data Parser Zones

Hello everyone, I’d like to make a thread to gain feedback on how to build zones for my ZEBRA Data Parser in 2020. If you are unfamiliar with my data parser, take a look at my TBA Blog posts on it.

This is a very new way to analyze FRC data, and as such there exist no established standards on how to build these zones. For 2019, I just threw together some zones in order to more quickly move to other analyses, and since it was a proof of concept, did not spend as much time on it. However, for 2020, since we will have dozens of events worth of data, I want to make sure to build these zones as best as I can from the getgo.

My general feeling for zones is that they should be between 1 and 4 robots in size. Making them smaller than a single robot generally seems silly, as at that point there will be little distinction between zones, and the differing position of the ZEBRA trackers on two robots will cause different zone designations even if the robots are sitting in the exact same field position. On the flipside, a zone greater than 4 robots in size is likely too large, and should be broken up into one or more smaller zones so that we don’t limit ourselves to zone use cases that we don’t think of right away.

Another current restriction that we have is that zones must be triangles or concave quadrilaterals. I have trouble imagining a case where a convex polygon would make a useful zone. The fact that we cannot use pentagons though seems to unnecessarily restrict us for 2020 though, primarily in the weird area near the trench and the nearest shield generator support beam. I am tentatively planning to add concave pentagon and concave hexagon zone support in my next data parser update, as I can’t find a good way to make zones in this area without pentagons.

With all that out of the way, here is my first pass at what I believe would be a good zone splitting for 2020. Note that I’ve only marked a half field, the other half would be symmetrical to this.

Let me explain the colors and their meanings:
Level 1 (Green): Green is for the very obvious field markings and structures. This includes the edges of the field, target zone markings, loading zone markings, initiation line, trench run markings, and shield generator boundaries
Level 2 (Yellow): Yellow is for the effective areas associated with penalties and/or zone-specific scoring. Since G10 applies to any robot who’s bumpers even cross the target zone, trench run, or loading zone, I made yellow lines to bound those areas. Since G3 says a robot may not have it’s bumpers break the plane of it’s own sector, I put a yellow line on the side of the initiation line near to the field center. Since G9 says robots must break the plane of it’s own sector, I added a yellow line on the side of the initiation line away from field center. These lines together will also be useful for tracking auto mobility points off of the initiation line. I also put yellow lines on both sides of the control panel (these could have been green as well).
Level 3 (White): White zones are for connecting corners of green/yellow lines to each other. This is where things start to become more artistic and less formally defined. Green and yellow lines arise from pretty clear principles, but there are many ways to connect corners. I have a strong personal preference for rectangular zones that are parallel to field walls when possible, so I used the white lines to build these, with the exception of the connection between the trench run corners and the yellow lines surrounding the trench run.
Level 4 (Pink): Pink zones are used to split zones that would be too large without additional splits. These are the lines that are most up to personal preference, and as such I am most interested in feedback on these, as I think there can be good arguments for many options. I chose to split the zones near the initiation line into 7 parts each, in line with the zones near the alliance wall. A reasonable alternative would have been to split these zones into 5 parts each, in line with the zones near the center of the field. I opted for more zones because I believe this area will be a common shooting area, and as such tracking which zone a robot is in with higher granularity will be important. I also chose to split the quadrants of the shield generator in half perpendicular to the switches. I think this is a more natural split than to go parallel to the switches as robots will swing some while hanging. I could have split each quadrant into 3 zones instead of 2, but that was starting to get small. I can see an argument for 3 though as it would better mark endgame locations for robots. I also split the long side of the trench run and adjacent penalty effective area into 3 zones. This comfortably puts one ball in each zone for potential auto tracking, and makes each zone around the same size as the other trench run zone on the far side of the trench. I could see splitting this area into 2 or 4 zones though.

Let me know what you think of any of my guiding principles or zone designations! Particularly if you have ideas for use cases of these zones that I haven’t thought of.


After re-reading the G15 rules, I realized that the above zones in the shield generator won’t be able to identify this penalty very well. Here’s my new suggestion for the shield generator (pink/white lines in other areas stay the same as above):

This is getting to be smaller zones then I tend to be comfortable with, but I think it’s pretty important to be able to track penalties as well as possible. The small white lines connecting the support beam centers to the yellow penalty area corners could be placed parallel to the other lines, I have no strong preference as they are so small and close to field structures. This also gives a little bit more granularity to hang positions, which seems useful.

1 Like

Why not just treat them as polygons with N sides? But, I’d probably move this to Postgres at this point.

Each year you create a set of polygons that you can then join robot locations into which conveniently moves the zoning out of the parser and into the processor so you could actually have variable zone layers.

Can I get a printout to hang on my wall?


I am not fully sure if this is captured already but the “penalty zone” from the target zone and loading zone triangles is effectively ~1 robot bigger than the “penalty zone” around the trench because of the differences in G10/G11.

This will be captured with the above zones. G11 will be defined as a defensive robot within any of the opponent’s yellow boundaries that is contacting (within 3.5ft) an opponent robot. G10 will be defined as an offensive robot within it’s own target or loading zone yellow boundaries and contacting (within 3.5ft) an opposing robot. The zone the defender is in will not matter for G10.

1 Like

I will be doing this in the backend. I really doubt there would ever be a need for >6 sides though so I was planning to just restrict to that on the front-end, I could go up to 10 or something though.

I’ve never worked with postgres, so I don’t really know what that workflow would look like. One of my high priorities has been making tools that require no or minimal installation/setup on most computers, which is why I’ve largely been sticking with excel. If there are other tools that also meet this requirement I might explore them.

My thought process has been that there should be only one layer of zones that are very small. Then you can use zone groups to be effective “layers” on the data by selecting what their component zones are. Having multiple sets of zones in a year just seems unnecessarily confusing to me, and would probably make equivalent zones and zone groups harder to use as well.

I mean, your intended questions with zones may be different than mine. For example - if I wanted to see the impact that a 2006 style offensive period rule would have had I could simply create 3 zones across the field and build a simple query compared to having only one set of zones where I have to figure out how to repurpose existing ones.

By allowing larger zones (including overlapping ones) you can likely gain some performance gains with specific types of queries.

It also future proofs your solution by allowing for swapping out zone definitions year by year.

Def look at PostGIS, it adds a lot of stuff you don’t need but it also adds the concept of a Geometry column which will let you do fun queries like “Is this path the robot moved in the last 6 seconds contained entirely within this boundary” fairly trivially.

Unless the front end is building zones you should be able to just send the points down as an array of points and draw them that way?

Those make sense, I’ll try to take a look at PostGIS after the season. I’ll be sticking with my excel book for this season though

The front end is just a set of columns in my excel book, so the more points I allow for the polygons, the more columns I have to check for entries. Not too difficult to add more, but with the restriction of convexity I have trouble seeing a use case where you’d want more than 6-sides.

Yeah, that all makes sense tbh. Lemme know if you want some help with PostGIS. Hopefully by post season I’ll have free time again :frowning:

1 Like

Just my two cents… I think we’re going to see a significant number of teams lining up “straight” in front of the goal to shoot. The way the white/pink zones in front of the goal are set up (up to the yellow line past the INITIATION LINE), those robots could end up splitting between zones right next to each other, depending on which side of their robot the tracker is on.

The data might come out a little better if you set up your lines to match the outer edges of the high goal - that would split the robots into “center shooter” and “angled shooter” profiles, which could be more valuable data.

1 Like

Option 1:

Option 2:

Share preferences, I’m leaning toward option 2.

1 Like

I’d lean toward option 2 as well.


I like option 2 as well for the reasons Jon stated


I too like option 2. Are the (x,y) coordinates of the corners of zones available somewhere? I’d like to play around with this as well if you are open to sharing :slight_smile:

1 Like

I haven’t actually built the coordinates yet. All I have so far is this ppt with the lines on it, so you can modify that if you want:
zoning.pptx (461.3 KB)

Relatedly, if someone wanted to build all the zones for me I’d add a thank you to you in my data parser :slight_smile:
It would just free me up to work on other things on the key stretch leading up to the first competition.

Alright, I’m locking in the following zones:

Only change was making a zone on the center side of the initiation line line up with the shooting zones instead of the center zones, this will make the further shots more comparable with the close shots. @typeusernamehere if you want to print something to hang on your wall this is the one I’d recommend :wink:. If I ever start selling merch I’ll be sure to make a t-shirt with this on it.

Here are the zone IDs I’m assigning. Tried to keep zones adjacent to each other and crisscross the field. Zones 65-128 were defined to mirror zones 1-64, that will make definitions easier as I can mirror the coordinates for those as well. Also, 128 is 2^7 which is a sweet number of zones to have, completely unintentional, but cool.

Equivalent zones will be defined using the same IDs for zones 1-64, and be paired with the zone on the opposite side with ID 129 - (near ID).

I think this is probably the hardest year of at least the last 10 to properly zone. There are weird angles with the field walls, target zone, loading zone, and especially the shield generator. There is also no clear line separating left/right or near/far. Finally, there are multiple penalty-effective yellow lines which create a large number of small zones.


I’d buy it


Here are my preliminary zone definitions in case anyone wants to use them, I haven’t done a ton of validation yet so let me know if anything looks off:
preliminary zones.xlsx (20.5 KB)

I’ve updated my zones a bit. I found out my previous definitions made a few zones (like 61 and 78) concave. This is now corrected and the new zones pass my validation tests.

zone definitions.xlsx (19.5 KB)