Auto set point not being reached

[arastogi11]

@arnavthak @Cheekibreekiski @jmeisten

Worth checking the units being used for feedForward for swerve

https://www.chiefdelphi.com/t/swerve-bot-trajectory-following-possible-unit-conversion-issue/423731

We are obviously undershooting but this could be a potential thing to check

Also btw the code did get pushed tonight to a new swerve branch which is totally fine.

[arastogi11]

I don't see feed Forward values getting used anywhere but I'm wondering if the other values we did get from sysid were just in a different unit than what this code is currently set up for

[MollyConnolly]

Did you need to tune the auto constants still? https://github.com/BobcatRobotics/2023-ChargedUp-177/blob/77fe3bd89f6529a50b6e51bc9c91067e1f39e9e3/src/main/java/frc/robot/Constants.java#L133

[arastogi11]

Did you need to tune the auto constants still?

https://github.com/BobcatRobotics/2023-ChargedUp-177/blob/77fe3bd89f6529a50b6e51bc9c91067e1f39e9e3/src/main/java/frc/robot/Constants.java#L133

Think Molly is correct here. Looks like these values match the base 364 repo which was for L2 gearing while our modules are L3 gearing. We'll want to tune these Saturday!

[arnavthak]

That is something we still need to tune, but I'm not sure that would be that much of an impact. Unfortunately, we need more surface and a better surface than carpet to get the real values for those. If someone knows the theoretical values, that's good too!

[arastogi11]

That is something we still need to tune, but I'm not sure that would be that much of an impact. Unfortunately, we need more surface and a better surface than carpet to get the real values for those. If someone knows the theoretical values, that's good too!

Easy enough to test to see if it makes an impact. Just change manually a bit at a time and see if results change. I can't find another teams code who is using L3 but I'll ask around.

Personally I do think tuning this as well as the max velocity would have an effect while we're testing.

I also think it could be valuable to rerun sysid to see if additional bumper weight may have thrown things off a bit. It's a light robot currently so weight of bumpers could potentially have thrown off your constants?

These are pretty easy things to try.

[Cheekibreekiski]

Did we end up re-testing with the bumpers? It was consistently getting ~160 cm (0.82 Jakes) without them, did we see any significant difference when we added them?

also @MollyConnolly the code got pushed to the old swerve branch

[arastogi11]

Did we end up re-testing with the bumpers? It was consistently getting ~160 cm (0.82 Jakes) without them, did we see any significant difference when we added them?

also @MollyConnolly the code got pushed to the old swerve branch

Sorry I was under the assumption the 1.6 was with bumpers on. Hoped that was part of the issue.

[arnavthak]

Just 1.6 without bumpers, yeah

[arastogi11]

Since our encoders are reporting the same distance traveled as actual travel, we should tune the gains.

A simple test for this could be marking 2 meters using tape on carpet. 0 the encoders, drive in teleop to the other tape, and see what distance is returned to the dashboard. If that's reporting 2 meters I'd wager auto gains need tuning.

[Cheekibreekiski]

Would it be worthwhile to make a simple auto using coords to see if the issue is with pathweaver?

[arastogi11]

Would it be worthwhile to make a simple auto using coords to see if the issue is with pathweaver?

My gut feeling is that it's unlikely a pathweaver coordinate issue unless you want to just double check.

I was chatting with Kyle from 176 describing our issue and he also recommended tuning the PID/feedForward since the encoders are also showing that we're short of the target.

[jmeisten]

Potentially stupid question, but did we ever monitor what the robot believes its pose is based on the swerve odometry? Yes the individual encoders are saying 153cm traveled but I wonder if the overall odometry think it is making the full 180. Just something to test. We should tune first

[arastogi11]

I don't think that's a stupid question at all. My assumption is gyro is also checked against. But I'd need to dig into code a bit tonight.

Does the gyro get used for autos at all or is it just based off encoders? If the gyro is used we never actually calibrated this gyro after mounting it. Could be something to look into in addition to tuning

[Cheekibreekiski]

@jmeisten I don't think we ever did that, all our measurements were based off of encoder vals

[Cheekibreekiski]

@arastogi11 briefly looking at the code, it does look like we use the gyro, the getPose method returns the odometry, which we update with the gyro

swerveOdometry.update(getYaw(), getModulePositions());  

EDIT: The getPose method is used by the swerve controller that we use in autos, I forgot to mention that

[arastogi11]

So I think we have a good set of things to check. These are not in priority order:

1) see what odometry returns 2) based on that maybe gyro needs calibration or better yet we pop in the pigeon 2.0

• calibration is really weird though and requires some downtime. It may not be worth calibrating the pigeon 1.0 now that we have our pigeon 2.0 ready to go which is supposed to be way better than the 1.0

3) check if we need to tune PID and feedForward 4) maybe recharacterize? 5) I did realize that you can also empirically get the wheelbase through sysid while I gave you wheelbase from a CAD model. Could be worth getting this from sysid - maybe CAD vs reality is off?

All these could also be working in tandem and causing stack up of error.

Did I miss anything to check?

[Cheekibreekiski]

I think you mentioned this before, but we might need to tune the max speed and max angular velocity too. I just added an odometry printout to SmartDashboard so that should be good to go

[Cheekibreekiski]

Actually looking at the code it seems like we have to tune all of our auto constants

public static final class AutoConstants { //TODO: The below constants are used in the example auto, and must be tuned to specific robot
        public static final double kMaxSpeedMetersPerSecond = 3;
        public static final double kMaxAccelerationMetersPerSecondSquared = 3;
        public static final double kMaxAngularSpeedRadiansPerSecond = Math.PI;
        public static final double kMaxAngularSpeedRadiansPerSecondSquared = Math.PI;

        public static final double kPXController = 1;
        public static final double kPYController = 1;
        public static final double kPThetaController = 1;

[arastogi11]

Actually looking at the code it seems like we have to tune all of our auto constants

public static final class AutoConstants { //TODO: The below constants are used in the example auto, and must be tuned to specific robot
        public static final double kMaxSpeedMetersPerSecond = 3;
        public static final double kMaxAccelerationMetersPerSecondSquared = 3;
        public static final double kMaxAngularSpeedRadiansPerSecond = Math.PI;
        public static final double kMaxAngularSpeedRadiansPerSecondSquared = Math.PI;

        public static final double kPXController = 1;
        public static final double kPYController = 1;
        public static final double kPThetaController = 1;

Correct! Molly pointed this out above

https://github.com/BobcatRobotics/2023-ChargedUp-177/issues/11#issuecomment-1397937384

These are still set to what the 364 base code was set to

[arnavthak]

Max speed is 5.5 m/s and Max angular velocity is the only other one they recommend tuning. Here's a source for the theoretical calculations: (https://www.chiefdelphi.com/t/how-to-calculate-the-max-free-speed-of-a-swerve/400741)

[arastogi11]

Marking this complete