Control surface deflection sign convention #193
This is related to #192 but really is a topic that needs addressing on its own as it is something that we may want to change, although, if we do, will imply backwards changes to all models with symmetric control surfaces.
Control surfaces deflections are not well defined according to a sign convention, which may pose problems in the future for antisymmetric control surfaces (ailerons) and may suppose now a difference in the linear versus nonlinear implementation of the control surfaces. We either change behaviour or continue as is, knowing how it works (a bug becomes a feature if you leave it long enough).
Control surfaces are implemented in the aerogrid.py file as part of the grid assembly process.
The UVLM grid is assembled in "strips", where a strip is a chord wise section. These strips are concatenated in a span wise manner resulting in surfaces.
A strip is generated here:
The whole surface is generated here:
In the process of generating the strip, control surfaces are done first, in the local B frame by rotating the relevant chord wise section about
These strips are concatenated sequentially in increasing node order. However, any rotation on the strip to assemble the surface is performed AFTER the control surface is implemented. Therefore, the control surface is rotated about an axis different from the material frame.
Take, for example the following configuration, where the arrow indicates the local xb, which is aligned with the beam and positive in the increasing node number direction
The grid strips are generated sequentially for each element. Since the control surfaces are implemented always rotating about the local
which is NOT coincident with xb.
The current implementation is that, for symmetric control surfaces with a single control surface input (i.e. same
The advantage of this being that the sign convention is clearly defined, and that the same approach is retained in the linear solver.
Please comment :)
A bit of a longwinded explanation but I think that should be tackled as the code goes forward. Probably the easiest short term option is 1) (and I'll see what to do for the linear solver in relation to #192) but we may want to look towards option 2) for future releases.
The text was updated successfully, but these errors were encountered:
Brilliant explanation. A few thoughts after quick look to the code:
Yep, the thing is that control surfaces are applied currently before the definition of
Practically, most applications benefit from the symmetric CS behaviour as is, therefore maybe the best option is to add the extra input to tell the code whether the CS deflects anti-symmetrically.
Agree on 2). I had experience with symmetric modelling with non-diagonal stiffness matrices and it was tricky.
Also agree on 3). Although the control surface behaviour is not affected by it
- useful if free flying aircraft has to be trimmed and linearized due to issue #193