WayMaker: A new waypoint editor for path planning

To answer your “standalone” question, it’s not technically coupled with something else, but it is definitely designed for FRC, and uses the existing WPILIb GUI and trajectory classes internally. It’s built into the WPILIB monorepo, and I’m not sure at the moment what limitations that puts on its portability separate from a full WPILib install.

EDIT: It’s pretty restricted. You’ll have to install WPILIB to get the binary. As a part of WPILIB, the project can’t officially support FTC teams, especially since the library that would be the best way to use the data is unofficial.

My official stance, as limited by being a WPILIB project (hopefully-to-be), according to what I just found out about WPILib/FIRST politics, is that WayMaker is for FRC use only. I can’t link to any resources for other competitions that could help you use this outside FRC (including the one I definitely didn’t previously have linked at the top of this post), and I can’t offer support if an issue doesn’t affect FRC teams. That said, I’m not going to stop you from using it for other purposes (and depending on how you read the BSD license that applies to it, I actually can’t).

All tools built as part of our monorepo get published to Artifactory. Once there, you can just download the .zip, extract it, and run it. I just tried this for SysId and it ran out of the box.

Here’s the Artifactory URL as an example:

and the direct file URL:


I’ve added a cubic/quintic switch and support for styling the track differently from the points. Also the settings popup is now a persistent window.


Trajectory reversal (shown here on quintic)


I want to correct what seems like a misunderstanding here. As individual volunteer contributors, all of the WPILib developers can (and often do) help outside of FRC use cases or the officially supported languages (for example, I created RobotPy, and I still occasionally contribute and help with issues there, even though it’s not an officially supported language).

At a top level, we are careful about what we communicate regarding what is officially supported by the overall WPILib organization and FIRST, mainly because we are resource limited and can’t be everything to everyone. This does limit what we say and link to in our published documentation, as having information in the docs implies that it is supported by us. The docs have some additional restrictions/coordination required with FIRST, as the WPILib docs site is also used for broader FIRST control system documentation.

But again, this does not limit what individual developers can say or do (e.g. via posts on online forums such as this one). Of course, just like those with associations to a FRC team or a workplace, it’s important to be clear when we are speaking for ourselves or the organization, and what we say reflects on the organization.

EDIT: In case it wasn’t clear, we in the WPILib organization love seeing our libraries and tools used for non-FRC things. However, due to resource constraints, we just can’t guarantee that it will work or promise to support it, but we generally will try to help as much as we can!


Where do you think this will stand come January? Part of the monorepo release or just the fork? I was fixing to make a pathweaver PR dump to json (and up convert existing path config files from their csv), but if this will be ready for prime time I won’t

This will definitely still be in the fork at that point. I think the window is already past for merging big additions like this for 2022. I would like to collaborate on a JSON schema for cross-compatibility. Probably by November I’ll have the JSON export ready to go, which I think is the last big thing before an initial release.

1 Like

I will probably be looking for some teams to attempt to use it in place of PathWeaver, but it feels tacky to ask that during the season, even though that’s the point at which it might be ready for UX testing like that.

Since it’s a separate subproject in the monorepo, the risk of merging it is rather low. I’m not sure where the “JSON config to Trajectory” helper functions would go yet. We can either add it as a vendordep or add it to wpilibc/j and designate it as “incubating”.


At the same time, while I possibly could merge a functional, usable version for 2022, I’m not sure if it would be “better than PathWeaver” at that point, especially from UX standpoints. It would need more iteration post-season when I have more time,before I’d be ready to release as an actual “prime time” tool.

Dev update:

ImGUI has a branch with this docking widgets feature. I decided to try it out, and it seems to work pretty well (speaking from 30 seconds of snapping these widgets together and grabbing a screenshot.)

EDIT: I spoke too soon. Combining two widgets into a tabbed widget seems to crash it, but I’m not going to bother to debug that. Back to regular free-floating widgets.


I used the same names that were present in the CSV file. Open to change them, I didn’t look at what you were doing.

1 Like
# Path
  "name": string,
  "schemaVersion": string,
  "units": string,
  "reversed": bool,
  "poses": [poseObjects, ...], # n poses
  "types": ["CubicHermite" | "QuinticHermite" | "Clothoid", ...] # n - 1 types

This is from Tyler on the Discord. Basically reversal is constrained to be per-path instead of per-point, and poses are x,y, theta. We’re also toying with being able to define interpolation types per-segment, but there’s some interface cases that raises that we don’t intuitively have behavioral expectations for.

This means you won’t be able to describe e.g. the “bounce path” of the 2021 challenges, correct (assuming the most efficient path is to reverse the robot’s direction at the end of each bounce)? Would the expectation be that those are described as separate paths for each “bounce” and the user is responsible for executing them in sequence in their auto code?


1 Like

(I’m defining path as the X-Y coordinates before time domain stuff like velocity is created, path segment as the spline interpolating between two waypoints, and trajectory as the path plus time domain stuff.)

PathWeaver has to generate those as separate trajectories anyway because you can’t reverse individual path segments in a trajectory. The WPILib trajectory API applies reversal per-trajectory instead of per-path-segment.

Furthermore, changing the drivetrain’s velocity from positive to negative requires that it hit zero at some point due to the intermediate value theorem, and trajectory velocities are assumed to be a truncated trapezoid profile with uniform signedness. We’d need a more general trajectory generator/optimizer to handle direction changes in a single trajectory.


I didn’t think you could do that. The checkbox in the gui reverses all the points. We had to make 4 individual paths and concatenate them together.

So that proposed config for waymaker looks good, but seems like a jump that doesn’t make sense for pathweaver right now. I think that should be V2, and when waymaker becomes official (or whenever a team wants to use it) there should be a script to go from my V1 to your V2, using a default for the segment types. I’ll add “name” into V1 though so you don’t have to glean it from the file name

To elaborate on this, the idea is users can change the path interpolation between waypoints. Since they both generate lists of poses+curvatures, that whole thing can be concatentated and passed to the trajectory parameterizer like normal. This is nice for mixing splines with constant or linearly changing curvature turns (aka clothoids) around cones. 2021 barrel racing is an example application.

An example of the interface problems mentioned is what should happen if the user removes a waypoint between a cubic hermite spline and quintic hermite spline. They are incompatible since one specifies headings and the other does not. We could either ignore the quintic’s headings and effectively make the combined path cubic, or choose headings tangent to the previous cubic spline and effectively make the combined path quintic. We won’t know the user’s intent unless we ask them somehow.

While we could give that first example sane default behavior if we wanted, I’m not sure what to do automatically when merging a cubic/quintic and a clothoid since the two merge resolutions have different shapes.

We could only allow users to delete a waypoint if the adjacent path segments have the same type, but it wouldn’t be clear to the user that they need to manually change the type of one of the path segments first. If we generate a popup if they attempt it, we could just as easily delete the point anyway and ask for a merge resolution, which has a better flow.

Note that merging path segments of the same type is trivial. Cubics and clothoids would discard the heading of the start/end pose connecting them, and quintics would discard one of the start/end poses since they’re identical.


Thought after reading this very thorough description of the issue. I’m going to need click targets/pop ups for editing a segment’s type anyway, so I figure on point delete, I can open that pop up at the screen location of the deleted point to select the type for the fused segment.

1 Like

Update: I have started a formal design doc for WayMaker:


Ignore the design doc link above. Use this Markdown version instead, hosted on my fork of WPILib:

This will be the updated one from here on