## ROSCO Equivalent Wind Speed Estimator Struggling Due to Blade Deflection

This forum if for discussing controls. Questions about how to implement controls in FAST are more appropriate to the CAE Tools forum.

Moderator: Bonnie.Jonkman

Sam.Ramsahoye
Posts: 16
Joined: Mon Apr 27, 2020 1:06 pm
Organization: Arup
Location: United Kingdom

### ROSCO Equivalent Wind Speed Estimator Struggling Due to Blade Deflection

Hi,

I'm having some problems getting the extended Kalman filter (WE_Mode=2) to work reliably when I enable the blade degrees of freedom. I find that reliable estimates are obtained with rigid blades and that the divergence between reliable and unreliable esimates (obtained with flexible blades) is well correlated with a drift tip deflection around 20s. Please have a look at the plots below.

Perhaps it's due to a poor initialisation of the tip-deflection (initially set to 0 at t=0) on my part and the nature of the Kalman filter.

Any advice would be much appreciated.

Edit. I would have thought the equivalent mean speed would be 9 m/s as that is the mean wind speed during the simulation. The rotor diameter is approximately 200m.

Best,
Sam
Attachments
equivalent-windspeed-estimate-hh.png (34.19 KiB) Viewed 292 times
out-of-plane-tip-deflections.png (51.12 KiB) Viewed 301 times
equivalent-windspeed-estimate.png (21.83 KiB) Viewed 301 times

Sam.Ramsahoye
Posts: 16
Joined: Mon Apr 27, 2020 1:06 pm
Organization: Arup
Location: United Kingdom

### Re: ROSCO Equivalent Wind Speed Estimator Struggling Due to Blade Deflection

It was my openfast naivety which was the problem, nothing to do with the ROSCO_toolbox or the ROSCO controller. Updating the LinearRamp setting to true in ServoDyn and adding a corrector iteration in the driver stabilised things.

I noticed in the source code for the wind-speed estimator that there is a variable denoted ti, I guess turbulence intensity? Is it a fixed parameter or can it evolve throughout a simulation?

Sam
Last edited by Sam.Ramsahoye on Thu May 07, 2020 11:52 am, edited 1 time in total.

Nikhar.Abbas
Posts: 5
Joined: Wed Apr 29, 2020 7:11 pm
Organization: National Renewable Energy Lab
Location: Boulder, CO

### Re: ROSCO Equivalent Wind Speed Estimator Struggling Due to Blade Deflection

Hi Sam,
Just to clarify, was the instability due to the WSE, or elsewhere in the setup?

Nikhar

Sam.Ramsahoye
Posts: 16
Joined: Mon Apr 27, 2020 1:06 pm
Organization: Arup
Location: United Kingdom

### Re: ROSCO Equivalent Wind Speed Estimator Struggling Due to Blade Deflection

Hi Nikhar,

I edited my original reply for clarity. I added a question relating to turbulence intensity in the WSE.

Thanks,
Sam

Nikhar.Abbas
Posts: 5
Joined: Wed Apr 29, 2020 7:11 pm
Organization: National Renewable Energy Lab
Location: Boulder, CO

### Re: ROSCO Equivalent Wind Speed Estimator Struggling Due to Blade Deflection

Hi Sam,
Good to hear!

Yes, you are correct - ti corresponds to the turbulence intensity.

The way it is now, it is a hard coded value. It could certainly be made a time-dependent (or wind-dependent) value that evolves over time if wanted/needed. The selection of ti, as well as the other parameters/values that affect the Q matrix in the WSE can certainly be a bit touchy, however. Some recent work has been done to clean up and improve the WSE response and will be merged once it is more extensively tested.

Nikhar

Sam.Ramsahoye
Posts: 16
Joined: Mon Apr 27, 2020 1:06 pm
Organization: Arup
Location: United Kingdom

### Re: ROSCO Equivalent Wind Speed Estimator Struggling Due to Blade Deflection

Hi Nikhar,

Thanks for the assistance!

If I was to make ti a user input variable, do you think it would actually improve the quality of my results?

Also, will VS_ControlMode = 2 strictly try and enforce that the tip-speed ratio is constant up to rated speed, or rated-speed and beyond? From what I can see, the main difference between this approach and the implementation of the traditional region 2 approach is that the user is in effect setting the value of VS_Rgn2K(\lambda, \beta, R) which is fixed using optimal values of \lambda in VS_ControlMode = 1. However, with VS_ControlMode=2, above rated the generator torque appears to saturate at VS_MaxTq (LocalVar%GenTq = MIN(LocalVar%GenTq, CntrPar%VS_MaxTq)) and not LocalVar%GenTq = (CntrPar%VS_RtPwr/(CntrPar%VS_GenEff/100.0))/LocalVar%GenSpeedF (=constant Power), like using VS_ControlMode=1.

Sam

Nikhar.Abbas
Posts: 5
Joined: Wed Apr 29, 2020 7:11 pm
Organization: National Renewable Energy Lab
Location: Boulder, CO

### Re: ROSCO Equivalent Wind Speed Estimator Struggling Due to Blade Deflection

Hi Sam,

It certainly could improve results, but it is hard to say specifically. There is so much coupling going on between everything that it would certainly take some time spent modifying and tuning the specifics of the controller and WSE to find the best ways to improve performance. Modifying the Q(1,1) and L parameters also tend to a have somewhat large influence on the WSE performance - the values currently used were based on "standard" values that provide reasonable performance in a number of test cases for different turbine configurations.

As far as the TSR tracking logic itself, with VS_ControlMode=2, the torque controller will always try to enforce that the tip-speed ratio is constant. The torque PI controller itself takes a TSR-tracking generator speed reference based on the estimated wind speed. When the wind speeds are above rated, the torque will simply saturate at the rated torque value. This does differ from the constant-power in above rated logic seen in the legacy controller, and when VS_ControlMode=1. It would be good to have a constant power and constant torque regime in above rated for TSR tracking control, but we haven't had the need (or bandwidth) to implement this internally yet. That said, from my understanding, constant torque is generally standard for floating turbines, and the performance differences can be negligible as compared to constant power for fixed-bottom turbines.

As an additional note on this: the overall AEP differences of using VS_ControlMode=2 vs. VS_ControlMode=0/1 are minimal. Especially in the simulation case, the K*omega^2 law works very well to maximize power output. Implementation of a TSR tracking controller is mostly motivated by industry feedback suggesting that this would be a good feature to have implemented in a reference controller. You can feel free to implement the k*omega^2 law by changing VS_ControlMode=0/1 and ensuring that VS_Rgn2K is correct (it should be if you used the ROSCO toolbox to write DISCON.IN).

Finally, I have opened a pull request with my updates to the WSE parameters and some related values to improve performance and stability here: https://github.com/NREL/ROSCO/pull/10. No promises that they improve the performance for your turbine, but might be worth taking a look at.

Cheers,
Nikhar

Sam.Ramsahoye
Posts: 16
Joined: Mon Apr 27, 2020 1:06 pm
Organization: Arup
Location: United Kingdom

### Re: ROSCO Equivalent Wind Speed Estimator Struggling Due to Blade Deflection

Hi Nikhar,

Sounds good. I was thinking of running constant TSR under rated and constant power above, seems like that's an easy change to the source code I can make if it is worth while. My main motivation had been that power curves tend to be flat after rated conditions. But perhaps controllers based on constant torque/constant power don't vary too much as you suggested.

I'll use your pull request and see how it changes things.

Best,
Sam