Does My Team Need to Use Open Loops?

Hello CD,

We used the Talon Srx + mag encoder in all of our systems last year and successfully implemented motion magic in our system to bring our structure to scoring locations.

However there was still an option in our joystick to just “open loop run” the mechanisms to a positive and negative direction and I was wondering if that is even necessary since our drivers barely used it.

We ran into some trouble integrating both the closed and open loop modes.
When we ran the intake arm open loop, when we stopped moving we needed to send some power to the arm to counterbalance it against gravity, however when we ended the motion command the setpoint sent to the controller was not current since the arm was still decelerating and the mechanism would jump backwards awkwardly to the set point.
I figured that if we just ran a closed loop that moved the arm in a positive or negative direction we wouldn’t have that problem. since the jumping didn’t happen when we ran the intake arm on a closed loop.

Even for our drivetrain which always seemed to me like a classic case of an open loop use (for most of the teleop period), our robots over the years always had troubles driving straight, now we are working on improving the mechanical side, but from a programming point of view I figured we can just convert joystick values to velocity and run a velocity control, it should feel a whole lot smoother.

My fear of close looping everything is that if we over relay on our sensors and one of them malfunction mid game that mechanism will be dead for the rest of the match. However last year we had no problems of that kind except for one game when a robot collision broke off our intake arm encoder.

I was wondering how other team approach this topic, since my thoughts right now is that if quality sensors are mounted correctly on your mechanisms I don’t see advantages of ever using an open loop control.

In general, closed loop control is:

  1. Harder to write software for
  2. Harder to test
  3. Has more points of failure
  4. Often, harder to make it feel “intuitive” to a driver

Due to this, my rule of thumb: If you can get by with open-loop, do it.

You’ve actually brought up an interesting case. There is an important fact here that gravity’s pull makes this a nonlinear system.

Regardless of whether you’re running open or closed loop, you’ll want to incorporate some level of control effort offset to account for this. I wrote a blog post a little while back about this exact topic - It’s a bit of a read, but if you’re willing, it’ll illustrate exactly what I’m referring to here.

In general , we try to keep things as open-loop as possible. Wherever closed loop happens, we almost always provide some form of open-loop “backup” or “manual” mode.

When transitioning from closed loop to open loop, keep in mind that the operator always observes the actual state of the system, not the desired state. They’ll release the “manual” button when they see the mechanism at the position they want it at. As soon as the transition happens, you must set your desired position to whatever the actual position is.

Another thing to keep in mind during design: No closed loop controller is a panacea for mechanical woes. My rule of thumb: if a student can’t control the mechanism to some reasonable degree with a thrifty throttle and observation, there’s no hope we’ll get software to do that job in a reasonable period of time.

1 Like

We learned that we had to do this the hard way in 2018, when we lost a Finals match at one of our district events due to an arm encoder failure.

In 2019, we built in an “emergency mode” into all of our subsystems that incorporate closed loop control. That way, when a sensor fails or disconnects, we can immediately enter “emergency mode” which disables all closed loop control on the robot.

Conveniently, we were able to use the same button as an auto-disable button in 2019 (although this won’t work in other games because the joystick inputs are discarded in the auto period in other games).

1 Like

A nearby team (2357) uses similar “failsafe mode” in their 2019 code.

  public void setFailsafeActive(boolean failsafeActive) {

    if (failsafeActive) {
      setDefaultCommand(new DriveProportional());
    } else {
      setDefaultCommand(new DriveWithEncoders());

Simple Answer: No

I think the concerns about having fail safe’s in case mechanisms break mid-match are valid, so look into that as improving your code, but that by no means makes it a necessity.


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