Skip to content

Conversation

zachwaffle4
Copy link

ChassisAccelerations and the drivetrain acceleration types are added in both Java and C++. ChassisAccelerations is basically just ChassisSpeeds but for accelerations! DifferentialDriveWheelAccelerations, MecanumDriveWheelAccelerations, and SwerveModuleAccelerations are the acceleration equivalent of the drivetrain speeds types.

In Java, the Kinematics interface now has an additional generic parameter A which represents the accelerations, and toChassisAccelerations and toWheelAccelerations methods, which are implemented the same way as toChassisSpeeds and toWheelSpeeds.

Protobuf and struct classes were also added for all four classes in Java and C++.

…r accelerations) and make both classes interpolatable

Signed-off-by: Zach Harel <[email protected]>
…use it already had the protobuf) and fix toString format

Signed-off-by: Zach Harel <[email protected]>
Signed-off-by: Zach Harel <[email protected]>
…celerations, and SwerveModuleAccelerations with relevant protobufs/structs

Signed-off-by: Zach Harel <[email protected]>
…anumDriveWheelAccelerations, and SwerveModuleAccelerations with relevant protobufs/structs

Signed-off-by: Zach Harel <[email protected]>
Signed-off-by: Zach Harel <[email protected]>
…classes to include new third generic parameter

Signed-off-by: Zach Harel <[email protected]>
…them and also make gradle happy

Signed-off-by: Zach Harel <[email protected]>
@zachwaffle4 zachwaffle4 requested a review from a team as a code owner August 22, 2025 00:17
@github-actions github-actions bot added component: wpimath Math library 2027 2027 target labels Aug 22, 2025
Copy link
Contributor

@KangarooKoala KangarooKoala left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to include adding interpolate() to the wheel speeds classes (and wheel accelerations classes) in this PR? It's already pretty large and doesn't seem directly related.

@zachwaffle4
Copy link
Author

I included the interpolation here solely because it was also something I wanted to add and I didn't want to make another PR

…swerve (which includes angular velocity due to centripetal acceleration component)

Signed-off-by: Zach Harel <[email protected]>
…y in module acceleration calculations

Signed-off-by: Zach Harel <[email protected]>
@github-actions github-actions bot removed component: wpilibc WPILib C++ component: hal Hardware Abstraction Layer component: command-based WPILib Command Based Library component: glass Glass app and backend component: wpinet WPI networking library component: examples component: sysid SysId app component: wpiunits Java units library component: epilogue Annotation-based logging library component: wpical WPIcal labels Oct 11, 2025
@zachwaffle4 zachwaffle4 requested a review from calcmogul October 11, 2025 20:22
@zachwaffle4 zachwaffle4 requested a review from calcmogul October 11, 2025 21:10
calcmogul
calcmogul previously approved these changes Oct 11, 2025
Copy link
Contributor

@KangarooKoala KangarooKoala left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where's the derivation of the swerve drive kinematics math again?

Copy link
Contributor

@KangarooKoala KangarooKoala left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great work! The first PRs always take the longest (and this one is already a really large change)- Thanks for sticking with it!

double linearAcceleration = Math.hypot(x, y);

moduleAccelerations[i] =
new SwerveModuleAccelerations(linearAcceleration, new Rotation2d(x, y));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just remembered that this will print a warning if x and y are both (sufficiently close to) zero:

if (magnitude > 1e-6) {
m_cos = x / magnitude;
m_sin = y / magnitude;
} else {
m_cos = 1.0;
m_sin = 0.0;
MathSharedStore.reportError(
"x and y components of Rotation2d are zero\n", Thread.currentThread().getStackTrace());
}

(And yes, zero acceleration for a module is possible- For example, spinning in place around that module.)

In general, are polar coordinates really the best representation for a module's accelerations? From the SwerveDriveKinematics side, it seems like Cartesian would be easier since we wouldn't need to worry about edge cases with zero acceleration, but I don't know if polar makes more sense on the generation side. (I think that the inconsistency with SwerveModulePosition and SwerveModuleState would be fine because those are directly related to encoder measurements while the acceleration is not.)

Comment on lines +253 to +255
// We already know that our omega should be 2π from the previous test. Next, we need to
// determine
// the vx and vy of our chassis center. Because our COR is at a 45 degree angle from the center,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This isn't super important, but if we're going to end up making changes anyways, could you prevent this single awkward word? (One thing you could do is to briefly join the entire paragraph into one line and then format)

If this would be the only remaining change, it's probably fine to mark this as resolved and then someone can spin off another PR to fix this.

Comment on lines +432 to +439
// FL (12, 12): radius angle = 135°, tangential = 45°, centripetal = -135° → total angle =
// -144°
// FR (12, -12): radius angle = 45°, tangential = -45°, centripetal = -135° → total angle =
// 126°
// BL (-12, 12): radius angle = 135°, tangential = 45°, centripetal = 45° → total angle =
// -54°
// BR (-12, -12): radius angle = -45°, tangential = 45°, centripetal = 135° → total angle =
// 36°
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pity this didn't fit, it'd have been really nice if it did. If there's already changes to make that aren't just comment formatting, maybe try this?

Suggested change
// FL (12, 12): radius angle = 135°, tangential = 45°, centripetal = -135° → total angle =
// -144°
// FR (12, -12): radius angle = 45°, tangential = -45°, centripetal = -135° → total angle =
// 126°
// BL (-12, 12): radius angle = 135°, tangential = 45°, centripetal = 45° → total angle =
// -54°
// BR (-12, -12): radius angle = -45°, tangential = 45°, centripetal = 135° → total angle =
// 36°
// FL (12, 12): radius angle = 135°, tangential = 45°, centripetal = -135°
// → total angle = -144°
// FR (12, -12): radius angle = 45°, tangential = -45°, centripetal = -135°
// → total angle = 126°
// BL (-12, 12): radius angle = 135°, tangential = 45°, centripetal = 45°
// → total angle = -54°
// BR (-12, -12): radius angle = -45°, tangential = 45°, centripetal = 135°
// → total angle = 36°

Up to you how you want to format it, this is just a suggestion.

.toArray(Rotation2d[]::new);

assertAll(
() -> assertEquals(totalAccel, moduleAccelerations[0].acceleration, 0.1),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could the tolerances be changed from 0.1 to kEpsilon? I'm not sure why some of the other tests use 0.1 instead of kEpsilon, but it'd be good to specify a higher level of tolerance.

Comment on lines +345 to +350
// FL (12, 12): radius angle = 135°, tangential = 45°, centripetal =
// -135° → total angle = -144° FR (12, -12): radius angle = 45°, tangential =
// -45°, centripetal = -135° → total angle = 126° BL (-12, 12): radius angle
// = 135°, tangential = 45°, centripetal = 45° → total angle = -54° BR
// (-12, -12): radius angle = -45°, tangential = 45°, centripetal = 135° →
// total angle = 36°
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, not sure why the formatting got so messed up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

2027 2027 target component: wpimath Math library

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants