Add "point towards" zones

[mjansen4857]

Add a feature to the path editor to allow the creation of zones along the path that will force the robot to point towards a given point on the field. The user should be able to select whether the robot should point towards or away from the field position. This should be pretty free from a generation standpoint, as the rotation target of each path point within the zone can be set based on the field position. This functionality could probably be added to constraint zones for simplicity.

[lidor51]

Super nice, I think that instead of towards/away, allowing a "towards" offset is the best option. (E.g., shooter and "forward" of robot are 90 degrees apart.)

[WarrenReynolds]

Would love this feature to be built into the GUI and the follower code. A further advancement on this would be to have an optional targeting offset feature to allow for shooting on the run ability. The GUI would need to know the horizontal velocity of the shooter as an input for the targeting zone. Then when the trajectory follower is in this zone it could calculate the air time for the shot based on the calculated distance from target point. From this time and the robots current velocity it would know how far the robot is going to travel while the shot is in the air. Which means that you could calculate how far behind the target you need to aim so that the shot would go in while shooting on the run.

Thinking about this, the horizontal shooting velocity to target would probably change with how the shooter changes it angle and or its roller RPM at different distances to target, so it might be better to have the ability to supply an optional holonomic heading correction supplier to the trajectory follower for use in these zones. Then while ever the robot is in the "Track to Target Zone" it is constantly polling the "heading correction supplier" for targeting offsets. If no offset supplier was given during the construction of the path follower object, then the holonomic heading to track would simply be the heading to the target from the robots current position. If a supplier was there to give an offset, then this would be added/subtracted from the calculated heading to target value.

Then teams could write what ever code they wish to calculate the offset required to land a shot on the run based on the robot velocity/ heading information available outside of the path planner follower code. While all this could be achieved outside of path planner following by ignoring the holonomic rotational values generated from the trajectory follower and writing your own holonomic heading control loop outside of Path Planner, it would be a much nicer solution if the holonomic heading was always controlled inside the trajectory follower at all times so that there was always a smooth transition when going in and out of a "target tracking zone".

This made sense in my head when I wrote it, but I just re-read this post and I'm sorry if it doesn't make sense to you . Food for thought anyway. I look forward to seeing this enhancement.

[mjansen4857]

I think something like that is pretty game-specific, as it is pretty much only useful for a shooting game. Plus, if you can calculate what offset you would need to shoot at, you could calculate the actual robot rotation you need to shoot at and then just use the already existing rotation target override functionality. This would probably be a more accurate/robot solution over primarily targeting an angle that may not be the correct shooting angle depending on path following error/speed. etc.

[WarrenReynolds]

I think something like that is pretty game-specific

True, but lets face it, grabbing game elements and "shooting" them to a known position in auto to either score them or capture/ claim them is just about in every FRC game now.

When you are talking about "rotational target override" is this the GUI feature you are referring to, or is there a way to supply rotational target overrides from code outside of path planner at runtime for the trajectory follower to use instead of the values generated from the path?

If its is the former case, you can only specify a fixed rotational target at a single point. This rotation target angle won't change as you drive past the target. And you would need to "recalculate" the angle if a path or speed adjustment was made in the GUI.

If it is the later case and this feature already exists, then that's perfect. We just need to learn how to use that feature.

Having said all that, I still think the feature to holonomically track to field point from inside path planners follower while in certain zones would be a great feature to have, with or without the ability to supply external corrections at runtime. Cheers

[WarrenReynolds]

I did some searching and to answer my own question, its the later.

https://pathplanner.dev/pplib-override-target-rotation.html

Even with sample code.

Only thing I could wish for now is the ability to know when you are inside or outside a targeting Zone so that you know when to return a Rotation2D to track the target or return Null when you want pathplanner to calculate it from the path.

I suppose we could use marker commands to set or unset a drive subsystem boolean member variable to do that.

Do you ever think PP will have the ability to take an optional X and Y correction supplier. Then you could adjust for those last minute lineup issues. NB: I think I might have requested this before in a previous issue ticket.

Here is an idea: Having two marker commands to turn auto targeting on and then back off later could be replaced with a command that only runs while the robot is in a Zone. The logic would be to launch the command when the robot reaches the start of the zone and then cancel the command when the robot leaves the zone. The commands init function could turn on autotargeting, and the commands end method could turn off auto targeting. You could call it a named command zone. Just another idea.

[mjansen4857]

You’re essentially describing some of the functionality planned for adding the ability to use markers as triggers in #676

You could used a trigger based marker to easily set the rotation override method, or use a zone as you describe. The trigger would flip to true when entering the zone and false when leaving, and you could bind different commands to those conditions.

[WarrenReynolds]

When you are referring to a trigger, is that like how a joystick button is a "trigger" and this trigger could be bound to something. Like https://docs.wpilib.org/en/stable/docs/software/commandbased/binding-commands-to-triggers.html#arbitrary-triggers

[mjansen4857]

Yes