Need of hinges in rotorcraft level

[kgntci]

I've recently realized that we have no generic hinge definition in cpacs for rotating individual components. A hinge component is for example needed to define the pivoting point of a tiltrotor.

I have an initial sketch down below for a possible model:

<rotorcraft>
...
  <hinges>
    <hinge uID='hinge1'>
     <parentUID>engine1</parentUID>
     <translation refType='absLocal'>
       <x>0.</x>
       <y>0.</y>
       <z>0.</z>
     </translation>
     <rotation refType='absLocal'>
       <x>0.</x>
       <y>0.</y>
       <z>0.</z>
     </rotation>
     <steps>
       <step>
        <!-- Tiltrotor pointing upwards, as in the original definition -->
        <controlParameter>0.</controlParameter>
        <hingeTranslation>
          <x>0.</x>
          <y>0.</y>
          <z>0.</z>
        </hingeTranslation>
        <hingeRotation>
          <x>0.</x>
          <y>0.</y>
          <z>0.</z>
        </hingeRotation>
       </step>
       <step>
        <!-- Tiltrotor pointing in flight direction -->
        <controlParameter>1.</controlParameter>
        <hingeTranslation>
          <x>0.</x>
          <y>0.</y>
          <z>0.</z>
        </hingeTranslation>
        <hingeRotation>
          <x>0.</x>
          <y>-90.</y>
          <z>0.</z>
        </hingeRotation>
       </step>
     </steps>
    </hinge>
  </hinges>
...
</rotorcraft>

The hinge can be attached to a parent component through parentUID (e.g. a rotor strut). The rotor would be attached to the hinge through parentUID.

The step component basically mimics the definions of the controlSurfaceStepType.

This definition can be tailored to tigl later on.

What are your thoughts?

[MarAlder]

Very interesting idea @kgntci. Should users be allowed to place hinge lines on any geometry (parent) object, or should they be provided in specific places within the CPACS hierarchy? CPACS extension is simple, so I am leaning towards the second option (also to keep consistency to current control surface implementation). 🤔 Also, there are moveable elements which have a similar structure like hinge lines, but slightly different parametrizations. For example: landing gears and systemArchitecture states (still trying to find a consistent naming, though).

[kgntci]

@MarAlder, I would prefer to allow the users to place hinges on any geometry components. There's a multiple of varieties how you can use hinges on rotorcraft. Here are a couple of examples:

• Tiltrotor: You can basically tilt the rotor hub only (see Archer Midnight) or the whole engine pod (see Bell-Boeing-V-22). In the former case, a <rotor> element would be rotated about a point located at the tip of an <enginePylon>, wheras in the latter case, and <enginePylon> elements would be rotated about the tip of an <wing> element.
• Tiltwing: The entire <wing> element would be rotated about a hinge located on a <fuselage> (see NASA Tiltwing).

There's surely other combinations, where you can attach models through hinges effectively, but since we have so many combinations of hinge connections, it would be more elegant to allow the user to define hinges as a rotorcraft level element.

The hinge can be defined freely in space or as child element of another component. The child elements can be easily positioned and rotated with respect to the hinge. The child components can be displaced in translational and rotational manner w.r.t. to the hinge position. With the <step> definitions, you basically define the upper and lower boundaries of these displacements.

I've looked into the existing models. In controlSurfacPathType, a sub-surface of a wing is rotated about an axis, which is defined by two points on the wing plane. I don't see a two point hinge axis definition in <hinge>, since you can take define <hingeRotation> about three axes.

The control parameters of the hinge can be integrated into the systemArchitecture states, as a control component.

[joergbrech]

I am not 100% certain I understand this yet, but I am worried, that this will complicate relative positionings drastically. We already have overlapping transformations of e.g. wings, sections and elements + positionings that are not independent of each other. Adding a generic hinge-line that allows rotating any component adds more ambiguity in relative positionings.

