Wheels rotating into "spin" position when robot stops. Is this normal

Our swerve drives well but every time the robot is stopped, the wheels automatically move into the position they would would be for the robot to spin in place. They quickly go back into the proper position when we drive it, but it happens every time the robot is stopped. We don’t think it’s normal but can’t figure it out.
Neo motors and this is the code, I believe. https://github.com/allderdicerobotics/robot2023_noregistry

Thank you.

1 Like

I didn’t look at your code for “errors” for more than a few seconds - I assume the code is “correct.”

The wheels go to some position when you stop driving. If using the WPILib that used to be the zero orientation and my team changed that to be the last non-zero position. WPILib now includes that logic and we can’t control it if using their method. That doesn’t sound like your problem unless you coded your own method with a flaw. But that leads to the following:

Joysticks output a position even as you let go of them. The swerve modules are still tracking that as the sticks return to center. We had joysticks that returned to zero differently on the Y axis than the X axis and the wheels tracked that. Since you are troubled by the rotation possibly the rotation joystick is just a tiny bit off and the swerve modules track the joystick position even the imperfections. Try zeroing the sticks, try a different controller, etc.


If you have any code that’s constantly trying to hold a heading based on the gyro reading, then chances are your target heading and the actual heading are never actually identical, so there’s always a small command going to the swerve drive subsystem telling it to turn slightly. If this is the only command, your wheels will all go to the “spin” orientation, as you call it. There’s no harm in this.


Dangerous assumption :grinning:

Thanks. The swerve works, but the wheel alignment change causes a slight delay and seems to make our swerve less smooth.

Sometimes but half the problems posted have a solution NOT in the area the Poster thought. Nothing jumped at me out of the code as wrong, though.

This is easily tested if OP uses field orientation for telop. Flip the switch to not use field orientation and see if the problem goes away.

Partially to that point, my teams swerve modules are always on - solid green or red light (Talon colors) but too low of power to move.

I haven’t looked at your code, but I’ll venture a guess as to why this is happening. Do you control your throttle with a trigger on an controller, and your rotation with a thumbstick? If so, here’s what tends to happen: When you let go of the throttle, the controller will return a true zero value. When you let go of the thumbstick, the controller will return a value very close to zero, but not actually zero (depending on the controller). Basic kinematics will interpret this as “I’m not trying to translate, but I am trying to rotate, so turn the wheels into rotating position.” To solve for this, you need to specially handle this case by adding some code which says something along the lines of “If there is zero throttle, and very close to zero rotational input, then stop the motion of the motors which set the wheel angle.”

1 Like

Looking at your code, my description of the issue above is likely accurate. Here’s where you’re reading the joystick inputs:

// The left stick controls translation of the robot.
// Turning is controlled by the X axis of the right stick.
new RunCommand(
() →

I suspect you’re getting close-to-zero-but-not-zero inputs on these and that’s what is causing your issue. You just need to check for close-to-zero and tell the modules to stop if you are close to zero.

The solution we use for this is a small deadband on the joystick inputs. To stop jittering, and for safety reasons, it’s best to do this on any input that makes the robot move.
You could use the method applyDeadband from MathUtil class: MathUtil (WPILib API 2023.4.3)

This shouldn’t be causing it and is nitpicky but you should only ever create one controller object for each controller and never have created like you do in drive I would recommend making it in RobotContainer then passing the Trigger or the result of the Trigger down.

Oh you also don’t have any antiJitter code which prevents your swerve module from turning if the velocity is very low.
Similar to this except you dont have omegaRadPerSec since that is a 2nd order thing.