To x lock or not? That is the question

Do any of you all make your swerve wheels X-lock (all wheels go to 45) when coming to a stop? mentors think it should stay in the position they were in when the stick is released. the peogrammers think everyone (teams) makes it X-lock. What’s the best practice behavior?

1 Like

I can see the value of x-lock if you’re intentionally “planting” yourself, but for general cases, when you come to a stop, just leave the modules in their current position.


Typically, the advantage of going into an X-lock is to prevent your robot from being pushed around or otherwise sliding. Under flat-field, undefended gameplay, there is really no reason to go into an X-lock. I don’t have personal experience working with swerve, but I imagine that the X-lock has a tradeoff of slower start-up times, since all the wheel directions have to go back before moving. Not a lot of time, but if it happens each time you want to make a small adjustment, it’ll add up.

The main time you would want to use X-lock is when you want your robot to stay in one place under defense as you do something with a manipulator. However, in this game you’re protected while in the loading and scoring zones, this use case disappears. (You may still want to use it to prevent jostling from alliance partners.) In this game, I think that X-lock will be most useful once parked on the charging station, waiting for partners to climb.

All that said, you do not want every stop to automatically enter an X-lock. Better to have it as something which the drivers (or perhaps some autonomous subroutines) have to choose to engage.


Programmers say leaving the modules in their current position is not possible. what needs to happen to keep it in it’s previous state when the stick is released?

You just don’t move the modules when the stick is released… Programmers are wrong.


I agree with @ash4fun. However, if you decide to automatically do an X-lock, you cannot do it when the driver requests a speed of zero because the robot may still be coasting to a stop. If you do an X-lock while the robot is coasting, it will likely tip over. You’d have to first wait for the robot to come to a stop, and then move the wheels into an X. If you’re using a SlewRateLimiter, you might be able to get away with an X-lock when the calculated speed reaches zero, but it would still worry me.

Here is how we keep the wheels turned to their current position when the stick is released. When the requested translation and rotation are zero, get the current module angle and use it as the desired angle.

      if(desiredChassisSpeeds.vxMetersPerSecond == 0.0 && desiredChassisSpeeds.vyMetersPerSecond == 0.0
          && desiredChassisSpeeds.omegaRadiansPerSecond == 0.0) {
        var currentStates = getModuleStates();
        // Keep the wheels at their current angle when stopped, don't snap back to straight
        IntStream.range(0, currentStates.length).forEach(i -> desiredStates[i].angle = currentStates[i].angle);

Press X to doubt

(I’ll see myself out)


We saw a similar thing, please show them this reply.
The reason it is problematic is because WPILIB outputs angle 0 for 0 speed, you can get around that by checking if the input from the stick is 0 and if so just set the desired angle to the current angle from the encoders. If there is input just set the angles from the WPILIB calculation.

1 Like

Yea, this would have been a great idea last year, planting yourself and making it much harder to push you around during a shooting sequence (something we where working on).

1 Like

Important note, this behavior was changed this year. The kinematics now retain the state that they were last at by default. See allwpilib/ at main · wpilibsuite/allwpilib · GitHub

1 Like

As a result of the way we implement “attitude control” to compensate for rotational drift over long distances, our wheels go into a “diamond lock” when we stop. We considered modifying the software so this would not happen, but we ended up liking the way it helped our robot resist defense. The wheel response to a drive command is so quick that we haven’t felt a negative effect from stop to start. We’ve run like this multiple seasons and we don’t expect to change for 2023. Our testing shows diamond lock (or presumably x-lock) reduces sliding on the charge station dramatically.

We have had an X-lock command in our swerve code for many years. It was designed to make the robot hard to push around by an opposing robot while not using any real battery energy. The idea was that you could play some blocking defense and just sit there forcing the opposing alliance robot to spend a lot of time and energy to push you or go around you.

This mode is activated by the driver pushing a button on the game pad. It is not the “default” state when the robot is not moving.

It is rarely used. I think it was used once or twice during the 2018 season, but not at all in 2019, 2020 or 2022. I don’t think it will be all that effective this year as the field is so wide open that the opposing robot can easily just drive around a parked robot.

We use Neos in Braking mode so we leave the wheels angle alone and just use electronic braking to hold the position.

Our team has used “X mode” in the past, and it is fairly useful against pushing defense. It does not currently make as much of a difference as it did before brushless drive was commonplace, but I would still recommend giving drivers the option to use it. We simply have our driver press the X button on their controller to enable it, and then automatically disable it when they move the sticks to drive.

This is super important to consider. If you plan on X-Locking, it really should be automatic so the driver doesn’t have to “think” about it.
I think when to x-lock should be determined strategically by the team. There isn’t a time to always have it on or always have it off. You’ll (op) want to have a discussion with your team about what is right for your strategy and playstyle.

1 Like

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