Waymaker: Basic Field2d Waypoint Editor Proof of Concept

[shueja]

This PR is a draft. This code is nowhere close to ready to merge.

The intent of Waymaker is to leverage the Field2d Glass widget pose-editing capability to create a desktop app that previews the spline defined by a set of poses, and provides a code snippet to generate the corresponding trajectory in user code.

What's done so far:

• [x] Strip out everything from Glass besides Field2d
• [x] Adjust the rendering of Field2d to draw splines between the poses, using the existing spline backends for cubic/quintic.
• [x] Add a text box that displays the x/y/theta of each point.
• [x] Separate the Field2d configuration options to their own panel and add a config section per-trajectory. What is next:
• [ ] Change the text box to generate code snippets.
• [ ] Find the many bugs in the code.

Again, this is a DRAFT.

[virtuald]

Screenshot and concept sounds great. Feels like it belongs in its own repo, just like sysid?

[shueja]

I thought of doing this, but I also realized I'm using dependencies from wpimath (for the spline generation) and code from Glass, so I don't know if it makes more sense for it to be in the monorepo or a separate project.

[PeterJohnson]

Sysid is in a separate repo because of vendor deps. In general for imgui-based tools it is much easier for them to be in the monorepo. In particular in this case there would be benefits to potentially refactoring the Field2D differences so we can maintain just one version of the implementation in Glass.

[Starlight220]

What's the status of this?

[shueja]

Abandoned by me due to lack of C++ knowledge plus the start of the season. I think the simplest tool that would suit the basic use cases would be the following: Leverage the existing Field2d widget code so that users can add field objects (pose sets) that have splines traced between them. Save the pose set data in a JSON for reopening later. For actual integration in the user code, generate a Java/C++ contstructor for the Trajectory object (yes, it's codegen, but for a single constructor, the templating is simple IMO). Users then copy the constructor to wherever they create their trajectories in their code.

I think this is a good way to replace Pathweaver because:

• Pathweaver's main value after the introduction of on-robot trajectory generation is as a visualizer, not a generator.
• At least on my team, the workflow to use Pathweaver involves drawing the path, then clicking each point in turn to copy the information into the Trajectory constructor.
• The actual GUI code here is fairly limited, and I already had a PoC for it in the second commit.

Any way the PathWeaver replacement ends up going, I'm not particularly opinionated. Just wanted to share the thought process at the point I decided to abandon the original idea.