Enumerate BAYs on the field

[matthew-reynolds]

🚀 Feature Request

We need to establish a consistent standard to use across our system to describe the field. Some of the elements of the field have intrinsic, intuitive descriptors (ie. left vs right human player station, left vs right level 2 HAB, left vs right rocket, etc). However, there is no immediately intuitive way of enumerating BAYs on the field, and the manual doesn't give us a way.

Reminder that a BAY is the combination of a HATCH (the location that a HATCH PANEL can be placed) and its corresponding CARGO.

This is an open discussion - Please give feedback or alternatives to these formats. The first step is to pick an array format. Once we have that, we can determine how to enumerate the bays within each array.

Array Format - UPDATE 03/29, we will use option :two:

:one: Unique ID for every bay on each half-field

• Represented as an array of 20 entries, convering a half-field. We would create two of these messages/datatypes/whatever, one for PARTNER_ALLIANCE and one for OPPOSING ALLIANCE
• I like separating the two alliances into separate objects because we use the data very differently, and frankly we care a lot less about the state of the opposing alliance's half field
• I like separating the two alliances into separate objects because it makes it easy to know which side of the field is ours, which side is theirs, without needing to parse a big array or something

:two: Unique ID for every bay per ship on each half-field

• Represented as three arrays (left_rocket[6], cargo_ship[8], right_rocket[6]).
• Same as :one: with respect to two instances of the structure, one for each alliance

:three: Unique ID for every bay on the whole field

• Represented as one big array of 40 entries.
• Maybe 0-20 is always our alliance? Maybe 0-20 is always red? idk

:four: Unique ID for every bay per ship on the whole field

• Represented as six arrays (red_left_rocket[6], blue_cargo_ship[8], etc)

Enumeration within each array

Now that we know how the bays will be separate into arrays, we need to figure out how the bays within each array will be enumerated.

Rockets

Within each rocket, I will advocate very strongly for bays on the same level to be sequential (ie. bottom-left is 0, bottom-right is 1). From a coding perspective, this makes it simple and intuitive to group a pair of bays at the same level, which will need to be done frequently. The calculation to convert bay to level is floor(0/2) == floor(1/2) == 0, floor(2/2) == floor(3/2) == 1, etc. I also think it makes sense for bays that are physically lower to have lower numbers. Therefore I think the following is the best option for enumeration:

Feel free to disagree with the above, just please explain why and what you think is better. If we do go with this, then the question is are even numbers:

• :one: Always on the left when facing the rocket, as in the image above. (Even on right doesn't make sense, we read left to right)
• :two: Always on the side of the rocket closest to the driver station
• :three: Always on the side of the rocket furthest from the driver station

Cargo ship

I think trying to pair opposite bays on the cargo ship is confusing and pointless. It makes sense on the rocket, where the pairings would be logical and have function, but I think the same scheme would be just be confusing and wouldn't have any purpose on the cargo ship. In my eyes, the only two logical options are to count clockwise or counter-clockwise around the cargo ship. I think CCW from above is prefereable since it's similar to left-to-right. Please let me know if there's a better way to enumerate these.

• :one: Clockwise, from above (0 on the right of the field)
• :two: Counter-clockwise, from above (0 on the left of the field, as shown in image)

[matthew-reynolds]

I (@Matthew-Reynolds), @wmmc88, and @wraftus all vote for :two:.

I won't speak for the others, but I think :two: is the clearest and most straightforward to use. Doesn't have a massive array that would be a pain to sort through, each array is quite localized. I like the fact that each data-structure only contains half a field, since I think that will lead to better logical separation and organization between our PARTNER ALLIANCE side of the field, and the OPPOSING ALLIANCE side.

Perhaps could be store the data in a message such as this, and then publish two of these messages to complete the field state description.

Example FieldState.msg for :two:

float32   left_hp_cargo_confidence
float32   left_hp_hatch_panel_confidence
float32   right_hp_cargo_confidence
float32   right_hp_hatch_panel_confidence
float32[] left_rocket_cargo_confidence
float32[] left_rocket_hatch_panel_confidence
float32[] right_rocket_cargo_confidence
float32[] right_rocket_hatch_panel_confidence
float32[] cargo_ship_cargo_confidence
float32[] cargo_ship_hatch_panel_confidence

[matthew-reynolds]

Heads up - deadline for feedback will be Friday night. Saturday morning we'll pick an array structure and then start the discussion of enumeration within the array(s).

I'm really not a fan of setting a hard deadline, but we need to keep moving forward and this is pretty integral for the whole system, so I don't want to let it sit for weeks.

[Ivan-Z]

I like options 2️⃣ and 4️⃣, no real preference between the two. I think it's gonna be pretty confusing having to memorize 19 numbers for option 1️⃣and 3️⃣. One thing I would like added to it is additional sub arrays for the hab and the human player station.

[matthew-reynolds]

I'm more concerned about enumeration of BAYs here since they have no intuitive identifiers. Human player stations and hab have intuitive Left, Right, etc. They will certainly be stored in the field state datastructure though - I just mean to say that this issue is more concerned with the bays.

[juwels19]

I agree with @Ivan-Z on options 2️⃣ and 4️⃣ with a smaller preference towards 4️⃣. I think its more clear if the arrays are very descriptive with their names (red_left_rocket, red_right_rocket etc.). Also, what do you think of changing the rocket descriptor from left_rocket to far_rocket and right_rocket to near_rocket?

[matthew-reynolds]

I don't think that far and near makes sense for left vs right rocket.

I suppose I should elaborate a bit on how I was viewing left vs right. The first important note is that everything is from the perspective of the driver - This is FRC convention when describing the field, the left human player station is always on the driver's left, regardless of whether they're on the red or blue alliance. Kinda like driving on the right side of the road yields opposite sides of the road when driving in opposite directions, ya know?

My intent with :one: and :two: is that our data-structure encompasses a half field. To cover the whole field, we could publish two instances of the data structure, one for our alliance and one for the opposing alliance. On a given half-field, left-vs-right has meaning, but near-vs-far really doesn't.

I do think that for option :four:, though, red-vs-blue could/should be replaced with near-vs-far or partner-vs-opposing or something.

[gabrielmok]

I personally would go for 2️⃣ as you can have two instances of a “half-field”. I see a couple advantages for it down the road when you’re actually coding.

1) When we’re working with the msg, it allows you to easily identify which specific bay you are referring to (based on the scoring area). 2) Opposing and partner alliance will have a different set of logic respectively, so having a specific FieldState for each would make more sense.

[ghost]

I have no strong preference either way. The more I think about the enumeration the less it seems to affect much of our work. Macros could be wrapped around any of these enumerations and they would likely be the preferred way of accessing the bays regardless of which enumeration method we use.

From the perspective of frc_gym, there is again no strong preference on my end. It's a minuscule fraction of the environment setup and the agent doesn't care how we specify our bays.

If I were writing controls code, I'd probably prefer :two:.

[matthew-reynolds]

@michaelwm I don't understand your point about macros or the fact that they will be the preferred way of accessing the bays, but I agree that this layout isn't going to drastically affect our code. Just want to establish a standard so that communication is clear, we're consistent across the team, etc.

[matthew-reynolds]

Alrighty very clear winner. No one voted for :one: or :three: (I'm happy, they're gross), and between :two: and :four: option :two: was more popular, so we're going to go with that. Thanks for the feedback guys.

We need to figure out how the bays will be indexed within each array now. I've updated the original issue, please take a look and give feedback.

I vote :one: for rockets, :two: for cargo ship.

[juwels19]

I agree and also vote 1️⃣ for rockets, 2️⃣ for cargo ship