How do you use overrideXFeedback and overrideYFeedback without knowing the current reference state for current trajectory?

[WarrenReynolds]

We absolutely love PathPlanners AutoBuilder functionality that allows you to make a complete auto routine with multiple paths and multiple commands along the path and at the end points as well all from a GUI interface.

But last year we found ourselves wanting to follow an on-the-fly generated path in the middle of an AutoBuilder constructed auto. We never got it to work, as the on-the-fly generated auto intake note command required the drive subsystem and this hence cancelled the AutoBuilder command. At the time we couldn't understand why this was happening, but now we fully understand why it couldn't be done, because of the susbsystem requirements issues.

When the overrideXFeedback and overrideYFeedback methods were introduced into path planner we thought this would allow use to achieve the functionality we were trying to achieve. But putting these into practice is proving harder than expected. The conceptual problem we are facing is that field relative X Feed forwards and Y Feed forwards are being generated from the path data, and these are coming from the referenceState that is continually changing as the path is being followed. The external feedback correction that is supplied from outside autoBuilder has to fight against these feedforwards without knowing what they are. The other issue is we don't actually know where we are up in the path to as we can't see the reference state data.

So we are struggling to see how these feedback suppliers could actually be used in practice.

Feature request: Would love to see the ability to be able to follow on-the-fly generated paths between following pre-programmed paths from AutoBuilder. IE: if it's a command at an end point of a path that has to finish before the the next path can be followed, let it require the drive subsystem if it needs it. As the AutoBuilder path following and on the fly path following would never be running at the same time this should be allowed to happen.

[WarrenReynolds]

I've been thinking about this. Although it wouldn't be advised as it is a hack, would it be possible to create an on the fly command using FollowPathCommand::FollowPathCommand and not supply the drive subsystem to the constructor. Then it wouldnt fail the subsystem checking component of the autobuilder.
This command could be added as a named command to be used in the path planner GUI. Provided this named command would only be scheduled to run at end points (ie between paths), it would never produce a conflict with the autobuilder pathfollowing features.
The AutoBuilder should hold the drive subsystem requirement for the entire auto, so the default command for the drive subsystem shouldn't cut in.
I'm not sure if the drive susbsytem requirement is released after the last path is finished or released after the last commands that run after the last path is finished, so if one of these commands (with missing requirement) where runnings at the end of an auto, it might start conflicting with the default command for the subsystem.

Obviuosly if this on the fly command with no drive subsystem requirment was scheduled as a marker command this would have very undesirable effects.
@mjansen4857 Maybe if another type of Named command was added that was only allowed to be used between paths, then we would have the ability to introduce on-the-fly commands into an autobuilder. Just an idea.

[mjansen4857]

You can follow on-the-fly paths in auto builder like that, you just need to use a deferred command to keep the requirements stuff happy. This can't be used on an event marker, but can work in between paths in a command composition.

[WarrenReynolds]

Do you know where I can find some information on deferred commands?

[WarrenReynolds]

How do you modify your sample code that drives forward x+2m to be a deferred command?
Once this done, are saying that you can Register this deferred command as a named command using NamedCommands::registerCommand("Name to use in Path Planner App", New_Deferred_Command);
and then use it as a named command in the path planner GUI as long as it's is between paths and not on a path?

[WarrenReynolds]

After doing a bit of inspecting of the PathPlanner Lib files (especially PathFindThenFollowPath) I think I understand how a deferred command works now. So ignore that question.

I still can't quiet work out how I could utilize the feedback overrides yet. Maybe in a future version, you could change the constructor to be able to supply an optional consumer of current trajectory state information that the path following is using in real time, then code external to pathplanner would know where the robot should be on the trajectory and hence be able to cancel out the feedforwards if needed, so that it could truly override the feedbacks, and take control.