Swerve Module Questions

Technical Java
1

Hi there! Our team switched to a custom swerve drive setup this year, and it is working for the most part, but we’re having some issues that I haven’t seen other threads about, and I was wondering if anyone would be able to give some insight.

We are using team 364’s swerve template (GitHub - Team364/BaseFalconSwerve) and are going to implement team 177’s swervemodule.java fix (2023-ChargedUp-177/SwerveModule.java at main · BobcatRobotics/2023-ChargedUp-177 · GitHub) to stop the modules from randomly angling after code redeploys. Here’s our code: 2023-ChargedUp-5914/2023Robot_Final at main · nstig22/2023-ChargedUp-5914 · GitHub

Our modules are a custom setup using two Falcons and Rev Through-Bore Encoders on 1:1 gearing from the steering axis. We have them set up in absolute mode through the duty cycle encoder class. We are using a navx2 for our gyro.

1. Modules have to be manually straightened before every boot

Even with the absolute magnetic encoders, the wheels maintain their positions relative to each other, rather than the position of the absolute encoders. If they are not straightened they will be misaligned. Not sure if this is normal for swerve drive, but I haven't seen other teams manually straightening wheels before matches.

2. Module alignment issues

We are able to drive through most of a match, but if we take a few good hits, the modules will become misaligned relative to each other. To fix this, we have to manually straighten them and restart. I'm not sure what the cause of this is, because our code is using PID control to account for error in the angles of the modules. Is this just a PID tuning issue or something wrong with the encoders?

3. Drive characterization issues

We've recharacterized our drive multiple times with the angle motors in brake mode and the modules clamped straight with pieces of flexcraft. However, the bot still spins when driven straight, indicating that the drive motors on one side are spinning faster than the other. I've made sure our SysId values are correct, but it still doesn't seem to help. It didn't look like it in the code, but is there some characterization that needs to be done for the angle motors?

4. Encoder noise

This isn't necessarily an issue, but the SmartDashboard values for the encoder positions read to 6 decimal places that are constantly bouncing around. Would reducing the encoder duty cycle help with this, and would that even be something worth doing?

5. Angle motor clicking

Because of the design of the modules, there is a small amount of slop in the gears the angle motors drive through. This leads to noise coming from the Falcons that keep trying to correct the position when the error is just the backlash in the gears. It doesn't happen with every movement, but will this burn out the Falcons eventually?

Any insight into these issues would be greatly appreciated. Thanks!

2

How did u wire/code the Rev through bore encoders? Are u sure ur using the absolute mode and not relative mode?

Edit: looking at ur code, ur using the dutycycle encoder and the absolute methods. Did u wire it properly to the Rio using the right adapter?

3

How are the encoders wired to the roboRIO? Are you using the Absolute Encoder connection or the incremental? The absolute connecection should stay the same between power cycles.

Is a belt or gear skipping?

4

This is a good question, especially given issue # 5. Can you share CAD files or pictures of the swerve modules?

5

Yep, we have them plugged into the DIO ports, and they all read correctly.

6

Ok, but ur saying that the modules are essentially just acting relatively to where they are at robot init?

7

Correct. They seem to lose their position even though we are resetting the falcon encoders to the absolute encoders.

8

They’re plugged into the DIO ports and seem to be reading correctly.

The modules only use gears and are pretty beefy. We’re pretty confident that they’re not skipping teeth.

9

IMG-5089
IMG-50891920×1440 187 KB

IMG-5086
IMG-50861920×1440 164 KB

IMG-5085
IMG-50851920×1440 307 KB

IMG-5084
IMG-50841920×1440 286 KB

10

Idk if this is part of the problem but I shouldn’t need to reset all the angle motors in the subsystem constructor, 2023-ChargedUp-5914/Swerve.java at main · nstig22/2023-ChargedUp-5914 · GitHub, as it’s done for each module on init. I don’t think it should cause ur issue but maybe try without.

11

Does the number change when you initialize or does it stay zero? It looks like you don’t do any configuration of the duty cycle encoder. I haven’t used it, but does it return degrees when calling get absolute encoder?

12

I’m pretty sure you’re correct, by default it returns a value of 0-1.

Multiplying by 360 before converting degrees to Rotation2d may be all that’s needed.

13

That’s true. It’s does default to 0-1 unless u change the scaling which u can do in ur get angle function or there is a built-in method to the duty cycle encoder as well

14

I’ll give this a try. This is how the constructor was setup was set up by 364 though.

Offsets are consistent between boots, and they do return a 0-1 value. Multiplying by 360 seems to work to return degrees.

That was an accidental change when switching swervemodule files. I’ve fixed it now and it’s working like normal again.

15

@benjiboy2539
@GoldMonster

16

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