Introducing PathPlanner 2.0

Technical
1

Hello everyone! I’ve been working on a total re-work of PathPlanner for the 2022 season and wanted to get a pre-release out there before the season starts so I can get some feedback on all of the changes. If your team already uses PathPlanner or is considering using it I’d appreciate if you gave the new version a try and let me know if something doesn’t work as expected. Read the Wiki for info on how to use the new version.

PathPlanner
PathPlanner2784×1664

Here’s a list of some of the biggest changes:

  • Totally rewritten with Flutter instead of electron. The app should perform better on all systems and be easier to maintain.

  • Path generation is now available as a robot-side library. The Java version of this library can function as a drop-in replacement for WPILib trajectories, so it can be used with built-in path followers like RamseteCommand. Unfortunately, the C++ version cannot be used like this, but any C++ code that can follow a WPILib Trajectory can be modified to follow a PathPlanner path with minimal changes.

  • Added the ability to mark a waypoint as a “reversal” that will stop the robot and reverse direction in the middle of the path. This allows for paths like the Autonav bounce challenge to be done in a single path.

  • Instead of editing a single path file at a time and managing saving them all manually, PathPlanner now opens a robot code project and automatically saves path files into the deploy directory. These files can all be edited, renamed, re-ordered, deleted, or duplicated from within a single PathPlanner window. Now the annoying Edit → Save → Generate → Deploy workflow has been simplified to Edit → Deploy.

  • Overall less janky than previous versions.

Known Issues:

  • There is currently no way for LabVIEW or Python teams to use this new version. A simplified csv file generator should be added to the app before the beginning of the season. If you would like to create a port of PathPlannerLib for your language, reach out and I’d be glad to help you out and link to it on the wiki.

  • Simulating C++ robot code on desktop is only supported on macOS at the moment. I can’t get the windows and linux desktop libraries to compile correctly with the 2022 version of WPILib yet.

Planned Additions:

  • In-app generation for teams that cannot use a robot-side library

  • Custom field images (This will likely not be added until after kickoff)

  • Notifications to inform the user when a new version of the generation library is available

You can download the new version on GitHub or from the Miscosoft Store or Mac App Store to receive auto-updates. Info on installing/using the generation library can be found here.

   

I’d greatly appreciate any feedback!

53 Likes
2

Would you mind going into detail on why you chose the Flutter framework? Did it have something to do with portability, or was it just what your team already knew?

Also, is there documentation on the path schema your application exports to robot code? I don’t see it on the wiki.

1 Like
3

There’s a bunch of reasons why I chose to switch to flutter, but I’ll list the biggest ones I can think of:

  • One codebase that compiles to a native application for each platform.
  • Lots of built in UI elements, so most of the UI work I do is just arranging the included widgets and making them actually do something.
  • Included package manager that probably has a package for doing whatever you want to do, many of them supporting all platforms.
  • Dart, the programming language used by flutter, is really nice to work with.

It pretty much just boils down to it being easy to work with and compile for all platforms without having to do anything platform-specific to get it running.

Paths are saved to .path files in the src/main/deploy/pathplanner directory of the project. These files are JSON formatted and are essentially only a list of every waypoint on the path. PathPlanner paths are Bézier curves so each waypoint has 3 coordinate pairs that describe it (2 for the start and end point). On top of these 3 points, each waypoint contains other info such as the rotation for holonomic drive trains, the velocity override, if the point is a reversal or not, and if the waypoint is locked in the GUI or not. Its probably better to just show an example of a waypoint so here’s an example of a path file with all but 1 waypoint removed:

{
"waypoints": [
    ...
    {
        "anchorPoint": {"x": 5, "y": 5},
        "prevControl": {"x": 4, "y": 5},
        "nextControl": {"x": 6, "y": 5},
        "holonomicAngle": 0,
        "isReversal": false,
        "velOverride": null,
        "isLocked": false
    },
    ...
]
}
4 Likes
4

