Open carbotaniuman opened 4 years ago
The serialization should beas follows:
generateTrajectory(
cubicWaypoints.start,
cubicWaypoints.interior,
cubicWaypoints.end,
config)
config
object taken by the GenerateTrajectory
method, and should deserialize into that object.So the 2 ways forward that I think need to be decided between. They each have their own benefits and I'll try to explain both.
We change the format pathweaver stores its paths from csv for path and json for constraints. Keep a project level config file in json , but duplicate all the robot constraints in a single json for path + config. If users want to change specific constraints per path they are able to. (this is mostly a coincidence) Now the exact internal PathWeaver path save file is the "serialization" with 5 points, that gets beamed to the robot. It is silly to come up with a new data format and have a bunch of equivalent ones floating around. Then during robot startup the robot opens all its path descriptions and processes them into a full trajectory. Some mechanism to make the pipeline automatic would also be convenient.
We make a command line utility that ships with wpilib. It's only job is to open PathWeaver path and constraint files and run the wpilib traj gen code and dump the output trajectory to disk on computer. Then we make gradle task for deploying code that runs our command line utility on every path and puts the output into the robot deploy folder. Which is then ftped onto the robot. This is nice because while the current traj gen is fast enough to run on robot, future algorithms might not be and it unifies all of them.
I would be capable of writing the Gradle utility for the second one assuming the module system if up and running. That way, making a new path implementation is as easy as adding a module to Pathfinder, and you got both visualization and following (via Trajectory) for free.
I would be capable of writing the Gradle utility for the second one assuming the module system if up and running. That way, making a new path implementation is as easy as adding a module to Pathfinder, and you got both visualization and following (via Trajectory) for free.
Ya lets go with you start doing that. It keeps everything unified. Also others that attempt to use pathweaver for non FRC uses will probably prefer the precomputed command line option.
And I like the idea of a module system where backends are automatically added to both systems.
The second one sounds similar to something I started implementing here. I'm also interested in a feature like this.
Is this still relevant? If I remember correctly, Trajectories are serializable to (or at least deserializable from) JSON. Additionally, does the serialization to Struct/Protobuf for NT/DataLog affect this?
Tracking issue for the JSON Serialization of Trajectories from PathWeaver to Java and C++ Robot projects.