Override X, Y, and rotation correction feedback

[lidor51]

Similar to rotation override but slightly different, make (separately) option to override x feedback & y feedback, if each enabled it'll make the correct of the outputs based on that instead of the odometry error.

Can be used to implement game piece collection as part of the path.

[WarrenReynolds]

I think I suggested something like this last year. Are you suggesting Robot relative X and Y feedback corrections or field relative?
If its field relative you could add a wrapper around you Pose returner that lets Pathplanner know where it is. Then feed the corrective offset into that wrapper so that the Path follow can correct its path.
Then path planner wouldn't need to be touched.
You could either smooth these changes in with a trapeziodal profile on your delta X and Y or just snap them in and let pathplanner deal with it.

[mjansen4857]

Honestly you're probably better off using a different approach to something like this. Feeding in a different "target" pose seems much more convoluted and error prone than just generating and following a new on-the-fly path. If you just fed in the pose of the game piece, it would have very large correction from the PID controllers, and negate the smooth deceleration that following the path itself would have.

For example:

1. Pre-planned path 1 drives the robot from the starting position to a spot near the game piece, close enough for your camera to see it. Ending with a non-zero velocity.
2. Create an on-the-fly path from the robot's current position to the position of the game piece, then follow that
3. Pre-planned path 2 drives from where you expect the robot will pick up the game piece to wherever else you want it to go

Another option could be to follow a path most of the way there, then take over with a command that will drive straight towards a game piece at some speed, then slow down that speed as the distance to the game piece decreases.

EDIT: This also sort of already exists if you just override the chassis speeds coming from the output function of the command.

[WarrenReynolds]

Feeding in a different "target" pose seems much more convoluted and error prone than just generating and following a new on-the-fly path

I agree that this could be done, but it is possible to make and use a custom path while executing one of your amazing autobuilder compete all in one commandgroup autos. I absolutely love that feature of being able to completely modify what the robot does in an auto, completely from within the GUI.

EDIT: This also sort of already exists if you just override the chassis speeds coming from the output function of the command.

Agreed this is a great feature, it let us switch control of our holonomic rotation over to another system while following a path. This allowed us to auto target continuously. But I'm struggling to work out how you could adjust x and y while following a path. If you added an "adjustment" to x velocity, the corrective action of the path follower would be fighting against you continuously. The more you added or subtracted from the outputs of the follower to move the robot off the course, the more the follower would correct to get it back on course.

[lidor51]

@mjansen4857 sorry for the late response, but would like to hear your take on the following:

1. Pre-planned path 1 drives the robot from the starting position to a spot near the game piece, close enough for your camera to see it. Ending with a non-zero velocity.

If we don't see any game pieces (e.g., camera broken for that match), it would be an undesired behavior to terminate the path.

2. Create an on-the-fly path from the robot's current position to the position of the game piece, then follow that

In this case it might be impossible to utilize markers after starting the on-the fly path, I endorse markers utilization as it's a very user friendly way to define autos. Am I missing new PP functionality? / What's your suggestion here?

3. Pre-planned path 2 drives from where you expect the robot will pick up the game piece to wherever else you want it to go

That's open a different issue (regardless to this feature request). The robot picked a rebound game piece / a game piece that a teammate left me. What would be the best way to "connect" to the pre-planned path 2, with respecting pre-defined markers? (and to keep utilization the UI as much as possible).

EDIT: This also sort of already exists if you just override the chassis speeds coming from the output function of the command.

You're assuming that we would like to add a chassis speeds effort on top of the trajectory feedback, which is not necessary the case.

[mjansen4857]

So just to get this straight, you essentially just want a way to override the X/Y speeds corrections, on top of the target speeds from the trajectory? Or do you want to override the speeds output as a whole?

[lidor51]

Ideally we would be able to choose whether we're overriding the controller feedback, or overriding the output speeds entirely.

That will be the best, but if you have a reason to implement only one option, I suggest it would be overriding controller feedback (on top of trajectory speeds). Since we can override entirely the output chassis speeds output if we really want to.

[mjansen4857]

Yeah I think overriding the speeds entirely is better suited to your output function or a different command entirely. Overriding the feedback does make sense in some cases though so that can be done.