Looks like a great project, thanks for sharing!

I quickly looked through the wiki examples; I’m curious if the robot-side libraries support arbitrary start/stop velocities. Or maybe there’s an alternative way of performing tasks in parallel with non-zero velocity drivetrain motion once reaching specific waypoints in a trajectory?

if I missed documentation somewhere feel free to just drop me a link, I will read.

5 Likes
5

I believe you’re asking if you can have the path start/end with a non-zero velocity? If so, this can be done with the “Velocity Override” field in the GUI. This normally functions as a velocity limiter for waypoints but if used on the start or end point it will change the start/end velocity of the path. If I misunderstood what you’re asking let me know.

3 Likes
6

Yea precisely!
Sorry, my question made perfect sense in my head :grin:

I overlooked the GUI side velocity limit field, as I incorrectly assumed that kind of feature would be on the robot-code side (since it looks like that’s where the vel and accel limits are defined for the path). Thanks for decoding my intent.

It may be worth including your explanation above for the “velocity override” field when used on start/end points in a path. Definitely a useful feature.

Hope to take this for a spin soon!

2 Likes
7

It looks nice and I like that you are not inventing (much) new code for on the robot, reusing the standard Ramsete, etc.

However, WPILib also supplies PathWeaver. What are the advantages of PathPlanner over PathWeaver? (Not that my team has used either, yet.)

8

Also, are you aware of this thread:

I don’t mean to kill any effort you are making, but it is always good to know your “competition”.

2 Likes
9

I don’t really consider PathPlanner to be a competitor to anything officially supported by WPILib. I think PathWeaver is perfectly fine and probably a better option for a majority of teams. I just release PathPlanner as an alternative for people who might like its feature set better. I think I’d say the main advantages at this point are ease of use and holonomic mode. This is just the first iteration of the new version so there’s not much new yet, but moving generation to robot-code will allow me to play around with some ideas I’ve had for a while but couldn’t do in a standalone UI.

3 Likes
10

We’ve already discussed yesterday. I have permission to copy parts of the feature set of PathPlanner, so the two programs may end up being similar. WayMaker does intentionally avoid anything having to do with velocity, because path information should be robot-independent.

11

In my opinion another great feature on the previous version, that I hope will be integrated in this version as well, is the option to visualize an animation of the robot driving the path. So you can make some initial optimizations on the GUI, before running on the robot.

3 Likes
12

I admittedly have not used either on a real robot yet, but playing around in sims, I much prefer PathPlanner over PathWeaver as PathWeaver repeatedly asks you to save essentially every time you click anything at all, and it’s incredibly obnoxious. PathPlanner autosaves, for better or for worse. I’d recommend creating a git commit between every match if you’re going to be altering paths using PathPlanner during the event, and being very vigilant about the process.

4 Likes
13

Yeah I should mention this in the documentation. You can also duplicate a path and edit that so you still have the original just in case. I think its probably a good idea to add a “Competition Mode” or something like that will disable auto-saving so you don’t accidentally move a point and end up deploying a changed path without knowing.

5 Likes
14

This is really an awesome work . Thanks Michael!

1 Like
15

So , this is just a path creator . And if l use a swerve drive , l stilll need to use the WPILIB’s swervecontroller command?

16

Correct. This doesn’t handle any actual path following, just generates them.

17

Thanks , can l change the background picture myself? Besides , what’s the unit of Robot’s length and width?

1 Like
18

You can’t change the field image right now unless you build the app manually. I do plan on allowing importing custom field images at some point, though this would likely not happen before the season starts. The units are meters.

19

That’s ok.

image

If l draw a path like this , since the heading is the same , so my swerve will only move from the left to the right. However , why is the line between them curving . That’s why?

2 Likes
20

The holonomic angle only controls the rotation of the robot, not the shape of the path it drives. The control points, which are the small white dots connected to the waypoints with black lines, control the shape. If you drag those around you can change the shape of the curve without moving the waypoint.

1 Like