I have the feeling that this could be related to the coordinate systems discussion. Currently, transformations are implicitly understood relative to the parent coordinate system (e.g. the wing coordinate system). If we add explicit coordinate systems, or reference frames, we could define wings and rotors relative to a custom coordinate frame and rotate the objects simply by changing the rotation around one of the axes. This doesn't add a third dimension of placing things relative to each other, it just modifies one of the two we already have. The downside of this is added complexity as well and the lack of a physical interpretation (is this just a description of the geometry or the description of an actual physical hinge?)

The other option would be to allow hinge-lines to specific types only.

[kgntci]

@joergbrech, I fully understand your concern that adding more frame definitions would seem like increasing the level of complexity in the first hand. But it's about more than adding a reference frame.

Let's put it this way: In the example of a tiltrotor, tilting the rotor means, the rotor is deflected as a result of a control input about a pivot point, just like deflecting the ailerons and flaps of a wing. Therefore, the definition of upper and lower boundaries of the deflection are needed, otherwise you would have a free rotating frame joint. This is why, I've also added <steps> definition in my initial proposal. Controling a tilt deflection mainly features a <hingeRotation> but could also feature <hingeTranslation> in <x>, <y> and <z> directions (I've updated the initial definition in my first post accordingly).

So, when you design a vehicle, which changes it's configuration in flight by tilting their components, hinges are considered as constituent components of the vehicle already within the conceptual design stage. Therefore, one would know that the tilted components should be poisitioned relative to a parent component, about which that particular component is tilted, instead of positioning with absolute coordinates. This is where a possible <hinge> definition would close the gap.

All in all, the intention in the hinge definition is to provide a kinematic reference point with controllable deflection limits and not a geometry.

Furthermore, attaching sections, elements and positionings to hinges would not be a part of the definition. As you've suggested, we can narrow down the allowed types (i.e. rotors, fuselages, wings, engines, engine pylons) to parent or inherit hinge elements.

If you're thinking that such extension in cpacs would be risky, I would suggest to contain our first implementations within the rotorcraft definition, until a certain level of maturity has been reached.

[joergbrech]

I understand, that a purely geometric view is not ideal and a CPACS node with steps and limits makes more sense.

If you're thinking that such extension in cpacs would be risky, I would suggest to contain our first implementations within the rotorcraft definition, until a certain level of maturity has been reached.

No, here I see the danger of artificially limiting the functionality of CPACS, like the current state of rotors not being accessible in aircraft. I suppose I prefer to limit the implementation on a few allowed types like you say and test it out.

[kgntci]

I've updated the definition above for a tiltrotor case. controlParameter = 0. defines the initial position of the hinge, where the rotor is poiniting upwards and controlParameter = 1. defines the lower end, where the rotor is pointing in the flight direction.

A child rotor definition would look like the following

<rotors>
  <rotor uID='rotor1'>
    <parentUID>hinge1</parentUID>
    <translation refType='absLocal'>
      <x>0.</x>
      <y>0.</y>
      <z>1.</z>
    </translation>
  </rotor>
</rotors>

Here, the rotor1 is elevated by 1m above hinge1, so that the rotational movement in hinge would result in a circular motion of the rotor about it's pivot point with a radius of 1m.

I suppose I prefer to limit the implementation on a few allowed types like you say and test it out.

Yes, that would be a good start. I would suggest to take wings and fuselages to parent hinges. Child elements of hinges could be basiaclly every other element that has a fully defined 3D geometry, namely wings, fuselages, rotors, landingGears, engines, etc, as well as hinges themselves.

[MarAlder]

For a complete rotor rotation we could specify your example like below. step would be consistent to the trailing edge devices.

<somewhereInCPACS>
	<configurationDefinitions>
		<configurationDefinition uID="cruise_configuration">
			<name>Cruise configuration</name>
			<description>Combination of control elements for cruise configuration</description>
			<controlElements>
				<controlElement>
					<controlDeviceUID>rotor_tilt</controlDeviceUID>
					<controlParameter>1</controlParameter>
				</controlElement>
			</controlElements>
		</configurationDefinition>
	</configurationDefinitions>
	<rotors>
		<rotor uID="rotor1">
			<name>Rotor 1</name>
			<description>Rotor which can be tilted</description>
			<rotorHub>
				...
			</rotorHub>
			<controlDevices>
				<tilt uID="rotor_tilt">
					<innerHingePoint>
						...
					</innerHingePoint>
					<!-- outerHingePoint defaults to innerHingePoint -->
					<steps>
						<!-- Tiltrotor pointing upwards, as in the original definition -->
						<step>
							<controlParameter>0</controlParameter>
							<innerHingeTranslation>
								<x>0</x>
								<y>0</y>
								<z>0</z>
							</innerHingeTranslation>
							<!-- outerHingeTranslation defaults to innerHingeTranslation -->
							<hingeRotation>0</hingeRotation>
						</step>
						<!-- Tiltrotor pointing in flight direction -->
						<step>
							<controlParameter>1</controlParameter>
							<innerHingeTranslation>
								<x>0</x>
								<y>0</y>
								<z>0</z>
							</innerHingeTranslation>
							<!-- outerHingeTranslation defaults to innerHingeTranslation -->
							<hingeRotation>-90</hingeRotation>
						</step>
					</steps>
				</tilt>
			</controlDevices>
		</rotor>
	</rotors>
</somewhereInCPACS>

Just thinking, is it the complete rotor which should rotate, or the rotor hub, or both?

Naming convention for the definition of control states/devices/functions/specifications

See #856

[kgntci]

For a complete rotor rotation we could specify your example like below. step would be consistent to the trailing edge devices.

@MarAlder, the <configurationDefinition> seems just fine. A <controlDevices> element is would be serving the purpose well for controling the rotor elements, such as swashplate angles and rotational speed (I'm also working on some definitions for these). However, I wouldn't consider tilt as a rotor control parameter, for one, tilting the rotor hub only is not how the mechanism works, but rather your rotate a group of components.

Saying that, I've just realized a flaw in my initial definition above. There, I place the hinge1 as child element of engine1, which makes no sense. In conventional tiltrotors, the rotor is tilted along with a larger engine cowling. In this case, the kinematic relation would be wing --> hinge --> engine cowling --> rotor and a possible parenting definition in the CPACS definiton should look like following:

<rotorcraft>
...
  <wings>
    <wing uID='wing1'>
  <hinges>
    <hinge uID='hinge1'>
   <parentUID>wing1</parentUID>
     ...
  <engines>
     <engine uID='engine1'>
       <parentUID>hinge1</parentUID>
     ...
   <rotors>
     <rotor uID='rotor1'>
       <parentUID>engine1</parentUID>
     ...
</rotorcraft>

In this relation, the configuration at an arbitarily selected tilt control would look like this:

For the eVTOL use, the engine is a smaller e-motor, which also moves along horizontal and vertical direction to have clearance with it's strut and wing:

Placing a <tilt> definition in <rotor> limits this flexibility. Therefore, I still want to promote the opinion of separate <hinge> definitions as I proposed in my first post.

I see that you're also inheriting controlSurfacePathType for the <tilt> definition. This type basically represents a shaft, which the control surface is attached to. So, it has a single rotational axis. For the tiltrotor application, this seems to be sufficient at a first glance. Nevertheless, a 3-DOF hinge would still provide more flexibility to designers.

[MarAlder]

Nice examples - you're right, a hinge definition in the rotor node makes techically not much sense.

Nevertheless, I want to propose a slightly different approach, taking #856 and #831 into account.

I still think that when predefining hinges directly at aircraft or rotocraft level, the disadvantages outweigh the advantages. If defined at the appropriate location, why should we pre-define such elements? I see the following drawbacks on this:

• ✅ The predefined hinge elements could be reusable, if multiple components share the same hinge.
• ❌ However, the predefined hinge elements are probably not used often enough to justify the advantages of defining them in advance. In contrast, each hinge line physically occurs only once.
• ❌ Not every control device follows the classical hinge line deflection. If we introduce this concept, we would also have to model other degrees of freedom consistently using this approach (e.g., deflection path of a landing gear). If not, we would have two different approaches (local definition vs. referencing pre-defined hinges).
• ❌ As a consequence of the above point, we would not be able to define exactly which pre-defined definition (classic hinge-line deflection or deflection path of landing gear) can be applied for a particular component. The correct/possible references would have to be kept implicitly in the documentation, which is always prone to errors in practice.
• ❌ I consider a hinge to be a detail of a component, not a component in its own.
• ❌The concept of parentUID is established in CPACS for static placement relative to a parent coordinate system. This goes hand in hand with the transformation element. Typically, you want to align a rotor within the coordinate system of an engine or wing. The hinge definition according to the above example would therefore have to refer to those components in order to map this dependency.
• ❌With the recent CPACS extension for systems, we add more and more complexity in uID linking. Let's try to avoid where not necessary.

With regard to #856 I want a consistent approach for exisiting and future CPACS extensions. Also keeping #831 in mind I would therefore propose to add a controlDevices definition to relatively positioned components such as engine and wing. Then we would consistently have the triple combination of parentUID, transformation, and controlDevices.

The engine extension should cover your tilt-rotor example. In the above figures, the rotor is actually not tilted, but I would say the engine is. I must admit that we more and more question the semantic meaning of engine, but it would fit your example. The rotor can have engine as parent element, without tilt mechanism (note that since CPACS 3.5 there are also pre-definable rotorElements which can be positioned in pre-defined engines or genericSystems). If we adopt the system definition from aircraft, we can also position an electric motor and other system components in the engine via parentUID.

The wing extension would cover #831. A second wing, the actual wingtip, would have <parentUID>mainWing</parentUID>, a transformation and controlDevice.

In both cases, controlDevice could have a control function like tilt/ deflection/openForOtherNames, which would contain the same structure as in wing control surfaces to maintain consistency and simplify TiGL implementation. Components like landingGear would as well have the triple parentUID, transformation, and controlDevices. But here we see that defining controlDevices like hinge mechanisms directly in the corresponding component level, we can adjust the data structure to specific needs, such as steering or braking DoFs.

Example:

<cpacs>
	<vehicles>
		<engines>
			<engine uID="predefined_tiltableEngine">
				<name>...</name>
				<nacelle>...</nacelle>
			</engine>
		</engines>
		<rotorcraft>
			<configurationDefinitions>
				<configurationDefinition uID="cruise_configuration">
					<name>Cruise configuration</name>
					<description>Combination of control elements for cruise configuration</description>
					<controlElements>
						<controlElement>
							<controlDeviceUID>engine_tilt</controlDeviceUID>
							<controlParameter>1</controlParameter>
						</controlElement>
					</controlElements>
				</configurationDefinition>
			</configurationDefinitions>
			<rotors>
				<rotor uID="rotor1">
					<name>Rotor 1</name>
					<parentUID>tiltableEngine</parentUID>
					<transformation>...</transformation>
				</rotor>
			</rotors>
			<engines>
				<engine uID="tiltableEngine">
					<parentUID>wing</parentUID>
					<transformation>...</transformation>
					<controlDevices>
						<tilt uID="engine_tilt">
							<innerHingePoint>
								...
							</innerHingePoint>
							<!-- outerHingePoint defaults to innerHingePoint -->
							<steps>
								<!-- Tiltrotor pointing upwards, as in the original definition -->
								<step>
									<controlParameter>0</controlParameter>
									<innerHingeTranslation>
										<x>0</x>
										<y>0</y>
										<z>0</z>
									</innerHingeTranslation>
									<!-- outerHingeTranslation defaults to innerHingeTranslation -->
									<hingeRotation>0</hingeRotation>
								</step>
								<!-- Tiltrotor pointing in flight direction -->
								<step>
									<controlParameter>1</controlParameter>
									<innerHingeTranslation>
										<x>0</x>
										<y>0</y>
										<z>0</z>
									</innerHingeTranslation>
									<!-- outerHingeTranslation defaults to innerHingeTranslation -->
									<hingeRotation>-90</hingeRotation>
								</step>
							</steps>
						</tilt>
					</controlDevices>
				</engine>
			</engines>
		</rotorcraft>
	</vehicles>	
</cpacs>