[AustinSchuh]

Originally Posted by tStano

Okay! Thank you so much, guys. I really appreciate all the effort that clearly went into those posts, and I hope it can help many students to come. Definitely got me interested in a more softwarey path in school again.

NotInControl, your post really gives a good overview without me having to worry so much about the math I don't understand. That was super helpful, I much better understand what I'm doing now.
Austin, rereading your post after NotInControl's really gave me some awesome insight. It really gives a good overview of the involved complexity in designing a system. I'll look into some math, and I'm sure that will help my learning process with all this controls stuff.

So, a few more questions, which require an oversimplified explanation of my understanding:
1.You make a mathematical model of your system using all relevant states. It needs to be linear and time invariant or the math is even harder.

Yes.

Originally Posted by tStano

2. You use this to test your code which uses the variables you defined to achieve an output. You tune constants here. This is where I have questions. do you create some kind of testing code? Is hardware(sensors, even mock-ups of robot parts with similar moments?) involved?

I do all my testing purely in software. I have found that if tests aren't automated and easy to run, they won't get run. I'm incredibly lazy...

For my example above, lets design a controller and write a test for it. The plant is x(n + 1) = 2 x(n) + u(n), and we are trying to stabilize it to 0.

#include <gtest/gtest.h>
#include <gtest/gtest.h>

class Plant {
 public:
  Plant(double x0) : x_(x0) {}
  void Iterate(double u) {
    x_ = x_ * 2.0 + u;
  }
  double x() const { return x_; }

 private:
  double x_ = 0;
};

double Controller(double x) {
  return -x * 1.5;
}

TEST(Stabilize, StabilizeToZero) {
  Plant p(1);
  for (int i = 0; i < 100; ++i) {
    double u = Controller(p.x());
    p.Iterate(u);
  }
  EXPECT_NEAR(0, p.x(), 0.001);
}

int main(int argc, char **argv) {
  ::testing::InitGoogleTest(&argc, argv);
  return RUN_ALL_TESTS();
}

The Controller function (or class) is then used unmodified on the real robot. The only thing that you need to change is how you measure your sensor value to feed it to the function, and how you get the output to the real robot.

For a more complicated plant, you could imagine simulating other simple sensors. A hall effect sensor on our claw can be simulated as something that turns on when the claw is between 2 angles.

Tests are also great for testing that other simple functions do what you expect them to do. Wrote a nice function to constrain your goal? Write a test to make sure that it handles all the corner cases correctly. Once you write it once and automate it, it lives forever and will continue to verify that your code works as expected.

Originally Posted by tStano

3.Then you go to the real robot, and hopefully, its close enough to your model, and everything is peachy.

Yes.

As long as you don't crank up the gains in your simulation, the gain and phase margin of your loops should be large enough that it will be stable. The gain margin is the amount of gain error (robot responds with more or less torque than expected, for example) that you can tolerate before going unstable. The phase margin is the amount of delay error that you can tolerate before going unstable.

The initial tunings are normally not bad, but I'm a perfectionist. For an extra 1/2 hour of work, the tuning of the loops can be significantly improved over the initial tuning. I watch and listen to the physical response and look for overshoot, slow response, oscillation, etc and tune them out by adjusting the time constants. It also helps to record a step response and plot it. After having tuned enough loops over the years, you get a feeling for what speed poles work for FRC robots, which helps your initial guess. FSFB gives you knobs in both the observer to filter out noise, and the controller to control your response.