Hi,
I am currently attempting to implement a structural observer for FOWTs to include platform pitch, tower deflection, and blade deflections. I have derived my model using a Lagrangian approach by first defining position vectors for each element (tower, blade, etc) in the earth frame, differentiating, and computing the kinetic energies. I have written up my work in this Overleaf document for both fixed-bottom and floating turbines.
So far I have had good luck with the fixed-bottom observer, as shown in my results plots for tower-top displacement and blade displacement:
Note that I am employing a square-root cubature unscented Kalman filter (SRCUKF) for the estimation, hence the legend names.
For the floating case I use the same BEM routine, same derivation, etc, but the blade flapwise displacements are wildly invalid, see these comparisons:
My gut instinct is that this looks like a coding error rather than a modelling one; however, I have confirmed my BEM forcing vector against FAST, and even fed my model directly with FAST values but get the same result. Is this modelling approach reasonable? I appreciate any feedback.
Best,
Ian
Dear @Ian.Ammerman,
I’m not sure what to suggest, but I agree that there appears to be a bug in the derivation or implementation of your SRCUKF model. As with any debugging, I would suggest focusing on simplified cases where you can isolate various terms.
Best regards,
Dear @Jason.Jonkman ,
Thank you for your note. To clarify, the error is present both with the observer (SRCUKF) and without (just using RK4 time integration).
As for debugging steps, I am currently testing on a steady wind (no wave) case slightly above rated wind speed (I am using the 5MW OC4 model). To debug so far, I have compared the forcing values of my BEM code against FAST directly, which was also supported by the success for the fixed-bottom case. Without dumping all of my code here, the only difference between running the fixed-bottom and floating scripts is the M, C, K matrices. All that to say that from a debugging standpoint, all evidence seems to point to an issue with the derivation/equations of motion; however, the nature of the error (from my intuition at least) seems to point to a programming error, though I feel very confident at this point in the underlying code.
Interestingly, I did lock the pitch degree of freedom (fed 0 RHS force and forced the position & velocity states to stay 0). When I did that, the blade deflections were still wildly wrong, but the tower deflection was well matched to the fixed case.