pathplanner icon indicating copy to clipboard operation
pathplanner copied to clipboard

Have an option to "end early" a path

Open lidor51 opened this issue 1 year ago • 6 comments

For example we would like to end earlier a path in case we collected a game piece 1m/1sec earlier than planned.

We would like to end earlier the path to save time (and start rhe next path from this pose, using the appropriate replanning config).

lidor51 avatar May 12 '24 11:05 lidor51

In this case we might want to tirgger in order all remaining markers.

lidor51 avatar May 12 '24 12:05 lidor51

@mjansen4857 IMO it's super important feature for the future of autonomous, it'll allow better support in game-pieces vision based decisions. How it's aligned with this summer prioritization?

lidor51 avatar Sep 14 '24 08:09 lidor51

This is awkward. I just replied to you in #721 with my PR (#923), but it also allows for this, and it is one of the examples. You just need to add the FollowPath and WaitUntil to a Race group

HenryLeC avatar Dec 07 '24 04:12 HenryLeC

My point here wasn't on how to technically end path early, as it's possible as you stated. The thing to consider when ending path early is that the next path will consider the new starting point location (that might be dynamic and changed based on where a game piece was intaked).

lidor51 avatar Dec 07 '24 08:12 lidor51

I did play around with this problem in simulation and the solution I’m going to try on a real robot is starting the next path in a location that you can pathfind to and then path finding to it before starting the path. The solution is not ideal because it requires runtime computing of the path so is therefore maybe nondeterministic, but pathfinding has been shown to work pretty well during the 2024 season. You will also be abruptly stoping the robot between the paths which is not ideal and may cause problems.

Currently there is no way to pathfindThenRunPath from the UI so once I get to test this I am going to add that to the UI and lib

HenryLeC avatar Dec 07 '24 12:12 HenryLeC

I see some scenarios in which there are issues with your solution to patch pathfind to the next path (e.g., we need to run a shorter path than the original path, so pathfinding to the original start point will make our auto longer than needed), instead if we're too far from the next starting point, running pathfind to pose would be a general solution that can work. (Technically on the fly generation would also work but it's harder to implement a solution that works in the general case).

My suggestion: Implement Pathfind to Pose from UI, that need to have an adequate solution to trigger other subsystems commands during pathfinding (e.g., based on distance from start point or to end point).

lidor51 avatar Dec 10 '24 06:12 lidor51