This is the biggest change IMO. It means that robots with more than four sides have an extension limit where the projection of the frame perimeter sides converge, not just at 48". So if you wanted to extend over a corner, you can no longer just add a straight frame perimeter side there and extend over that.
And this is how circular bumpers die. Not with a bang, but with the extension rules.
They died once plywood was not considered plywood years ago.
That’s not how I interpret it. Granted, the blue box shows a rectangular robot, so it’s hard to tell from the picture what is intended. I would interpret the rule as projecting that side straight out from the robot, not projecting the adjacent sides out until you either meet or hit 48". In other words, I would say it’s the red projection below, not the blue.
The key is the wording “that side of the frame perimeter” - I’m projecting one side with the red, perpendicular to the frame itself. With the blue, you’re projecting an extension of two separate sides.
Agreed. It’s the projection of that side.
I’m not so sure you’re reading that correctly. I think that what they’re actually saying here is that the projection of that frame perimeter runs directly outwards at right angles to the frame element. So a flat corner would be able to be extended past, but you’d have to keep the width of the extension less than the width of that frame perimeter (i.e., if the corner piece was 6" long from corner to corner, you could only have a 6" wide extension that went straight our from it.) Admittedly, that does still limit what can be done with extensions more than otherwise, just not quite as much as you’re interpreting this.
Anybody want to ask in the Q&A for a hexagonal and triangular frame perimeter to be added?
If blue is correct we’re going to get some pretty sharp bumpers. Unless this config violates some other bumper rule.
I’m pretty sure that frame perimeters are by definition convex.
But if someone made a triangular base, the “blue” interpretation will lead to some wacky extensions!
inb4 spike bot
Got it, this one is much more realistic
The images in this thread give me some mad abstract art vibes.
I’m calling it the “primary tangent” period.
I was actually having PTSD from my college classes on Feynman diagrams
I’m sure we can figure out a way to use the quantum superposition principle to show that robot was extended into the projection of the frame perimeter and fully contained within its frame perimeter at the same time.
Already done.
I’m a little concerned about the change in section 11.6.2.
I really prefer to play with the worst robot in the competition few times rather than playing against the best one few times
Assuming I’m in the top 5 robots in the competition, getting to play against the best robot 2-3 times would destroy my placements while getting to play with a bad robot on my alliance is not as bad, considering it is a 3 robots alliance and 2 robots can “carry” it while it is playing defense
It’s not actually a change. It’s just being updated to reflect the reality of the scheduling algorithm that has been used for several years. See this thread:
I’m not sure I understand, according to this, is it still practically the same order as before but they just corrected it in the manual?
If it is, they need to change the system, not the manual, playing against the 1st seed in our DCMP 3 times in 2022 and loosing all 3 matches was really bad for us last year for example
That’s right, they just corrected the manual to match what the system already has been doing.
There’s a lot of analysis/discussion of the algorithm in the second link of the post I linked above.
If a bug can be defined as behavior that doesn’t match the specification, sometimes the fastest way to fix a bug is to change the specification.
Caleb has emailed FIRST about it a couple of times, so I think they know about the issues involved by now.
It may be that they really do prefer duplicate opponents over duplicate partners, and think the current algorithm is correct.
It may be that they think improvements could be made, but they’re busy dealing with this season, and don’t want to change something this important so close to competitions, but have it in their list of things to look at for next year. (Sometimes running software with known bugs is preferable to running software which may have unknown bugs.)
If you’d like to let FIRST know your opinion of how the scheduling algorithm should work, I suspect that if you email [email protected] a well-written, thoughtful letter about the issue, you’d probably get a well-written, thoughtful letter in reply.