What do you want to see in Pathfinder?

Technical Programming
1

Hi All,

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.

2

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.

Thank you for all the work you put in to this. =D

3

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.

4

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.

5

Ability to specify non-zero velocity at path endpoints.

6

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.

7

Some level of LabVIEW support - or at least easy enough to create a wrapper.

8

+1

9

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.

10

+1

11

+2

[/quote]

12

This is more difficult than it seems, and is something I would likely leave up to the community to implement, as was done with the current version of the Pathfinder Library https://github.com/JacisNonsense/Pathfinder/tree/master/Pathfinder-LabVIEW

13

Native support for reversed paths would be nice. In other words, when the path has the following points:


X     Y     Heading (deg)
0     160   180
120   160   180

The output path should cause the robot to drive in reverse. We did some work-arounds to detect and address this, but if it were part of core pathfinder the application code would be simpler.

Pathfinder is a great resource, though. Thanks for all your hard work! If you want help implementing features, maybe you could put some issues in on GitHub so the community can help?

14

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.

15

+3

I think there is something out there, but it is very obscure.

Some documentation / a tutorial on how to implement it into a labview robot would be amazing.

16

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!

Thanks for the awesome tool Jaci!

17

I’ll leave this here :slight_smile:

18

This will likely be implemented as a flag that gets passed (bool reverse Y/N), since 180deg can also refer to a robot going forward, but facing opposite to where it started.

I plan to put this up on GitHub at some point as a new project, but I’m keeping it private for the time being since it will be part of a larger collection of projects TBD

19

That’s a good point, I’ll put arbitrary start/stop velocities on the list

20

That works, too.

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.