Feature request: example of saturated pi controller

[cmichelenstrofer]

Saturated PI controllers have been a popular request. We should either include one in pto or give an example.

[cmichelenstrofer]

Here's a noteboook that uses a saturated PI controller, using np.clip.

saturated_pi.ipynb.zip

The scales are not ideal yet... takes many iterations to converge and sometimes it needs to be run twice. But it shows how to create a saturated PI controller and that it works.

Interestingly, the optimal gains are not the same as for the PI (since the position and velocities are not the same!).

Using a max force of +/-1000N, this is a regular wave result:

and irregular:

The saturated PI controller is achieved as

f_max = 1000

def saturated_pi(pto, wec, x_wec, x_opt, waves=None, nsubsteps=1):
    force_td_tmp = wot.pto.controller_pi(pto, wec, x_wec, x_opt, waves, nsubsteps)
    force_td = np.clip(force_td_tmp, -1*f_max, f_max)
    return force_td

[cmichelenstrofer]

We should probably include this as either its own controller or a keyword on the existing PID controllers. @ryancoe @dtgaebe FYI

[ryancoe]

Nice work! If we can do it cleanly (and I think we can), I'd prefer to integrate it into the existing function(s).

Another thing that'd be interesting to look at with this is how well it works to initialize the solution with an unsaturated PI solution.

At a higher level, it'd be really great to have a tutorial where we illustrate a good workflow for device and control design (i.e., start with unstructured, work towards something you can implement in real-time). The Pioneer WEC might offer a good oppurtunity for this.

[cmichelenstrofer]

Regular wave results (more plots):

PI gains: [-4,407.5 N/(m/s); 8,884.1 N/m]
Saturated PI gains: [-7,336.0 N/(m/s); 3233.0 N/m]

Power PI: -295.9 W
Power saturated PI: -172.8 W

[cmichelenstrofer]

irregular:

PI gains: [-4,021.2 N/(m/s); 8,480.4 N/m]
Saturated PI gains: [-4,253.3 N/(m/s); 7582.1 N/m]

Power PI: -34.7 W
Power saturated PI: --33.6 W

[cmichelenstrofer]

@ryancoe @dtgaebe I added some more results above.

[cmichelenstrofer]

I'm working now on making the PI controller general for multiple PTO DOF.

[ryancoe]

Ok, you may want to talk with @dtgaebe about multi-dof feedback controllers if you're able

[ryancoe]

@cmichelenstrofer - Can you add a third curve to your regular wave comparison above: unstructured controller with a force constraint applied

[cmichelenstrofer]

@ryancoe The results are (nearly) identical to the saturated PI!! Maybe we shouldn't include a saturated PI force then...

[ryancoe]

Very cool! They'll only be the same for a regular (monochromatic) excitation like you have here, so I think that it is useful to add this functionality. However, this further emphasizes to me the need to have some good guidance on when/how to use these different controllers in the design process.

Which method is faster?

[cmichelenstrofer]

Ah right!

It is hard to tell which is faster. The unstructured + constraints converged in only 11 iterations, while the saturated PI took 76... but that might just be because of the scaling. Total time divided by number of iterations, the saturated pi controller is about twice as fast... but that doesn't account for any initial overhead.

[rebeccamccabe]

For a better initial guess, instead of using the unsaturated amplitude Fp, the fundamental of the saturated waveform will have an amplitude of alpha * Fmax / Fp, where alpha is a value ranging from 1 (no saturation) to 4/pi (full saturation, the fundamental of a square wave):

(from the Franklin-Powell-Emami Control textbook section on describing functions)

To go even further (unclear this is actually necessary) I've also derived the math for the higher harmonics too, which I think should be exact for a linear problem.

which is derived here https://github.com/symbiotic-engineering/MDOcean/blob/rgm-force-saturation/dev/describing_fcn_error.mlx

[rebeccamccabe]

other possible idea to help with convergence of the saturated controller - use a sigma approximation which alleviates the overshoots at the corners, and should mean you need fewer harmonics to stay within the constraint.

[cmichelenstrofer]

which is derived here https://github.com/symbiotic-engineering/MDOcean/blob/rgm-force-saturation/dev/describing_fcn_error.mlx

Really cool @rebeccamccabe! @ryancoe if we publish an example using a saturated PI, we should use this as initialization. @dtgaebe maybe this will help with the case you were running?

[cmichelenstrofer]

use a sigma approximation

This would be neat to try! Probably only needed in the PTO force, since that's the only one with discontinuities.

[cmichelenstrofer]

Ok, you may want to talk with @dtgaebe about multi-dof feedback controllers if you're able

@ryancoe, I talked to @dtgaebe; I will address off-diagonal multi-DOF feedback controllers in this same PR. We should also consider an example with the FOSWEC (with 2-DOF experimentally-derived impedance).

[cmichelenstrofer]

Regarding the sigma approximation: The way I'm doing the saturated PID I take the responses (positions, velocities, accelerations) which are not discontinuous, multiply by the respective gains, and sum. I then clip the force using np.clip. The harmonics of the force are not directly represented.

It could be used, however, for the unstructured controller with constraints. Or for the state (position) when there are state constraints. I suggest we provide a different tmat that does the sigma approximation in addition to the one we have that does the pure Fourier sum. If we want to do this we should start a new issue.