Swerve Open Loop vs Closed Loop

Would there be any difference in controlling a swerve drivebase in closed and open loop during teleoperated? I’ve looked at the codebases of a few teams and it seems like 364s BaseFalconSwerve uses open loop, while 2910 (which uses SDS lib) uses only closed loop control 2910 also uses open loop during teleop. I don’t see why there would be any difference, but maybe there is.

A few thoughts…

Open-loop is good from the perspective that it works just fine even if your ability to sense speed goes failed.

However, this would also eliminate your ability to do odometry, which might matter to your software just as much. IE, you’re “SOL” no matter what.

Depending on how aggressive your closed loop gains are, your open-loop behavior might feel a bit more intuitive to an operator (since it’s a simpler relationship between joystick position to motion). The operator’s brain is sorta running close loop anyway.

For our bot, we had enough rate limiting on joystick commands that running closed loop versus open loop didn’t make much of an intuitive difference to the operator, and so we did closed loop for a more consistent joystick-to-motion relationship.


We use open loop for teleop and closed for autos. This is because with open loop, the robot responds exactly to how the driver controls the robot, but during auto it’s basically impossible to get real consistency out of the drivetrain without closed loop.


However, this would also eliminate your ability to do odometry,

Why does an open loop make it so you can’t so odometry?

1 Like

It doesn’t.

FRC Odometry usually requires knowing wheel motion over time, same as closed loop.

My intended punchline is that if you’re relying on odometry for robot behavior, the open loop advantage of “doesn’t require sensors” is a moot point.

Is this because the open loop control will have a faster response time and therefor give the driver a better feel?

Kinda, yeah. The way I think about it is that the driver acts like the PID controller, rather than having one in the code. But yeah, it is more responsive with open loop.

1 Like

What level of open/closed loop are you talking about? Wheel velocity, robot velocity, robot position/heading, or something else?

We haven’t really noticed much of a difference between open and closed loop wheel velocity control.


Just wanted to clarify that this is not true. The drive motors in teleop are open loop. We have found it to be the most intuitive to have the driver control drive effort instead of velocity set point.

In auto we are also running each drive motor with simple voltage control and then closing the loop with overall robot odometery X, Y position. That being said typically when path following, feed forwards are getting us 95% of the way there.


Ah that’s my bad. I must’ve gotten confused when I was checking your code release.

1 Like

Open loop - using motor voltage or percentage output, this percent derived from desired velocity / max velocity

Closed loop - running PID on desired velocity with feedforward

This would be for a per module basis

1 Like

That’s what I thought— I don’t really see how this would affect teleop drive performance, because the driver is commanding a m/s velocity either way.

Our experience has been that the difference is unnoticeable in teleop, and I haven’t tried open-loop velocity in auto.

1 Like

I’m pretty sure you have to run closed loop in auto purely for the consistency that is required.

This what I would think too, but from a lot of the responses above seem to suggest that open loop would feel better. Our team hasn’t received our modules yet, so I’m just working purely out of simulation.

1 Like

If you’re using Falcons like most teams, the fact that there is no extra external wiring or signal paths for the sensors eliminate (or greatly reduce) the reliability issues that would be an issue with full time closed loop control. Since we at 230 like to have external gyro heading stabilization, we generally have a switch on the driver’s console to switch between gyro heading and raw heading (in case something breaks, or wires get pulled out, etc). We set up the scale factors such that the driver can’t really tell the difference (unless a defensive bot is disturbing heading).

In the past where we’ve used external encoders on tough boxes, etc, we’ve had enough signal failures to not do closed loop velocity under tele-op unless we had to.

We’ve done low pass filtering and acceleration limiting on our joystick inputs, no point in giving the driver bandwidth he/she cannot control. I think this helps with brownout issues as well. The point here being that even with closed loop control the robot has plenty of responsiveness, more than we need.

1 Like

Yes…and no. Physics is still very much in play. If the driver says “go fast” and then releases the stick to stop, with open loop the robot keeps going under its own momentum; with closed loop velocity control the control loop actively drives it to a stopped state. The driver could apply some reverse power to do something similar, but it’s not intuitive to do so.

The same applies in the other direction. If the joystick is moved to a position and held there, the closed-loop robot will accelerate as quickly as it can to hit that velocity and then stay there. The open-loop robot will apply whatever % output that position represents, and will eventually reach a steady state velocity (but will probably take longer to get there). As before, the driver could push the stick further up to get to the desired speed and then back off, but I would wager they are not going to do it as fast or accurately as the software can while adjusting output 50x/sec.

So in general I would describe open loop as feeling “sloppy” compared to closed. That may be more intuitive or have a “better feel” to some people; neither one is inherently the right way to do it, and control-input filtering can certainly have an effect. Still, I’m hard pressed to think of open-loop as “more responsive”.

The fear of losing a sensor for closed-loop was a bigger deal pre-brushless motors; we always had an open-loop override switch on the driver console (and used it a few times, too!). With brushless, you’re dependent on the internal encoders for the motor to work anyway, and it’s less of a concern. But we still have an open-loop override switch. Even if the drive team never needs it, the pit crew does - when you’re testing the robot up on blocks to make sure all is well with your drive, closed loop control that’s tuned for the mass of the robot can cause very strange behavior when it’s completely unloaded.


With brake mode on a motor wouldn’t they have a similar effect? Although, like you said, this would probably be sloppier than closed loop control.

I think ultimately this will have to be something that I’ll test out once I get my hands on some real swerve modules to see how both open and closed loop feel.


It depends what you mean by “more responsive.” A PID loop can definitely react faster to disturbances than a human driver.

It does take some effort to make a closed-loop drive respond in the way most drivers expect, though, while open-loop feels “natural.”


Yeah, that’s more of what I was going for. I’ve been thwarted yet again by writing chiefdelphi messages while I’m tired.

From our “testing”, we’ve found that our drivers prefer open loop during teleop, but perhaps with a more optimally tuned closed loop we could change that.


Probably similar, but of course only in the “decelerating” direction, which makes for a little bit of asymmetry in control response. It’s probably easy enough to get used to though.

Yep, ultimately it’s good to have options. The one that makes your drive team most effective is the right answer.


I’m learning PIDs now, and I’m using closed loop position? Just for basic auto, should I be using closed loop velocity for a certain time? I’m just trying to make it go in a straight line consistently and quickly