Drake: System 2.0 PID Controller Needs to Support a Vector of Gains

[liangfok]

System 2.0's PID controller currently assumes the same gain can be applied to every control signal. This will not work when the control signals are applied to very different systems like the steering angle and throttle speed of a car that require different gains.

Addressing this issue will require generalizing gain.h, and pid_controller.h, among others.

[sherm1]

@liangfok, you can have as many PID controllers as you want in a Diagram and each has its own gains. Why isn't that a good enough solution?

[liangfok]

Having multiple PID systems will require that I have mux / demux systems to "break apart" and "re-combine" signals that would otherwise be a single vector (I think). For example, suppose I have three actuators in a RigidBodyTree:

1. front left wheel
2. front right wheel
3. steering

The states of these are represented by a single vector in RigidBodyPlant. I will need to separate these signals and feed them into separate PID controllers to assign them different gains. I figured it would be cleaner to support a vector of gains within a PID controller.

[sherm1]

It would be great to see these parameters delivered on input or parameter ports like Simulink's PID controller. I'm not as excited about feeding these into the constructor.

[david-german-tri]

Feeding them into the constructor seems like a fine interim solution to me. Parameters are coming relatively soon, but I wouldn't want to block this on them.

[liangfok]

I plan to work on this issue after #3742 is merged.

[liangfok]

Note that once #3619 is resolved, the gains can be extracted out of drake::systems::PidController and applied using a specialized AffineSystem system thus resolving this issue.

[liangfok]

Thinking about this some more, System 2.0's PID controller can be greatly simplified by keeping the gains (as vectors per this issue) within it and making it a System instead of a Diagram. The equations are simple enough that they can be directly implemented within a single system. Note that System 1.0's PID controller is a single system and uses vectors for gains.

[RussTedrake]

sounds like a good idea to me.

[amcastro-tri]

I agree with you @liangfok. The reason I originally implemented the PID controller this way was during the sprint to test we could build complicated Diagram systems composed of Diagram's (the concept of Diagram being a tree of Diagram's). This PID controller was the simplest useful system example I came up with. That then led me to write the more complex controlled Kuka using @naveenoid's gravity commentator and your own bot visualizer.