Pinging @calcmogul because of previous Discord discussion on this.
Is your feature request related to a problem? Please describe.
Not exactly a problem. This is a discussion / draft/RFC about a hypothetical waypoint editor, similar to PathWeaver but built for WPILib Trajectories and delegating generation of the trajectory from the given waypoints to a component of the robot code.
Describe the solution you'd like
Scope: At the time of posting, my stance is that the editor should not need to know anything about a particular robot’s characteristics. A Trajectory has the same waypoints independent of a robot, and the robot code can generate its own trajectory out of a given set of waypoints and robot-specific constraints. One of the eventually-discovered shortfalls of PathWeaver was that it required constraints and generated frame-by-frame points for the robot to follow.
My proposed alternative would instead export the “curve handle “ waypoint sets for later robot use.
Further thoughts:
- The waypoint export file should be JSON instead of CSV.
- The tool should use ImGUI and build off the Field2d widget, which already has support for building indexed sets of poses in the GUI.
For the record, I have already started on an ImGUI app that uses the Field2d without its Network Tables backend. I’d like to develop this project and contribute back to WPILIB if this would be welcome, but I want to hear use cases and/or problem statements with current PathWeaver, as well as feature requests.
Pinging @calcmogul because of previous Discord discussion on this.
Is your feature request related to a problem? Please describe.
Not exactly a problem. This is a discussion / draft/RFC about a hypothetical waypoint editor, similar to PathWeaver but built for WPILib Trajectories and delegating generation of the trajectory from the given waypoints to a component of the robot code.
Describe the solution you'd like
Scope: At the time of posting, my stance is that the editor should not need to know anything about a particular robot’s characteristics. A Trajectory has the same waypoints independent of a robot, and the robot code can generate its own trajectory out of a given set of waypoints and robot-specific constraints. One of the eventually-discovered shortfalls of PathWeaver was that it required constraints and generated frame-by-frame points for the robot to follow.
My proposed alternative would instead export the “curve handle “ waypoint sets for later robot use.
Further thoughts:
For the record, I have already started on an ImGUI app that uses the Field2d without its Network Tables backend. I’d like to develop this project and contribute back to WPILIB if this would be welcome, but I want to hear use cases and/or problem statements with current PathWeaver, as well as feature requests.