Issue using TSR tracking control mode

[ElioDaka]

Dear all,

I am using ROSCO to control a wind turbine model, that is similar to the IEA 15 MW. I have a strange behavior in using TSR tracking control (VS_ControlMode = 2). In particular, in the correspondence of the wind step, I have a large decrease of the generator torque, that goes almost to zero for like 20 seconds, than the torque signal goes to reasonable values. I don't have this problem when using k-w^2 control logic in below rated operations. I am not using the EKF wind estimator but just a filtered wind speed estimate.
Is this problem related to the controller or to the turbine model? Do you have any suggestion to solve it?
In the figure below i report generator speed and torque for the two cases.

Thank you
Elio

[dzalkind]

Hi Elio,

I generally recommend running VS_ControlMode = 2 with the wind speed estimator enabled (WE_Mode of 1). When you use the wind speed signal directly with a step input, the tip speed ratio will fall drastically at the step and the torque will drop similarly to track the desired tip speed ratio. The wind speed estimator provides enough of a time delay that these transients are usually avoided, and it's a more realistic control approach. Alternatively, you can decrease F_WECornerFreq to delay the wind speed estimate signal.

I hope this helps.

Best, Dan

[ElioDaka]

Hi Dan,

Thank you very much for your help. Decreasing the frequency of the filter things go much better, the undershoot is still present but is greatly reduced. What I notice is that the dynamic of the system is slower, I mean the rotor reaches a steady state velocity after the wind step in a longer time. I think this is due to the fact that my rotor has a very high inertia, or am I missing something else that can cause this behavior?
Thank you again

Best, Elio

[nikhar-abbas]

Hi Elio,

Yes, you are correct - a rotor with high inertia will increase speed more slowly than a rotor with slow inertia. As Dan mentioned, the generator torque may drop to help speed this up, but it can only do so much.

I'm going to move this to the discussions page because it doesn't seem to be an issue with the ROSCO code.

Nikhar

[ElioDaka]

Dear all,

thank you again for your help. I apologize for turning back again to this discussion. Reading the source code I noticed that the variable LocalVar%We_Vw_F is the variable LocalVar%WE_Vw filtered with a low pass filter having frequency CntrPar%F_WECornerFreq. But using WE_Mode = 0 the variable LocalVar%WE_Vw is already the wind speed filtered, so in this case we are filtering the wind speed signal that is used by the controllers two times, aren't we? I noticed this comparing the results coming from the same simulation carried out using ROSCO from the bladed style DLL and from Simulink. In the first figure I used the Simulink as it is and, despite using the same WECornerFreq I get different results. While in the second figure I implemented the "double filtering" in the simulink and the results are overlapped.

Thank you
Best, Elio

[nikhar-abbas]

Hi Elio,

This looks like a bit of an oversight on our part -- we don't use WE_Mode=0 often, so this is unsurprising.

In the ROSCO source code, the variable LocalVar%WE_Vw is the filtered nacelle vane signal when WE_Mode=0. It is important to filter this signal because it is inherently very noisy. As you have found, it would be good to also have this filter implemented in the Simulink model as the added phase delay from the filtering is important for smooth control action.

Would you mind submitting a pull request to the ROSCO/develop branch with the fixes that you are showing results from?

Thanks,
Nikhar

[ElioDaka]

Hi Nikhar,

Sorry for the late reply, I submitted the pull request with the fixes on the simulink model. Hope I did it in the right way. Let mw know if I did something wrong.
Thanks
Best, Elio

[icnosvbovwb]

Hello,every:

I used ROSCO to run the IEA-15-240-RWT-UMaineSemi example, and found that the Wind speed estimator has a slightly different trend.

[dzalkind]

This comparison looks okay. A better comparison for the wind speed estimate would be the rotor average wind speed, RtVAvgxh. In past versions of ROSCO, there was a drift in the mean wind speed, but I'm not seeing that so much here. Also, what is your x-axis?

[icnosvbovwb]

Dear @dzalkind
Thank you for taking the time to see my question. In the rosco2.6 version, I run two examples, and their root mean square is 1.1961-0.9627=0.2334, and 1.2362-1.5934=-0.3572, the data looks fine, but the graph in front of the second graph looks like something weird. The third picture is the picture of the paper, which looks very standard. I hope that the wind speed comparison graph of the two examples can be close to the third graph. Although it is not exactly the same, I want to pursue the same trend of the rotor average wind speed and wind speed evaluation.I'm not sure what needs to be modified? Can you help me?

[dzalkind]

The wind speed estimate relies on the Cp surface. To increase the wind speed estimate, the Cp surface needs to decrease. You could try regenerating a Cp surface with aeroelastic simulations. You could also hack it by reducing WE_RhoAir, but that will only provide a steady offset. What is your use case? What you're showing looks good enough for the controller to work.