Generate right and left paths for use with Talon SRX motion profiling

[agasser]

Is your feature request related to a problem? Please describe.
In 2019, PathWeaver generated three paths, one for the drawn trajectory and two for the drive wheels. These trajectory CSV files would then be loaded with PathFinder, translated, and streamed to the Talon SRX for motion profiling. In 2020, no CSV is generated, but worse, there are no trajectories for the right and left wheels.

Describe the solution you'd like
Ideally, two CSVs would be generated like last year that include at least position, velocity, and heading. A JSON or other format would work, but it would require some additional coding to load the translate.

Describe alternatives you've considered
It seems like the recommended approach with PathFinder in 2020 is to write your own code to deserialize the JSON and then use RamseteController to drive the bot. This requires new code and a new unproven solution, in addition to processing on the roboRIO instead of taking advantage of the Talon SRX closed-loop features.

Additional context
Why does PathWeaver project setup ask for the robot wheelbase, is that even used?

[prateekma]

In 2020, no CSV is generated, but worse, there are no trajectories for the right and left wheels.

This is intentional, as the new trajectory code uses odometry to correct global pose error, and this is something that previous solutions did not offer.

This requires new code and a new unproven solution, in addition to processing on the roboRIO instead of taking advantage of the Talon SRX closed-loop features.

The solution is not unproven. Several teams used the Ramsete controller for autos in 2019 and several beta teams have tested the exact implementation in WPILib this offseason with great success. You can still offload the velocity controller to your smart motor controllers if you'd like, but I see no benefit to performing the motion profile itself on a motor controller when it cannot correct for global pose error. There is no downside to performing this on the roboRIO: the performance hit is negligible.

Why does PathWeaver project setup ask for the robot wheelbase, is that even used?

The track width is used to ensure that the generated trajectory slows down enough around turns such that no wheel speed goes above the specified max velocity.

[PeterJohnson]

We are not planning on supporting Pathfinder for 2020 and beyond. If you still want to use Pathfinder, you can use the 2019 PathWeaver instead (it can be installed in parallel using the 2019 WPILib installer). I agree the documentation needs to be updated to show how to load the JSON file (captured in wpilibsuite/frc-docs#438).

[agasser]

I probably used the wrong wording when I said "unproven". Although it may have been proven by some teams in the offseason, it has not been proven by our team. In any case, this change and the required effort to get it working is non-trivial.

[prateekma]

I understand that it is something new, but it's a change for the better. Hopefully the very comprehensive and step-by-step documentation for path following will help a lot. We were able to get the entire setup working in about an hour with minimal tuning.

[agasser]

The documentation is helping, but I'll be honest, my team has spent 15-20 hours on this since Saturday and we still don't have it working with complete success. It's hard to believe anyone could get this working in an hour. Just running characterization took about 2-hours of time: installing Python, understanding the parameters, adjusting the values and getting the robot driving and spinning in the right direction, etc.

I don't disagree, this is a change for the better but it's just a really big breaking change to PathWeaver that I missed in the beta. The only mention of it in the release notes is, "Updated to output WPILib splines." It doesn't even call it out as a breaking change. There is not a single comment in the beta discussion that mentions PathWeaver, although there are a few teams who mentioned trajectories.

I'll close the issue since it's clear there is only one way forward. Thanks.

Just for other team's sake who may have landed here, if you want to run the 2019 PathWeaver to output CSVs, an easy way to do it is to add it to your build.gradle. Doing this will allow you to run gradlew oldPathWeaver at the terminal to launch the 2019 PathWeaver.