use perimeter stepping for crease defenders instead of shotcones

[annieisawesome2]

Description

Currently, CreaseDefensePlayFSM handles only 3 crease defenders to occupy 3 positions. We used shot cones to find where the robots should be positioned. However, when the shot cone angle is small there would be one robot clustered in the middle and not really doing much so want fewer sometimes. To do this, perimeter stepping along the defence area was implemented.

There was a bug in stepAlongPerimeter where the mid-segment starts to interpolate from the segment start not the closest_start so the steps were wrong. Fix: first segment starts at closest point on perimeter.
Tests were added for crease defender so LEFT and RIGHT matches +/- step from the centre. Also added perimeter stepping tests for bug.

So far this seems to look like it fixed the issue of the shot cones always using up 3 robots.

Testing Done

Updated C++ tests and made sure they all passed.
To visually see the change working i ran ./tbots.py run thunderscope_main --keyboard_estop and tested placing the ball in a couple places like centre and the side where the shot cone caused different spacing of robots. Here I had 2 robots to demonstrate how the spacing was super close when the angle was smaller and the 2 crease defenders were further when enemy was in the centre causing a larger shotcone.

This is before the fix. Notice crease defenders 1 and 2 are spaced further.

And when angle is close they are spaced super close. Since we can have up to 3, when there are 3 crease defenders, in this situation they cluster causing one to be very useless. (robots 1 and 5 are the crease defenders here)

Here is the fix where the 2 crease defenders are always evenly spaced based on robot radius.

Screen.Recording.2026-08-22.at.12.30.26.PM.mov

Resolved Issues

In my opinion doing the perimeter stepping solves the dynamic number of robots as crease defender?
#3374
#2995

Length Justification and Key Files to Review

Review Checklist

It is the reviewers responsibility to also make sure every item here has been covered

• Function & Class comments: All function definitions (usually in the .h file) should have a javadoc style comment at the start of them. For examples, see the functions defined in thunderbots/software/geom. Similarly, all classes should have an associated Javadoc comment explaining the purpose of the class.
• Remove all commented out code
• Remove extra print statements: for example, those just used for testing
• Resolve all TODO's: All TODO (or similar) statements should either be completed or associated with a github issue

[StarrryNight]

Nice work! Added a few comments

[annieisawesome2]

**perimeter^^ LMAO

[annieisawesome2]

@mkhlb Please let me know your concerns about this brought up at the sprint presentation.

[annieisawesome2]

Not sure if this improves play. Will come back after ai vs ai data collection and analysis done.