Pulling YAGSL 2023 Into 2024

[MTappen]

Hello,

I am curious how other teams are pulling YAGSL into 2024. I got our robot (NEO, CANSparkMAX with Cancoders) running in the fall with the YAGSL vendordep.

The new 2024 branch isn’t working for us because it doesn’t use feedforward, so I would like to roll back to 2023 to unblock auto development. The vendordep won’t work with 2024. Is it possible to find out which GitHub commit it corresponds to? It is version “2023.2.9”, so I am going to try February 10th, 2023, but curious if it might be based on a newer commit.

Thanks!

[field]

We have a very similar config: NEO, CanSparkMAX, Cancoders MK4i.

We also had our (very new) base working fine on the 2023 codebase. It was using a “known good” configuration with updated conversion factor due to our MK4i ratio being different from the “known good” one.

Over the last few days we’ve updated firmware on everything as well as moved to the new WPILib code, and Thursday’s YAGSL beta. The code compiles and will run on the robot (that itself took some time and patience but it’s now working).

However we can’t drive the robot yet. The “desired” inputs look good, and it even appears to handle turning properly. But the “blue” arrows - the actual drive motor states - are not aligned properly and do not spin. We don’t know what to do to fix this. Here’s an example.

No power to wheels after upgrading to 2024

We don’t plan to revert for this - we’re going to get it working… but we do need help understanding what’s wrong.

[MTappen]

I got booted out of the lab before I could fully debug our robot, but here are two things you can check:

1. YAGSL 2023 had its own feedforward calculations. In 2024, FF is set to 0 explicitly, so you need to use the FF in the SparkMAX PID controller. Try setting F in the pidfproperties.json to something like 0.15 or 0.2.
2. Check the actual power being delivered by the motor controller. I added this to my drive command

    CANSparkMax motorController = (CANSparkMax) swerve.getSwerveDrive().getModules()[0].getDriveMotor().getMotor();
    SmartDashboard.putNumber("Motor 0 Set Speed", motorController.getAppliedOutput());

WIth this, I figured out that we are doing something wrong with the angles and that is triggering new logic that lowers power when the angle error gets large. To check that, look for this line in SwerveModule.java:

      double velocity = desiredState.speedMetersPerSecond * (cosineScalar);

I commented out the cosineScalar term and that got wheels spinning. I got booted from the lab before I could figure out why we are triggering that logic.

Hope that helps!