2024 Field2d Shuffleboard Widget Robot Not Starting from Alliance

Hi all,

Recently, we have been working with auto paths using PathPlanner 2024, but the robot starts at the same origin in the Field2d widget on Shuffleboard (right at the bottom left of the field image) regardless of the alliance we choose it to be. Is it due to some conflict between the resetting of the robot’s initial pose while constructing auto paths?

Much appreciated,
Can

PathPlanner now always uses the blue alliance right side as the origin.
However once you start running your auto, your robot should “reset” it’s pose to the start of the associated path.

Our auto has the following 2 methods and we instantiate a SendableChooser that builds every auto routine we currently have in PathPlanner.

Wouldn’t PathPlanner automatically reset the Field image with respect to different starting alliances of the robot?

PathPlanner transforms the point to it’s red side equivalent if necessary, but the origin remains on the blue side, always. PathPlanner should call “setPose” to set the pose to the initial pose of the path when the path starts.

@mjansen4857 would know better than I do.

If your robot odom is not being reset when you run the auto then you probably don’t have a starting pose in the auto.

Also, your current setup would not react to the current alliance. It will always flip the path to the red side since your “should flip path” supplier is always returning true. You’d want to change this to return true only if the current alliance is red.

1 Like

We have a similar issue so I’d figured I’d chime in here.

We created a ShuffleBoard button that updates the robot pose to the first point of the path. We tried to disable the dynamic planning for initial path pose but had no luck. We are currently using the button to update our pose until we start using April Tag for localization. Is there a better method for doing this using some sort of Pathplanner configs?

Another issue we encountered with the Field Widget is that the coordinate frame seems to be off to the one being used in PathPlanner. When we set the robot to the first pose in the path it shows inside the drivers station on the widget. The path runs fine but the widget is off horizontality. I don’t know if this is an issue with the Widget Cords or the PathPlanner cords.

If you want to reset your pose you’ll want to use the starting pose in an auto mode, not the first point of the path. Since you can start following a path with any rotation/velocity paths themselves don’t have a real starting pose unless you set the “preview starting rotation”. But I’d still recommend using the starting pose from an auto over that.

Try using AdvantageScope over shuffleboard. The AdvantageScope field coordinates are correct.

Thank you for your response. I got the second part and fixed the configuration method to account for red&blue path flipping, however how can I reset the swerve odometry in autoInit perhaps to the starting position of the path?

Just run the PathPlannerAuto command and it will do it for you

public Command setInitPose(String pathName) {
        return Commands.runOnce(
                () -> {
                    PathPlannerPath path = PathPlannerPath.fromPathFile(pathName);
                    PathPoint firstPoint = path.getPoint(0);
                    Pose2d firstPose = new Pose2d(firstPoint.position, firstPoint.rotationTarget.getTarget());
                    this.resetPose(firstPose);
                }).ignoringDisable(true);
    }

So just to confirm you are suggesting that we reset to the first point in the auto not the path? So using PathPlannerAuto(autoName) instead? If this is the case how do we get the Pose from the Auto. I only see a way to do this through the PathPlannerPath type.

But how can I return different autos based on the selection of the user in the Sendable created by autoBuilder? We included only
private SendableChooser<Command> autoChooser = AutoBuilder.buildAutoChooser(); in our code and when we selected from Shuffleboard, the respective auto ran but it wasn’t called with PathPlannerAuto(). So how can I reset the odometry of the robot if following this method?

The auto resets odom for you, you don’t need to get it yourself. If you just want the pose for some reason there is a method to get it: Path Groups | PathPlanner Docs

You need to have a starting pose in the auto.
image

If it’s not working even with a starting pose in the auto then your “setPose” method is not resetting odometry.

1 Like

Thank you, I found that I checked that off, so will try that tomorrow!

I found the issue. The code that we were using as an example had the consumer for the resetPose to just seed Field Centric.

 private void configurePathPlanner() {
        AutoBuilder.configureHolonomic(
                () -> this.getState().Pose, // Supplier of current robot pose
                this::seedFieldRelative, // Consumer for seeding pose against auto
                this::getCurrentRobotChassisSpeeds,
                (speeds) -> this.setControl(autoRequest.withSpeeds(speeds)), // Consumer of ChassisSpeeds to drive the
                                                                             // robot
                new HolonomicPathFollowerConfig(new PIDConstants(10, 0, 0),
                        new PIDConstants(10, 0, 0),
                        5,
                        .228,
                        new ReplanningConfig(false, false),
                        0.004), // faster period than default

                () -> {
                    // Boolean supplier that controls when the path will be mirrored for the red
                    // alliance
                    // This will flip the path being followed to the red side of the field.
                    // THE ORIGIN WILL REMAIN ON THE BLUE SIDE

                    var alliance = DriverStation.getAlliance();
                    if (alliance.isPresent()) {
                        return alliance.get() == DriverStation.Alliance.Red;
                    }
                    return false;
                },
                this); // Subsystem for requirements

We will update that. Thanks for the help!

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.