Path Planner Issue: Path Mirroring

My team is attempting to mirror paths for paths built on the blue side of the field. In the PPswerve controller command, mirroring with alliance color is set to true. When we run our paths for blue they work completely fine, however, the problem exists when running the path on the red side. For testing we ran straight paths, going from x=2 to x=5. On blue, it followed the path like normal. On red, the path curved to either side while going forward depending on where the path was built. If the path was built below Y = 4m, the robot would curve to the right while going forward. If it was built above y = 4m, the robot would curve to the left while moving forward. If the path was built on y = 4, the robot would follow the straight, correct path for both red and blue. We also tested at the extremes, using y = 8, and this caused the robot to run full speed the direction it was curving towards, and it wasn’t consistent to the max velocity and accelerations we are setting for the paths. Has anyone else gotten path mirroring to work using path planner, and if so how? Or have you had the same issue? Any input would help.

Well Hello fellow alliance partner! Do you mind sharing ur code? From what ur saying, it seems like ur path should work!

Are you putting ur robot in an unknown state by switching colors after running autonomous?

1 Like

Here is the Drive subsystem where the PP swerve controller is and the auto we are running for the paths. (13.9 KB) (13.9 KB)

You need to reset your odometry with a transformed initial state. If you reset your odometry using path.getInitialHolonomicPose() it will be resetting the odometry for the blue side of the field. Use PathPlannerTrajectory.transformStateForAlliance to transform the initial state and get a holonomic pose from that: new Pose2d(state.pose.getTranslation(), state.holonomicRotation) to reset your odometry.

Edit: Also, from looking at your code it looks like you are resetting your odom with the poseMeters pose. This is for differential drivetrains, you’ll want to use a pose that uses the holonomic rotation like above.


We changed the code to use the use getInitialHolonomicPose() inside the PPSwerveControllerCommand and started experiencing a different, but still incorrect path for the red alliance side. The path still works as normal for the blue alliance, but on red it now translates to the right before moving forward. The distance it moves forward is the same as the blue path but the translation to the right shouldn’t happen. Here is the path we are running with videos of blue and red side paths and the updated code.

Here is the updated drivesystem and robotcontainer code as well. (65.0 KB) (13.9 KB)

On a side note, to help with troubleshooting. We can generate and successfully follow holonomic and complex paths on the red or blue side. However when we go to “flip” the blue path to red, is when the anomalous behavior occurs.

Also, please forgive the spaghetti code and our ignorance, this is our first year using swerve and Java.

Yes, your initial path state still needs to be transformed for the red alliance. The one you are resetting for is the blue alliance.

var transformedState = PathPlannerTrajectory.transformStateForAlliance(path.getInitialState(), DriverStation.getAlliance());
resetOdom(new Pose2d(transformedState.poseMeters.getTranslation(), transformedState.holonomicRotation));

The above is essentially pseudocode but you should be able to translate it to your code.


Hello :wave:
Here we have the same problem when executing the trajectory in the red alliance. It seems we were not aware of using PathPlannerTrajectory.transformStateForAlliance.
We followed the example on GitHub of PPSwerveControllerCommand where we did indeed use traj.getInitialHolonomicPose(), however, we believed that enabling useAllianceColor would also change the initial position of the robot.
It seems that this is not the case and it is necessary to change the state of the trajectory to obtain the mirror position in advance for resetOdometry.
I came across this thread looking for a solution and tomorrow we will test it to work perfectly.

1 Like

We have already tried what I mentioned before.
The robot performed well in both alliances :ok_hand: :+1:
Changing the initial state of the trajectory before using resetOdometry has resolved the issue.