Swerve Drive Odometry +Y is to the Right?

[sam.mulvey747]

Hi everyone, my team is trying to use Path Planner to follow routines with our swerve drive. Currently, we are running a routine as follows:

However, when we run the code, the robot will travel in the correct direction forward, but will be mirrored vertically, so it basically follows this path instead:

I checked that CCW was positive for our heading, and +X is positive for our odometry, but +Y is actually to the right instead of to the left. I don’t know if this would be 100% of the issue, but I’m sure it wouldn’t help. I have no idea though how we could invert this so the odometry is measuring the correct +Y direction. And if that’s not the only issue, we are still kind of stuck. Any help would be appreciated. Thanks

[bovlb]

My first guess would be that your turn motors and turn encoders both need to be inverted.

Are you emitting your dead-reckoning position to the SmartDashboard (e.g. using Field2d (WPILib API 2022.4.1))? If so, does it agree with where you want to go, or where you actually go?

What about with teleop control?

[democat]

Do your swerve drive kinematics have the top left module as positive in both x and y offset?

[sam.mulvey747]

Here is the order we call the modules in our subsystem, and the following image is how we set up the kinematics object in our constants file:

So you seem to be on to something, as the first one is ±. What do we have to make them for it to be correct?

[sam.mulvey747]

I’ve never heard of this before, and we are going to try it when in our lab tomorrow. As for teleop, that is where I discovered that our +X is forward and our +Y is to the right.

[jdao]

Your Translation2ds are incorrect for your given positions. Top-Left is + +, Top-Right is + -, Bottom-Left is - + and Bottom-Right is - -.

[sam.mulvey747]

Thanks for the help! Will try this out tomorrow. For my future reference, where would I find this information so I can understand why?

[jdao]

Think of the center of your robot is (0,0) in reference to the WPILib Coordinate System, with forward being positive X and left as positive Y. From here, each module is shifted by half the width/length of your drive base (typically). So if you draw your chassis onto a graph, each module will fall into one of the four quadrants of the graph, which will tell you what sign the X and Y should be.

[ArdaTurkmen]

We had the same issue this year, first, you should check your gyro about its direction and path planner. For us, we used navx which is positive in the clockwise direction but the path planner is negative in the clockwise direction. When resetting your position to the trajectory’s initial pose, you should put a negative sign. We did something like that:

  public void resetOdometry(Pose2d pose) {
m_gyro.reset();
m_gyro.setAngleAdjustment( (-1) * pose.getRotation().getDegrees());
m_odometry.resetPosition(pose, m_gryo.getRotation());
  }

If you can share the related part of your code, I can look in my free time and help you more:)

[Emerson1706]

Sam, as @bovlb said, you should check that your swerve module encoders read a positive angle (PI/2 radians) when trying to drive left, if they are reading positive to the right then that will cause exactly what you see here, the odometry will read that you’re moving to the left when you’re actually moving right.

You want everything on your robot to be in a right-hand-rule coordinate system with CCW rotation as positive as this is how everything is setup in WPILIB, also what may happen when you fix this is that your robot in teleop will drive the wrong direction, this is no reason to be worried, you can fix this where you read values from the controller by negating the joystick value.

[gcschmit]

Our team struggled a bit with the various coordinate systems last season. We created this document to capture the robot coordinate system, field coordinate system, PathPlanner coordinate system, Pigeon 2 behavior, and joystick directions. All of this information exists elsewhere, but we found it helpful to have it in one place.

[siddypot]

We had this issue, our fix was to make sure our kinematics were configured properly. We swapped 2 of the modules in the odometer.update() parameters.