JSON Serialization of Trajectories

[carbotaniuman]

Tracking issue for the JSON Serialization of Trajectories from PathWeaver to Java and C++ Robot projects.

[Oblarg]

The serialization should beas follows:

• Pathweaver trajectories should be serialized to an object containing a set of control vectors/waypoints, and a set of config parameters.
• Clamped cubic trajectories should have a control vector at either end, and waypoints in the middle.
• Quintic trajectories should have a full set of control vectors.
• The Java/C++ code on the WPILib side should have matching objects to be deserialized into - one for clamped cubic, one for quintic. The API for generating a trajectory from the serialized waypoints should ultimately look something like this:

generateTrajectory(
  cubicWaypoints.start,
  cubicWaypoints.interior,
  cubicWaypoints.end,
  config)

• Configuration parameters should match the ones required by the config object taken by the GenerateTrajectory method, and should deserialize into that object.

[gftabor]

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.

1. 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.

2. 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.

[carbotaniuman]

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.

[gftabor]

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.

1. Maybe modify the pathfile structure to include the name of the backend it assumes. That will be important if more are added
2. As a note backends might also require different parameters. For now just assume they all need point/ control vector for every waypoint, extra info is better than not enough. Eventually might need to dynamically save more data depending on algorithm.

[blomqcon]

The second one sounds similar to something I started implementing here. I'm also interested in a feature like this.

[Starlight220]

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?