Define waypoint locations based on other waypoints

[nlaverdure]

Real-world FRC fields are often assembled with errors and asymmetries (sometimes far in excess of the assembly tolerance listed in the game manual).

To account for this, teams frequently need to tweak and tune their paths when they arrive at events. This can be difficult, given that their only resources are:

• A brief window for accessing the field and taking measurements by hand
• Opportunities to witness the success/failure of their auto modes in matches
• (If teams have some kind of mapping technology, they could also use that during matches and/or during the official measurement period)

photo credit: Zach Clarke

We can increase the competitive success of teams using Choreo if we can help them complete this tuning activity faster, enabling their autos to work as designed earlier in the event. One way to do this is to decrease the number of by-hand measurements that teams would need to take to ensure their waypoints align with the critical field geometry.

In Choreo and other pathplanning software, waypoints are typically placed with respect to the global coordinate system. If waypoints could optionally be be defined relative to another waypoint, we can reduce the number of independent references to the global coordinate system.

A special kind of waypoint, an anchor point, could also be created for the purpose of anchoring these relative waypoint definitions. An anchor point would have no affect on the trajectory.

Teams could construct their paths such that when they arrive at a new event, they'd simply need to adjust the position of a few anchor points to get a high degree of confidence that their autos will hit. In the 2024 game, these anchor points might be:

• The center of the base of the two Speakers
• The center of the base of the two Amps
• The position of the 11 "spike marks" where field resetters will stage the Notes

[nlaverdure]

Choreo would need to prevent the creation of circular dependencies (chaining together a closed loop of relative waypoint definitions)

[shueja]

Is this addressed by #566

[shueja]

Considering this addressed by expressions/variables, with future QOL/usability enhancements possibly to come