Parking Platforms Closer to Blue?

So I was assembling my field today and noticed something odd in the assembly instructions: they appear to place the parking platforms closer to blue than to red, as seen in the instructions here:


This can be seen better when the opposing sides are zoomed in on:
Red Side:

Blue Side:

This was confirmed upon assembly when the platforms measured ~1in closer to blue than to red.
In fact, the Platforms can even be seen to be off center in the game reveal!

In the field cad they are centered but the standoffs go straight through the tile!

Is this intentional? If so, why?

I guess that’s where this quote comes in???

Looking at my field and I can’t unsee it now.

O NO, an entire INCH.

An inch can mean a whole lot especially if you aren’t aware of it.
As long as teams are aware they should be able to be prepared.
I don’t see this being a huge issue in teleop but it could have an impact in autonomous.

I see it more being an issue for vexu because the larger robot is nearly the size of the platform and any tiny bit off will result in a failed park and a possible tip if the platform is missed by a significant amount.

To be honest this will only really effect programming skills(unless you’re doing a parking auton.) Its fine as long as you are aware of it.

all my autons are so good that this 1inch variance is going to mess things up. adding a pot rn for red and blue side. gosh golly im glad you pointed this out. /s

Then I must notify my programmers

Field variance is very annoying. Especially if it’s just one inch, because every program us humans write, has to be perfect. We’re not robots.

It effects Qualification Matches, even when you can park during Auton.

this could mess with auto. plus now that I’ve seen it it will drive me to insanity

Teams should really prepare for the parking platform to be closer to the blue OR red. Not every event till set every field perfectly. If your auton is sensitive to the variation, you should verify the distance, by some quick visual aid, before you begin the match or skills run.

It’s a good thing to be aware of, thanks for the heads up.

Talk about a rushed game design, they even forgot symmetry /s

Assembled our field a few days ago and noticed this, can’t un-see it now ;-;

I think I might just drill through the mats i cannot deal with this imperfection. Gosh. I spend 4 days balancing my robot so it can have perfect 50/50 f/r and 50/50 l/r weight distribution and then…this…

How am I supposed to live with this.

it’s nOt SyMmEtRiCaL.

You might consider cutting two tubes a little shorter instead. That’s what I would have done in VEX’s place.

Yeah. It’s not hard to correct all of it (like seriously ,drill the two platforms in different locations). I feel like they just got lazy//didn’t expect the people setting up the fields to be able to identify which side is which (thus screwing it up more).

That’s an even better solution. Once you know the limits, it shouldn’t be hard to adjust to get it however they want it. I think this was a regrettable oversight that got missed a lot in the design and testing process.

Tbh - it would’ve been cool if they mounted the entire platform on rails and moved it every match randomly (like how frc powerup had different colour stations).

-but this is vex, so…who needs fancy field setups. We can just charge 1000+ for a playable field setup, and then another 1000+ for a perimeter. Oh, and also, v5? yeah, we can release that in august, 2 months before people compete - yeah, who cares about all the first year teams that can only buy it once.
-so, vex may have bigger issues than this…but…seriously?

While I more or less agree with the rest of your post, I think this is a horrible idea. Random field states at the beginning of the match is a terrible idea. It basically makes autonomous routines involving the randomized objects impossible/impractical, and for what benefit? Having competed in FTC RES-Q (I’m looking at you, debris), I sincerecly hope that vex never implements random field states.

I think it would encourage programming using sensors more and more. For example, maybe with v5, we’d see robot auton routines that automatically calculate score based on what’s scored and what’s not, and automatically decides what’s the next best thing to do to even that score (instead of hardcoding the robot to pick up a cap or park). I think then the 15 seconds becomes more challenging to program. - Changing the field setup would introduce another factor teams get to account for, although randomization does feel pre bad ngl.