# Swerve Programming joystick issues

Hi,
Our team is planning on using a swerve drive train this year. We currently have 1 module (steer motor and drive motor) set up as a prototype. We are using CANTalons and CTRE absolute magnetic encoders.

The problem I am encountering while programming is that the joystick position wraps from 360 to 0, causing the wheel to pivot the long way around. For example, if the joystick and the wheel are at 350 degrees and the joystick is moved to 10 degrees, the wheel would take the long way all around. Is there any way to fix this issue?

Thanks

For our swerve code, for every degree position we give the module, it calculates whether it is faster to go clockwise or counterclockwise, and goes the shorter way. However, we are using relative CTRE encoders. Here’s an example:

Let’s pretend that we are using a relative encoder where 100 ticks = 1 degree. If the wheel is at 10 degrees and wants to go to 350, it finds it faster to go counter-clockwise and chooses that path. The difference here would be -20 degrees. Then it takes the starting position in ticks, and subtracts the tick equivalent of 20 degrees, or 2000 ticks in this case. So, 1000 (starting position) - 2000 (calculated shorter distance) = -1000 (new position).

TL;DR do the math on which direction to turn is faster, and do that. This would probably be easier if you used relative encoder mode. Swerve gets more complex if you allow the drive to go to the angle of reverse and flip its output.

That may not have been the best explanation ever, so if you need me to explain this differently, just ask.

https://www.chiefdelphi.com/forums/showpost.php?p=1440383

It’s difficult without your code to give an exact solution, but something like this should work for determining the best direction to rotate (as discussed above):

(W)heel pos: 350
(J)oystick pos: 10

(W-J)%360 = 340 -> bigger than 180, don’t turn negative
(J-W)%360 = 20 -> smaller than or = to 180, turn positive!

1 Like

Could you please explain why you prefer that method rather than using IEEEremainder.

Mostly inexperience on my part, good point 