PID controller class

[ethanmusser]

Feature request for a proportional-derivative (or perhaps proportional-integral-derivative) controller class.

Desired Behavior

Users can utilize the PD/PID controller class for applicable use-cases, or implement their own, more advanced controllers through child classes.

Minimal Proposed Implementation

• ControllerBase: An abstract class template that is templated for input type. Contains generic functions applicable to controllers, including:
  • ControllerBase - Default constructor.
  • Update - Pure virtual method that computes the controller output from the latest signal and set-point.
  • set_set_point
  • set_gains (maybe, might live in the child classes)
• PIDController: A child class to Controller that implements a discrete-time PID controller.

Desired Features

• ControllerBase:
  • Templated for various scalar types, Eigen vectors, std::vector, and std::array.
• PIDController:
  • Deadband and saturation
  • Custom error functions (e.g., e^2, sqrt(e)) via a function handle
  • Support for both:
    • passing in the error terms on update
    • computing these terms internally (e.g., derivative term based on previous proportional term and dt)

Later Features

• Support for defining a controller from a transfer function.
• ControllerBase child classes for more controllers, including:
  • BandBangController
  • ActiveDampingController

References

This code might be a good jumping-off point for the PID controller.

[chandravaran]

I was thinking these are the functions and variables that could be in abstract class

[ethanmusser]

I was thinking these are the functions and variables that could be in abstract class

Some thoughts:

• It's not really clear to me what the Start, Run, and Stop methods are intended to do here.
• Init only really makes sense as a factory constructor a la this.
• How do you intend to make the signature for the virtual set_gains function generic to any kind of controller gains (different controller implementations will have different types and numbers of gains).

[chandravaran]

So I was thinking there could be times when we want to shift from one controller scheme to another. So in that case we would require to start, run and stop. Which is why I kept these items. If I am not wrong if we were to template the function we would be able to send n number of parameters. Or we could send a vector and then do a check based on the number of parameters. Also we could use a 2-dimensional array that has the names as well.

[ethanmusser]

So I was thinking there could be times when we want to shift from one controller scheme to another. So in that case we would require to start, run and stop. Which is why I kept these items. If I am not wrong if we were to template the function we would be able to send n number of parameters. Or we could send a vector and then do a check based on the number of parameters. Also we could use a 2-dimensional array that has the names as well.

• There are certainly times that we want to implement a hybrid control scheme, but that is a different beast and outside the scope of this issue.
• You can template in this way, but keep in mind that we also want templating for the output type (e.g., for an Eigen vector data type we may want a vector or matrix of gains). This may be more complicated than you think, but take a crack at it if you like. Sending a std::vector alone could word, but might be more confusing since your gains are unlabelled. Not sure what you mean with the 2D array.
• I don't see mention of the Init vs. constructor comment.

In general, you should definitely start small with this and build up more complicated functionality as you go.

[chandravaran]

• Sorry missed the Init part, I was thinking that if we were to use different controllers then a separate init would be required. However, I don't if it is required honestly.
• When I mean by a 2D array, I mean one row will specify the name of the gain and the second row will contain the value. Something like a dictionary in python. Or even 2 1D std:vectors.
• So if I assume we don't require a hybrid control then Start, Stop, Run are not required correct?

[ethanmusser]

• Sorry missed the Init part, I was thinking that if we were to use different controllers then a separate init would be required. However, I don't if it is required honestly.
• When I mean by a 2D array, I mean one row will specify the name of the gain and the second row will contain the value. Something like a dictionary in python. Or even 2 1D std:vectors.
• So if I assume we don't require a hybrid control then Start, Stop, Run are not required correct?

• If you want to allow the user who is creating an ControllerBase child to implement their own initialization, you have the following options:
  • Encourage the user to write their own constructor for the child class, if desired. This is perhaps the simplest solution, but it would require that the user-defined constructor calls the ControllerBase base class constructor. I.e., the user would always need to write one of the following into their derived class (note C.52):

    class UserController : public ControllerBase {
     public:
      using ControllerBase::ControllerBase;  // This simply calls the child class constructor
      UserController() : ControllerBase(/* ... */) {}  // This calls the parent class constructor in the initialization
    }

  • The abstract class can be defined with a virtual Initialize method (as you described). In this case, the user would have to manually call the Initialize method in their code. Initialize cannot be called in the abstract class constructor as this may cause undefined behavior (this is very rightfully discouraged in this style guide section).
  • A virtual factory method could be included in ControllerBase to handle the virtual initialization behavior. This is the method recommended by the ISO C++ Core Guidlines (check out C.50).
• For specifying gains, you would need either a map of some sort or to use a dynamic allocation approach. Note:
  • If you want a Python dictionary-like behavior, look at std::map and std::unordered_map. These structures and internal algorithms are much better than the 2D array approach described here.
  • It is sufficient to mandate that users define their own gains mutator(s).
• The notion of transitioning between control schemes on the fly often (at least in our lab) requires knowledge of robot and environmental states, which this controller class will not have. So yes, I would remove methods intended for these transitions.

[chandravaran]

I have a question, when I am writing the update function. How would I make it generic to the inputs I can take into the function? Is it possible?