SlowGuess/NeurIPS_2023_OCR huggingface dataset:
-  $(U, V, W)$  is the velocity of the vehicle in the body frame along  $X$ ,  $Y$ , and  $Z$  axis respectively.
-  $(P, Q, R)$  is the rotation of the body, i.e., representing roll, pitch, and yaw respectively.
-  $\mathbf{q}$  is a four-dimensional vector connecting the world frame to body frame.
-  $(x, y, z)$  is the location in the world frame.
-  $\Omega_{i}$  is the rotation for the  $i$ th motor expressed as radian/sec.
-  $Q_{j}$  is the power drawn from  $j$ th battery.
The flight dynamics is governed by the following equation
$$
\frac {d \boldsymbol {x}}{d t} = f (\boldsymbol {x}, \boldsymbol {u}), \tag {2}
$$
where  $\pmb{x}$  is the current state of the vehicle and  $\pmb{u}$  is a vector representing control signals. Each component can be controlled independently by the corresponding control signal and we assume the control signals are within range of 0 and 1. The function  $f(\cdot)$  represents the computation of forces. The computation of various forces as described below.
Gravity. Let us consider the velocity at the world frame is  $v$  and the body frame is  $V$ , respectively. The translation matrix connective  $v$  to  $V$  is defined as  $R(\mathbf{q})$ . Thus,  $V = R(\mathbf{q})v$ . The gravitation force is applied on the center of mass of the vehicle and computed as
$$
F _ {g} = m g R (\boldsymbol {q}) \hat {z}, \tag {3}
$$
where  $\hat{z} = (0,0,1)$  is the unit vector pointing down in the world frame.
Drag. The drag force on the vehicle's body is computed based on the vehicle's flight through the air. We assume that the velocity is the vehicle's velocity in the air. Thus, the velocity is updated from the body frame to account for the motion of the air being in the world frame as  $U - R(\mathbf{q})v_{w}$ , where  $v_{w}$  is the wind velocity. Then the body drag is approximated as
$$
F _ {b} = - \frac {1}{2} \rho \left( \begin{array}{c} X _ {\text {b o d y}, u u} | U + 2 v _ {i} | (U + 2 U _ {i n}) \\ Y _ {\text {b o d y}, v v} | V + 2 V _ {i n} | (V + 2 V _ {i n}) \\ Z _ {\text {b o d y}, w w} | W + 2 W _ {i n} | (W + 2 W _ {i n}) \end{array} \right) \tag {4}
$$
where  $X_{body,uu}, Y_{body,vv}, Z_{body,ww}$  are the constants for each coordinate axis and for the vehicle we set it equal to a constant times the presented area of the vehicle's body along the coordinate axis.  $U_{in}, V_{in}, W_{in}$  are the wind velocity along  $X, Y,$  and  $Z$  directions, respectively. As for the asymmetrical vehicles, center of drag may not align with the center of mass, this generates a moment force given as  $M = (X_{cbody} - X_{cm}) \times F_b$ , where  $X_{cbody}$  is the center of body force and  $X_{cm}$  center of mass.
Propeller and motor modeling. We define the geometric center of a propeller in the body frame is  $X_{p}$  and the unit normal vector to the propeller shaft is  $n_p$ . The velocity of the air passing through the stationary propeller is estimated as
$$
V _ {p} = \left(V + \vec {\Omega} \times \left(X _ {p} - X _ {c m}\right)\right) \cdot n _ {p}. \tag {5}
$$
For propeller performance, we refer to pre-computed tables for each propeller providing performance data with respect to spin rate and advance ratio  $J$ . The spin rate is defined by the rotations per second and denoted by  $n = \Omega / 2\pi$ . The advanced ratio is computed as  $J = V_{p} / (nD)$ . where  $D$  is the diameter of the propeller. The thrust and power of the propeller are estimated as
$$
F _ {p} = C _ {T} (n, J) \rho n ^ {2} D ^ {4}, P = C _ {p} (n, J) \rho n ^ {3} D ^ {5}, \tag {6}
$$
where  $F_{p}$  and  $P$  are thrust and power.  $C_T()$  and  $C_p()$  are pre-computed performance values depending on  $n$  and  $J$ . The total force from the propeller is computed by summing over all propellers.
The torque from the motor is estimated as  $\tau_{motor} = K_T(I - I_0)$ , where  $I$  is the current,  $I_0$  is the idle current, and  $K_{T}$  is the torque constant. The relation between the current and voltage is given by
$$
V _ {\text {m o t o r}} = V _ {\text {b a t t e r y}} u _ {c} = \frac {\Omega}{K _ {V}} + I R _ {w} \tag {7}
$$
where  $V_{motor}$  is the voltage applied to the motor,  $V_{battery}$  is the battery voltage, and  $u_{c} = [0,1]$  is the control signal driving the motor.  $K_{V}$  is the RPM constant and  $R_{w}$  is the resistance.
Note that the flight dynamics simulation model is currently under construction, and there are some assumptions that would affect the flight characteristics and performance of a given design outside of this particular FDM. For example, the parametric connectors are currently made of 3d ABS plastic which accurately reflects the mass properties of such a material, but may not hold up to the structural loads experienced during flight, which are not currently modeled. Further development will continue to address these simulation gaps.
D Additional experiment details
For the baseline experiments listed in this paper, we randomly shuffle the entire dataset and then split the data into train, validation, and test splits of  $70\%$ ,  $10\%$ , and  $20\%$  respectively. For the regression tasks, we normalize the data using the mean and standard deviation of the data. Where necessary we remove anomalous data points. For the mass prediction, we remove designs with a mass greater than  $35\mathrm{Kg}$  from the data set. When we report the results in [1] for MSE, we use the unnormalized values.
D.1 LSTM architecture
The LSTM baseline model consists of a linear input layer followed by an LSTM layer (nn.LSTM in PyTorch) with an input size of 512, a hidden size of 512. The LSTM layer is then connected to a final linear layer, via a dropout layer with a value of 0.5, that takes in all the outputs of the LSTM layer and provides the one-dimensional prediction. During training we use the PyTorch in-built SGD optimizer with a learning rate of 0.05 and set the number of epochs to 4000, where we save the model with the best validation loss.
D.2 Transformer encoder architecture
The transformer encoder consists of a linear encoding layer followed by a positional encoding layer. The output of the positional encoding is then passed through a transformer encoding layer (nn . TransformerEncoder in PyTorch) with 8 layers and 2 heads. The final token from the transformer encoder is then passed through a linear layer that goes from the embedding dimension of 200 to a single output dimension. During training we use the PyTorch in-built SGD optimizer with a learning rate of 0.1 and set the number of epochs to 4000, where we save the model with the best validation loss.
D.3 Graph convolutional neural network
Apart from the aforementioned models on sequence data, we also consider a model that directly operates on the point cloud. We represent the point clouds as a set of 3D points and apply a graph convolutional network (GCN) [17, 32] to make predictions on them. We build the graphs with the points as nodes where nodes are represented by their 3D coordinate. Each node is connected to  $K$  nearest neighbors ( $K = 40$ ). Note that the GCN model captures the structural information from the point clouds and does not have access to the specification of the components. Our GCN has four convolutional layers followed by a fully connected layer. We train the GCN with Adam optimizer for 200 epochs.
E Automated data generation
As part of automating our data generation pipeline for AircraftVerse, we defined a design grammar. Building a grammar to define a CPS requires significant domain expertise and AircraftVerse was no exception. Our focus was to build a procedural generator of designs that produced topologically valid aircraft designs, i.e. designs that met the requirements needed to be evaluated by the scientific models. Appendix G shows an example of a valid design tree. Once we built a valid procedural generator (with expert-guided distributions over all choices), we added the following heuristics: limit designs to having a maximum of 12 wings; limit designs to having a maximum of 16 propellers; set the probability of a recursive structure to be 0.25, such that we do not get infinitely long recursive structures. We then generated half our dataset using our procedural generator. Thereafter, we trained a transformer-based classifier to identify designs from their sequences that were extremely unlikely to hover (similar to the benchmark outlined in Section D). The next stage of generation then used this classifier as a weak filter (calibrated according to a recall of  $90\%$ ) to increase the number of hovering vehicles in the dataset. Components of this process are highlighted in our previous technical report [6]. Overall this process is an accumulation of over two years of work in building the right domain knowledge and compute infrastructure to ensure that the data remains diverse, interesting, and useful.
F Aircraft grammar and components list
The full JSON schema for the aircraft designs in our design_tree.json files is available at https://github.com/SRI-CSL/AircraftVerse/blob/main-schema/uav_schema.json. As mentioned previously, the sequentialized designs in design_seq.json files are pre-order traversals of the design trees (they can be viewed as sequences of key-value pairs).
Below, we also include the list of allowed values for each property (or "key") in the trees/sequences. Note that the JSON schema does not specify the allowed values for the component selection properties like propType, motorType, etc, as the specific lists of components are subject to change, and not considered part of the design language itself. We list all the currently used values for those properties below.
Table 2: Key-value descriptions.
KEY	DESCRIPTION	VALUE OPTIONS
node_type	Main structural components of air-craft, like the central hub and con- nector arms.	‘AngledPropArm’, ‘AngledWingArm’, ‘BendSegment’, ‘BranchSegment_Asym’, ‘BranchWithTopSegment_Asym’, ‘ConnectedHub2_Sym_Wide’, ‘ConnectedHub3_2_1’, ‘ConnectedHub4_2_2’, ‘ConnectedHub4_Sym’, ‘ConnectedHub6_1_2_2_1’, ‘ConnectedHub6_2_2_2’, ‘ConnectedHub6_Sym’, ‘DoubleBendSegment’, ‘PropArm’, ‘SidewaysBendSegment’, ‘SidewaysBendWithTopSegment’, ‘WingArm’.
Continued on next page
Continued on next page
Table 2 - continued from previous page
KEY	DESCRIPTION	VALUE OPTIONS
armLength	A context specific arm length generally associated with node_types such as 'PropArm' and 'WingArm').	Float: [50, 500]
arm1Length	A more specific arm length associated with arms that include a bend.	Float: [50, 500]
arm2Length	A more specific arm length associated with arms that include a bend.	Float: [50, 200]
angle	A context specific angle that corresponds to angles in the vehicle construction.	Float: [-135, 360]
offset	A context specific offset value that can correspond to structural components such as the wing offset and the flange offset.	Float: [-200, 90]
x1_offset	Offset in the x-direction of Battery on the central plate.	Float: [0, 120]
z1_offset	Offset in the z-direction of Battery on the central plate.	Float: [0, 120]
tube_offset	The wing tube offset.	Float: [10, 90]
G Aircraft design summary
In the additional supplementary material, we include the complete representation of an individual design when accessed from AircraftVerse, where we print the:
- design_tree.json
- design_seq.json
- cadfile.stl
- pointCloud.npy
- output.json
trims.npy
As part of the notebook, we show how to access the design corpus and provide an example of printing the specification of a battery. Finally, we also include an enlarged plot of the trim states for readability, as Figure 2 was an illustration of a full design that by necessity limited the allocated space for it in the full paper.