# Swerve wheels turning 180 degrees when moving

So we’re using Ether’s derivation and when we go forward the wheels rotate before it gets to the the setpoint. We fixed the “second 180 problem” where we figure out the closest direction, but how do we tie the wheels together (so they turn the same direction)? We want them to turn the direction so it decreases the drift/rotation of the drivetrain. We also think that we could add a margin of error around when the edge cases where the wheel decides which way to turn to make the wheels by default turn the same way and get rid of the edge case. EDIT: we are trying it, but it seems to be messing up the code. Correct us if there’s a simpler solution for making the swerve modules correlate.

Our drivetrain (the way we organize our code is that we wrote method in the gyroSwerveDrive subsystem to control the swerve modules which are instances of the type SwerveModule which is a subsytem we created)

(gyroSwerveDrive)

(SwerveModule)

So, let me see if I have this right, you’ve figured out how to get the wheels to go to the closest direction so you’re never turning more than 180 degrees?

What do you mean by make the wheels turn the same direction to decrease the drift?

Eventually, once you have it all working, you can try to turn the modules a maximum of 90 degrees and reverse the drive motors but that comes after having everything else working. Is that what you’re asking now or something else?

Yes the wheels only turn 180 degrees (90 on each side)
If we try to translate before the wheels turn to the correct direction, the robot jolts to the side due to the wheels speeds still being active. Sometimes one or two wheels go ccw instead of cw or vice versa. So when we try to go left and right really fast, some of the wheels start to spin opposite while others don’t which causes the jolt in the first sentence.

When we did swerve, we never had the problem of the wheels finding a faster path by turning the opposite direction of each other. Maybe this is noticeable to you because the PID isn’t tuned perfectly. If you tune the PID better, the wheels should rotate to the same angle quicker also making them more likely to go the same direction when changing that angle.

Right now, you have it set up to where the wheels only have to rotate a maximum of 180 degrees. I’m kind of surprised that you’re having this issue in the first place because of that. This is noticeable to me when our wheels only turn 90 sometimes one will turn CCW while the others turn CW. This is why I’m guessing it’s a PID thing but I’m not too sure.

Do you mean for the wheels? Yeah, that could be possible (all of them are currently kP == 1 and nothing on kI or kD)

I’d definitely try increasing that until they start to overshoot. If you can tune that it makes the swerves a lot more effective.

We have our P at 12 and our I at 0.03. Note these values vary from system to system.

After a night of thought, we decided that tuning the PID should be a last resort type of thing since our robot is currently only the drive train, with engineering team putting on the other mechanisms later this week. We want to tune the PID when the weight will change smaller amounts since it’s kind of a pain. Is there a manual way to do that instead of tuning the PID like taking the movement direction of one wheel and setting the other wheel’s movement equal to it? (We did try to do this but we think we got the logic wrong).

If you wanted each wheel to point in the exact same direction, you could definitely get them to turn the same direction. When you rotate, the wheels should turn in different directions which might make one wheel get to its desired position than another wheel. If the swerve were slow to turn to their position, I could see this being a problem. But if they’re fast enough, I don’t think this would be a big problem.

I don’t think I fully understand you’re problem, if you could post a video of what’s wrong with the swerve modules and what they’re doing that you don’t want, I think I’d be able to help more.

This is mirrored on the other side of the drive train. We want all of them to turn CW or CCW, not both at the same time. (Note: this is at .5 multiplier on the joystick and barely touching the joystick so I think we have enough speed)

Here’s a video of it, see the slight turn at the end? We know that gyro correction probably fixes this, but we think that fixing the wheels turning different directions/angles would also help.

Yes, you are right about the speed, it seems to work just fine.

Can I ask what inputs you were giving it in each video? If you slow move the forward/strafe joystick around, they all turn to the correct direction, right? Then once you let go of that joystick they all turn towards the middle, right?

To me what it looks like is whenever you stop, the wheels turn to either 0 degrees or 180 degrees. Is that what’s happening or is it something else?

Funnily enough, when we decrease kP it seemed to converge towards the setpoint slightly better. Of course, we didn’t fix the angle problem. But I guess that’s okay.

That video was just left>straight>right. If we mode it slowly, they do go the same direction. Yes, they do all turn towards the middle.

Yes that’s happening, however that’s also always happening. We suppose that 0 vs 180 could change how the wheels turn.

Increasing kP just makes the driving less accurate. We’ll keep messing with kP but after that I suppose we’ll just work in gyro correction.

Are all the sensor phases set up correctly? It’s possible that one module has positive encoder increments as CW and the other has negative increments as CW, thus causing them to go in different directions. If both modules start off at the same position, they should turn the same way. We had this problem as well, except when we do change the sensor phase, the module starts turning forward and backwards rapidly, as if its overshooting and overshooting on the way back to correct itself, but I believe that one specific module needs different PID values. What is weird is that setting the sensor phase back the other way does not show this problem, and no other module has this issue.