Control Surface coordinate syststems

[MarAlder]

We should check the relative coordinate system to which the path definition, i.e. the translation and rotation of the control surfaces, refers.

CPACS documentation:

The deflection path of the control surface is defined within the hinge line coordinate system. This is defined as follows: The x-hinge coordinate equals the wing x-axis. The y-hinge coordinate equals the hinge line axis (see above; positive from inner to outer hinge point).

This definition leads to non-rectangular coordinate systems, which makes it very difficult to use in practice. VPH users, for example, report that the conversion between CPACS and Catia data sets is very complicated.

The implementation in TiGL, on the other hand, appears to refer to the global coordinate system, even if the component segment is specified as parentUID. The expected behavior would be that the flap extends at least in the wing coordinate system:

                            <componentSegment uID="wing1componentSegment">
                                <name>Wing 1 component segment</name>
                                <fromElementUID>wing1section1element1</fromElementUID>
                                <toElementUID>wing1section2element1</toElementUID>
                                <controlSurfaces>
                                    <trailingEdgeDevices>
                                        <trailingEdgeDevice uID="cs">
                                            <name>Control Surface</name>
                                            <parentUID>wing1componentSegment</parentUID>
                                            <outerShape>
                                                <innerBorder>
                                                    <etaLE>
                                                        <eta>0.2</eta>
                                                        <referenceUID>wing1componentSegment</referenceUID>
                                                    </etaLE>
                                                    <xsiLE>
                                                        <xsi>0.7</xsi>
                                                        <referenceUID>wing1componentSegment</referenceUID>
                                                    </xsiLE>
                                                </innerBorder>
                                                <outerBorder>
                                                    <etaLE>
                                                        <eta>0.8</eta>
                                                        <referenceUID>wing1componentSegment</referenceUID>
                                                    </etaLE>
                                                    <xsiLE>
                                                        <xsi>0.7</xsi>
                                                        <referenceUID>wing1componentSegment</referenceUID>
                                                    </xsiLE>
                                                </outerBorder>
                                            </outerShape>
                                            <path>
                                                <innerHingePoint>
                                                    <hingeRelHeight>0</hingeRelHeight>
                                                    <hingeXsi>0.7</hingeXsi>
                                                </innerHingePoint>
                                                <outerHingePoint>
                                                    <hingeRelHeight>0</hingeRelHeight>
                                                    <hingeXsi>0.7</hingeXsi>
                                                </outerHingePoint>
                                                <steps>
                                                    <step>
                                                        <controlParameter>0</controlParameter>
                                                        <innerHingeTranslation/>
                                                        <outerHingeTranslation>
                                                            <x>0</x>
                                                            <z>0</z>
                                                        </outerHingeTranslation>
                                                    </step>
                                                    <step>
                                                        <controlParameter>1</controlParameter>
                                                        <innerHingeTranslation>
                                                            <x>0.3</x>
                                                        </innerHingeTranslation>
                                                        <outerHingeTranslation>
                                                            <x>0.3</x>
                                                            <z>0</z>
                                                        </outerHingeTranslation>
                                                    </step>
                                                </steps>
                                            </path>
                                        </trailingEdgeDevice>
                                    </trailingEdgeDevices>
                                </controlSurfaces>
                            </componentSegment>

Download full example: basicWing.zip

We therefore propose that, consistent with the other CPACS elements, we only use rectangular coordinate systems, which are specified via the parentUID. This can therefore be either the wing/component segment coordinate system or that of another control surface. The documentation of the parentUID element therefore remains unchanged:

UID of the parent of the TED. The parent can either be the uID of the componentSegment of the wing, or the uID of another TED. In the second case this TED is placed within the other TED (double slotted flap). In this way n-slotted TEDs can be created.

This could require to add y to the outerHingeTranslation and finding a strategy to avoid distorted flaps. Such a change should therefore take place in close coordination with TiGL development (@joergbrech @AntonReiswich).

• Trailing edge docs
• Path docs

[joergbrech]

Somewhat related: DLR-SC/tigl#906. If we rethink the definition of the hinge line coordinate system, we might want to think about the symmetry attribute.

[MarAlder]

Yes, the consistent use of right-handed coordinate systems, whose dependency on each other results exclusively from the XML-hierarchy or the parentUID specifications, largely solves this problem (DLR-SC/tigl#906) and should simplify the implementation in TiGL, right?

Of course, we still have the problem that ailerons would deflect in opposite directions (or have a reversed path order), while flats, slats and spoilers deflect in the same direction. But again, this seams to be a problem of how we want to deal with the symmetry attribute (#609).

@CLiersch

[sdeinert]

I am not really sure if the direction of the deflection should be handled by the symmetry. The control surfaces themselves don't have a symmetry as far as I know and only reuse the symmetry setting of their parent wing. From my point of view the antimetric/opposite deflection should be an additional boolean attribute or element in the control surface definition which activates or deactivates the symmetric or antimetric deflection.

So in short, I think the symmetry flag of the wing should affect the geometry of the control surface while the deflection as a state of the aircraft (not permanently stored in CPACS but set during tool runtime) should only be affected by the information in which direction the tool should apply the deflection.

[MarAlder]

I agree, symmetry is pure evil. But perhaps we should focus on the problem without symmetry first?

[CLiersch]

I do agree with the proposal from @MarAlder regarding rectangular coordinate systems taken from the corresponding parent. In this case we would need a TiGL-method to retreive such a parent coordinate system to calculate the control surface (CS) deflections. Furthermore, I would also like to separate this issue from the symmetry aspects.

Regarding symmetry: From my understanding, a CS on a wing with symmetry attribute (to x-z-plane) means that the mirrored CS should also behave in a mirrored way: passing the defined and the mirrored CS the same control parameter should result again in a mirrored geometry. Regarding things like antimetric aileron deflections with one up and the other one down: I think, we do not need to cover this by addditional attributes. That is a task, the control distributor definition was made for.