Path Planner Mirroring Issue

[Ethen_from_1080]

My team is having an issue with flipping our paths from blue to red. Not sure how to flip them with the new library. Does anyone have an ideas? Our code is here: https://github.com/Isotope-Robotics/FRC-2024

Thanks,
-Ethen

[icemannie]

Pathplanner has a GeometryUtil class with flip methods

[jdaming]

The AutoBuilder you configured here will flip the path.

You said you are having problems but gave no details of what you are trying to do or what happened when you did it.

Don’t use the GeometryUtil classes unless you know you need them, it might be done for you.

[icemannie]

The start pose also needs flipped.

[jdaming]

Why do you think that? The reset pose supplier that you configure with AutoBuilder handles this for you so long as you have a starting pose set in your PathPlanner Auto.

[icemannie]

What if you build your own autos?

[NewtonCrosby]

You’re configuring the Autobuilder, why not build autos from Pathplanner and use the built-in functionality.

We’re a first year pathplanner team, but haven’t experienced any bugs yet in defining paths on the blue side of the field, and having them seamlessly flip to red.

Then, secondarily, if you’re going to build your own autos for some reason, then take a look at the code that the auto-builder runs and you’ll need to implement that same functionality.

[jdaming]

Sure you can build your own “autos” but I see no indication they are doing that and that is the exception not the norm so I would only give that advice when I know that is what they want to do.

We don’t have a full description of the problem so until we do nobody knows for sure what is meant. There are multiple PathPlanner Autos configured in their code so I think it makes sense that is the route they are going.

@Ethen_from_1080 why do you have follow path command? That seems to be doing the exact same thing without duplicating code as:

        // Load the path you want to follow using its name in the GUI
        PathPlannerPath path = PathPlannerPath.fromPathFile("Example Path");

        // Create a path following command using AutoBuilder. This will also trigger event markers.
        return AutoBuilder.followPathWithEvents(path);

[Ethen_from_1080]

I think we figured it out. I created that follow path command just to play with something and realized it does the same thing. This is our first year using this library and it seems more complicated than it really is. Our original issue was that we saw no change in paths for red or blue but I think that’s because we didn’t set an initial pose but I’ll check later today.

[billbo911]

Slightly off subject, but I thought I would ask you here anyway.
Our approach this year, first year using Pathplanner, is to create blue paths, and red paths. To do so, we would take out the commands to mirror automatically. Is that a legitimate approach?

[jdaming]

I know it seems you have settled on this approach, but why? I just want to make sure we can’t help you come to a much easier solution.

Assuming you are set on doing this I believe all you have to do is provide false to the supplier for shouldFlipPath.

[NewtonCrosby]

@billbo911

Slightly off subject, but I thought I would ask you here anyway.
Our approach this year, first year using Pathplanner, is to create blue paths, and red paths. To do so, we would take out the commands to mirror automatically. Is that a legitimate approach?

To quote myself above

We’re a first year pathplanner team, but haven’t experienced any bugs yet in defining paths on the blue side of the field, and having them seamlessly flip to red.

Is there actually a benefit to your software or drive team do defining separate paths from the blue or red side? The field has symmetry on the Y-axis, so flipping is a pretty reasonable solution as far as I’m concerned.

If the flipping works based on alliance, why wouldn’t you take advantage of it and do half the work, with half the potential for bugs, and halve the number of things that could go wrong? Did you try flipping and it didn’t work well?

[mjansen4857]

@NewtonCrosby

Is there actually a benefit to your software or drive team do defining separate paths from the blue or red side?

There can be if there are some pretty significant differences between the blue and red side of the field at competition. Still, it would be a huge pain to maintain 2 different versions of the same auto.

But, instead of doing this I would either:

• Use vision for anything that needs to be tolerant of different positions on either side of the field (i.e. game piece tracking or AprilTags to aim shots)
• Make use of the modular path system to only change the specific part of the auto that would need to be changed for the red alliance, then reuse all of the other parts just to reduce how much needs to be changed.

[jdaming]

@mjansen4857

differences between the blue and red side of the field at competition

I would bring this up to field staff during calibration, they have always been very receptive to any comments I have had and tried to get things as close as possible and definitely within spec. Now if you don’t catch it till after calibration then I understand.

[billbo911]

@jdaming

I know it seems you have settled on this approach, but why?

Oh, we’re not locked in just yet.
Our biggest concern is not really for autonomous, but for what happens once tele begins. Wouldn’t the robots orintation be backward.
Maybe we are just misunderstanding the situation and the code operation

This is our first year using both swerve and PP.