Questions about PathWeaver and WPILIB TrajectoryGenerator for Ramsete controller

When using PathWeaver to visualize paths, you have to give each point in the path a ‘heading’ using the tangent lines. When you put the path points into the TrajectoryGenerator, the intermediate paths don’t have headings associated with them. The headings of the points in PathWeaver make a difference in how the path is visualized. See the pics below. The path points are approximately what the example uses in the tutorial.



Is PathWeaver a good tool for visualizing paths if you’re using the WPI TrajectoryGenerator, or is there a technique that we should be applying to compensate for this, or is there a better tool?
Should we be loading paths from PW instead?

Our team found that PathWeaver was kinda hard to use. So I found PathPlanner and modified it to work with our bot and made our own version. We use the Talon SRX motion profiling but you can easily output the CSVs to be compatible with WPILib. Our version of PathPlanner called PathPlannerViking can be found here:

1 Like

The TrajectoryGenerator can take 2 types of waypoints. The first type is the one you see in the examples, where the headings are only specified for the endpoints and headings for interior points are determined automatically. The second type accepts headings for all waypoints (which is what PW uses internally).

Take a look here to learn more about both types of methods:

I believe there is an issue open for PathWeaver that will add support for cubic splines (i.e. automatic determination of headings at interior points).

Note that you will not receive official support when not using the provided WPILib tools. Please submit feedback on the documentation to help the WPILib developers make changes that will positively affect teams.

Thanks, I’d read through that page and missed the part about the function that takes the heading-based way-points as a list of Pose2d. The second section talks about how the more complex function overloads are more like what PathWeaver does and recommended not using them, which is where I’d say I got the impression not to use the other calls.
I think that at least satisfies my concerns over visualizing what we’re using. Certainly, more complete coverage of path visualization in PathWeaver will be helpful. At least for now, we can approximate headings we might use from there.

The reason we recommend not using those overloads is because it’s a lot of numbers and points to keep track off if you are not visualizing it.

It’s also way easier to end up with a trajectory that has a sharp point in it if you’re specifying the control vectors yourself - even if the path is technically continuous-curvature, there’s not necessarily any bound on how fast the curvature can change, so the “continuity” can easily be rather contrived in practice.

The clamped cubic generator is generally well-behaved, and pretty safe.

How did you add that custom game?

I followed what was laid out here. It’s the standard image from the upcoming release.
I used the zip file.

I suggest using the images from the PathWeaver team now that they’re available. See Pathweaver 2020 Game Help

1 Like

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.