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: https://github.com/FRC6854/PathPlannerViking
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).
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.
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.
