I’m sure many of you are aware of the Pathfinder library, based on 254’s MP implementation from 2015, which has seen a lot of use in this years’ season. I’m currently in the progress of creating the unnamed, new rendition of Pathfinder, which is set for an announcement of its own in the future. The timeline for this project is at this point unknown.
There are already a ton of new and noteworthy features being worked on, including better respect for robot kinematics (not violating vmax and amax), capability of following tighter paths, more control over waypoints, new curve types and the ability to work in more than 2 dimensions for special systems.
Since Pathfinder is being used by over 60 teams in their autonomous programs this year, I wanted to get an idea of what you, as a community, would like to see from this library.
There’s a poll setup, but please feel free to start a discussion below if I’ve missed anything, or if you want to expand on your vote further.
There’s no guarantee everything will make it in, but this post will be an instrumental tool in determining the development path of the project in the future.
It would be wonderfull to see the ability to incorporate vision, range sensors and other types of sensors to adapt the path “on the fly”. I’m still working out how feasible this would be but as long as you could stay 10 or so trajectory points ahead of the follower it seems like it could be done.
This is also being worked on! All paths are completely functional in their generation, meaning you can change your previous point based on your robot’s current position, vel and acceleration and it will compensate.
I’d like the option for tighter turns. In doing a side switch/side scale autonomous, we tried having the robot end at a 90 degree angle, but in order to do so, it curved outwards really far first and would become far less accurate the tighter we made it.
Seconding and expanding AntMan above me, having non-zero starting and ending velocities.
This way, we can build piecewise paths that, for example, have a faster top speed during a straightaway, and a lower top speed during turns (since pathfinder doesn’t currently respect vmax/amax with tank drives during turns). Right now, our paths max speed is limited based on the max speed we achieve while turning.
This could also allow teams to use pathfinder to build a pure-pursuit system like 254 used in 2016 without having to rewrite much of the library.
This is being fixed by allowing the tank drive calculator (coupled drivetrain) knowledge of the velocity profile. Instead of generating the profile and path, then merging them, it all happens at once so the max values of the velocity profile can be adjusted according to the model of the robot. In the new version, you will be able to do this without piecewise paths and still respect your robot constraints.
Pure pursuit is something I’m looking at for implementation, also.
Being able to specify non-zero endpoint velocities would still be useful for constructing piece-wise paths even if Pathfinder is being changed to have knowledge of the velocity profile. In Power Up we calculate every path we might use in auto in robotInit (Java FWIW) then choose the one that will be followed based on plate assignments and DS input. This approach could lead to some redundant calculations for paths that start out the same then diverge; for example, there could be a routine to drive straight then curve left and a similar but not mirror-image routine to drive straight then turn right; if the drive straight part were the same in both, it would be more efficient to calculate the drive straight path once then continue with either the curve left or curve right path, ideally without coming to a stop at the end of the drive straight path.
More swerve support. And what I mean by that is somehow being able to rotate and move along a path at the same time. Im not sure if thats possible with how it is currently set up. And you’d need a way to do the kinematics of that because you wouldnt know how far you have actually moved…
Also, being able to do tight turns and moving forward and backwards within the same path would be great!
Our implementation assumes a path is either all forward or all reverse. If the output heading starts the same as the input heading, the path is forward. If the output heading is 180 degrees off from the input heading, the path is reverse.
My intention behind doing it this way is to keep the paths general where you specify the robot orientations at given positions and the planner determines the direction of motion to achieve that.