Restructure `rotors`

[MarAlder]

Problem

rotors are currently only available under cpacs/vehicles/rotorcraft/model:

This has led to a common workaround: creating a rotorcraft/model solely to visualise rotors, even for aircraft. This is semantically incorrect and prevents rotors from being referenced in, for example, an aircraft/model for powertrain system architecture mapping.

Proposal

1. Move rotorBlades out of rotorcraft to the vehicles level.
2. Add rotors to aircraft/model.

with:

Backwards-compatibility

⚠️ In CPACS v3.5, a rotorElements node was introduced at vehicles level with the intent to fully decouple rotors and link them at vehicle model level. This proposal suggests reverting that direction, because this has led to:

• larger structural changes to the rotorcraft level.
• the need to link sub-uIDs of complex sub-information such as controlDevices for hinge kinematics.

I assume that not many stakeholders adopted to the rotorElements in v3.5.

Trade-offs

I see the following pro's and con's:

✅	Aligns rotors with wings, fuselages, etc. at both aircraft and rotorcraft level
✅	Minimal change for rotorcraft, only rotorBlades moves one level up
✅	No dummy generic system component required for use cases focused on geometry (e.g. modelling helicopter rotors)
⚠️	Not modelled as an explicit system component, systems engineers working on powertrain architectures may find this limiting. However, rotors can still be linked via uID in systemArchitectures.
⚠️	Requires repeated rotor definitions if the same rotor is reused in multiple places

[kgntci]

@MarAlder, I find this proposal quite expedient in favour of reducing the redundancy in the definitions.

On one hand, the rotors are the top end of the propulsion system to generate thrust, just like aeroplane engines. Therefore, it is more appropriate to create a rotor definition at the vehicle level that serves both rotorcaft and aircraft. Besides, an aircraft propeller can be very well modelled under the rotor definition.

On the other hand the redundand definition of the rotor geometry could be prevented in the aircraft / rotorcraft level, when multiple instances of a single rotor definition is needed (e.g. 6 propellers for electric aircraft or 12 rotors for lift+cruise eVTOL).

Speaking of instances, a baseline rotor instance definiton on the aircraft / rotorcraft level would be quite simple. Here's a brief example of two rotors attached to a wing:

<vehicles>
  <rotorBlades>
    <rotorBlade uID="prop_blade">
      <!-- wingType definition as usual -->
    </rotorBlade>
  </rotorBlades>
  <rotors>
    <rotor uID="propeller">
     <!-- rotorType definition without <parentUID> and <transformation> -->
    </rotor>
  <rotors>
  <aircraft>
    <model>
      <rotors>
      	<rotor uID="prop1" sense="ccw">
      		<name>Propeller 1</name>
      		<description>Inner rotor. Counter-clockwise rotation.</description>
      		<parentUID>wing</parentUID>
      		<rotorUID>propeller</rotorUID>
      		<transformation>
      			<translation>
      				<x>-0.5</x>
      				<y>1.</y>
      				<z>0.</z>
      			</translation>
      		</transformation>
      	</rotor>
      	<rotor uID="prop2" sense="cw">
      		<name>Propeller 2</name>
      		<description>Outer propller. Clockwise rotation.</description>
      		<parentUID>wing</parentUID>
      		<rotorUID>propeller</rotorUID>
      		<transformation>
      			<translation>
      				<x>-0.5</x>
      				<y>2.</y>
      				<z>0.</z>
      			</translation>
      		</transformation>
      	</rotor>
      </rotors>
    </model>
  <aircraft>
</vehicles>

In this case, prop1 and prop2 would the instances of a <rotor uID="propeller"> that is defined in the upper level. One attribute that should be considered is the rotational sense of the rotors. The attribute sense with enumeration string values ccw and cw would be quite helpful for this definition.

Although all propellers basically have the same geometry, the rotational sense would alter the geometry of the rotor blades by mirrorring them. Fortunately, this would not require additional definitions, as the mirroring can be handeled by the TiGL library, when the sense attribute is given.

[MarAlder]

I'm not fully against pre-defining rotors as well - as it aligns with engines.

We need to be aware that if we add sub-uIDs, we would then need a strategy to follow the hierarchy when referencing those, for example for controlDevices:

<vehicles>
    <rotorElements>
        <rotors>
            <rotor uID="predefinedRotor">
                <controlDevices>
                    <controlDevice uID="pitchControl">
                    ....

    <aircraft>
        <model uID="myAircraft">
            <rotors>
                <rotor uID="installedRotor1">
                    <rotorElementUID>predefinedRotor</rotorElementUID>
                    <transformation> .... </transformation>
                </rotor>
                <rotor uID="installedRotor2">
                    <rotorElementUID>predefinedRotor</rotorElementUID>
                    <transformation> .... </transformation>
                </rotor>
            ....
            <controlDeviceUID>pitchControl</controlDeviceUID> # of which rotor instance? ...

(see #856)

On the other hand, we need to find a solution for this for the engines anyway 🤷‍♂️ (already tagging @CLiersch for this problem)

I think a rotationalSense attribute makes a lot of sense. But I’m still a bit uneasy about the implicit assumption that the blades will be mirrored... It certainly makes sense, but what if that’s not what’s intended by the user (for example, for reverse thrust? What if the direction of rotation is needed as a control parameter? Would this also impact other control functions, like pitch angles etc.?... This would become a perfect source for errors). But I’ll think it over again and bring it up in the discussions.