Preprint
Article

Development and Evaluation of an Enhanced Virtual-Reality Flight Simulation Tool for Airships

Altmetrics

Downloads

163

Views

53

Comments

0

A peer-reviewed article of this preprint also exists.

Submitted:

12 April 2023

Posted:

13 April 2023

You are already at the latest version

Alerts
Abstract
A real-time flight simulation tool is proposed using a Virtual Reality Head-Mounted Display (VR-HMD) for airships operating in beyond the line-of-sight (BLOS) conditions. Particularly, the VR-HMD is developed for stratospheric airships flying at low/high altitudes. The proposed flight simulation tool uses the corresponding aerodynamics characteristics of the airship, the buoyancy effect, mass balance, added mass, propulsion contributions and ground reactions in the FlightGear Fight Simulator (FGFS). The VR headset has been connected to the FGFS along with the radio controller containing the real-time orientation/state of each button that is also simulated to provide better situational awareness and a Head-Up Display (HUD) that has been developed to provide the required flight data. In this work, a system was developed to connect the FGFS and the VR-capable graphics engine, Unity, to a PC and a wireless VR-HMD in real-time with minimal lag between data transmission. A balance was found for FGFS to write to a CSV file at a period of 0.01s. For Unity, the file was read every frame which translates to around 0.0167s (60 Hz). A test procedure was also conducted with a similar rating technique based on the NASA TLX questionnaire that identifies the pilot’s spare mental capacity when completing an assigned task to assure the comfortability of the proposed VR-HMD. Accordingly, a comparison has been made for the aircraft control using the desktop simulator and the VR-HMD tool. Results, showed that the current iteration of the system is ideal to train pilots on using similar systems in a safe and immersive environment. Furthermore, such an advanced portable system may even increase the situational awareness of pilots and allow them to complete a sizeable portion of actual flight tests with the same data transmission procedures in simulation. The resulting VR-HMD flight simulator is also conceived to express the ground control station (GCS) concept and transmit flight information as well as the point of view (POV) visuals in real-time using the real environment broadcasted using an onboard camera.
Keywords: 
Subject: Engineering  -   Aerospace Engineering

1. Introduction

Maintaining stability and operating autonomously are the main challenges related to the prolonged deployment of airships, and in-depth studies of flight operations are an important step toward deploying stratospheric hybrid airships [1]. A lot has been done to enhance the design and development of airships including several research projects and some stratospheric airship technology demonstrations such as HiSentinel by Southwest Research Institute (SwRI) and Aerostar International Inc [2], Sceye Stratospheric Airship by Sceye Inc [3], Integrated Sensor is Structure (ISIS) by DARPA [4], High-Altitude Long-Endurance Demonstrator (HALE-D) by Lockheed Martin [5] and Thales Alenia Space Airship by Thales group [6].
With the help of modelling and simulation, development cost of an aerial vehicle may be lowered [7,8]. Moreover, development of a flight simulation structure for a remotely-piloted air vehicle using the same techniques and subsystems enables the validation and verification of concepts and systems, optimization of the design and additionally, the enhancement of flying techniques and performance [9]. Nowadays, several types of flight simulators are available for different purposes, ranging from desktop platforms to more sophisticated training simulators and advanced X-DOF cockpit simulators [10]. Traditional simulators integrate flight dynamics model and simulation subsystems with a hardware cockpit mock-up, an outside visual, and a motion simulation [11]. Sometimes, these complex tools due to high-demanding quality standards for both hardware and software may exceed the cost of the actual product. Therefore, it is important to find the optimum cost/benefit ratio to reach an acceptable level of realism while considering the final cost [12].
VR provides a promising substitute to traditional simulators [13]. VR technology provides the opportunity to replace the entire reality with virtual objects with no limitations to what it could be. The difference between VR technology and conventional screens is the 3-dimensional capability of VR against the 2-dimensional representation of traditional screens. While most research and commercial applications use it to put the pilot into a virtual cockpit, some use it to emulate a HUD with the Out-The-Window (OTW) laid behind the HUD visuals similar to the experiment introduced in this paper [14,15]. In any case, the following three “pillars” play major roles to ensure usability of the technology among all targeted users: immersion, presence, and interactivity. Immersion is defined as a psychological experience often governed by various technological limitations including Field of View (FOV), resolution, latency, and trackability . Presence refers to the state or experience of a user in the virtual environment that may or not related to the physical environment. And, interactivity is the degree to which the user can control the virtual environment using a medium. According to some studies, these three pillars together constitute to user satisfaction and comfort while using VR headsets [16,17].
However, there are several concerns that are specifically involved when dealing with VR technology to ensure the comfortability of users. Motion sickness or spatial disorientation are usually the first things that are discussed when talking about VR. This is because of the disconnect the user experiences between what they see and what they feel [18]. One way to lessen the chance of motion sickness is to provide a portable infrastructure with a masked simulated environment. The enhanced portable VR-HMD for flight simulation and evaluation is a great training tool for pilots [19,20]. VR-based flight simulators are small and more portable than a full-size cockpit mock-up simulator and are much less expensive. This also makes them the best choice for most operators who are looking to train pilots in remote locations and perform flight operations in remote locations. Utilizing the same digital telemetry radio system in real and simulated flights can provide more consistency between each phase of the design [21]. Another key aspect to consider when working with VR headsets is human perception and behavior when using the application. One of such factors is the FOV [22]. Figure 1 compares the FOV of human eyes with various VR and Mixed Reality (MR) headsets. As illustrated, human eyes have an average total FOV of about 180 ° x 120 ° , while the Oculus Quest only has a FOV of around 94 ° x 90 ° . In this work, an Oculus Quest 2 has been used to study the simulated flight environment.
Augmented reality (AR) is a display device that enhances the real-world environment using virtual content and shows them on a screen. Usage of AR and VR technologies for futuristic vehicles or cockpit design is prevailing widely. In 2014, Aero Glass developed an application that could populate a large volume of ADS-B and other avionic information in the Osterhout Design Group (ODG) R-7 smart glasses [23,24]. It generated the information with respect to the pilot’s head position and orientation in a 3D environment. In 2016, Epson Moverio BT-300 smart glasses were used as a Head-Mounted Display (HMD) to fly the DJI Phantom quadcopters [25]. In 2016, Japan Airlines (JAL) demonstrated the idea of using AR to train pilots with a realistic flight simulator [24,25]. In 2017, Bell Helicopters began exploring the idea of an Augmented Reality futuristic cockpit system for their FCX-001 concept helicopter [25]. In 2021, Bombardier Aviation developed a full-size AR-based Cockpit Display System (CDS) for next generation flight deck HMI design practices [25].
Figure 1. Field of View (FOV) comparison between different visual systems [26,27].
Figure 1. Field of View (FOV) comparison between different visual systems [26,27].
Preprints 70936 g001
The VR-HMD simulator allows the operator to speed up the plans to use the VR headset for the real flight and to provide an integrated product that aims to train pilots from flight simulation to real flights using the same data transmission techniques. Utilizing the same digital telemetry radio system in real and simulated flights can provide more consistency between each phase of the design. Furthermore, the new flight simulator equipped with VR can be provided for the customers for training and operational flying purposes with the same data transmission techniques in simulated environment. Moreover, VR setups are small and portable which make them the best choice for most operational cases where customers are interested to operate in remote locations, particularly for airship related missions. Using this new technology, the required time to train pilots will significantly drop compared to the existing technologies as the integrated VR-HMD system will be used from start to finish to train the pilots for actual flight. Consequently, the VR-HMD flight simulator will allow the operator to accomplish the goal of from simulated training to actual flight with a single united system. The proposed portable integrated VR-HMD flight simulator has the potential to open a new generation of technology which costs just a few thousand dollars compared to existing separate GCS and full-size cockpit mock-up simulators which are significantly costlier in comparison. Such an advanced system is important to complete missions in real-time from remote locations and lower pilot workload and increase situational awareness.

2. Methodology

In Section 2, the methodology used for the development of the VR-HMD flight simulator is presented. Accordingly, in the following in Section 2.1, the airship architecture is presented with the details of the geometry parameters. Next, in Section 2.2, the flight simulator architecture including the flight dynamics model and the sub-sections of the flight simulator are presented in detail. In Section 2.3, the VR simulation application developed for the purpose of this study is introduced. Finally, in Section 2.4, the test procedure for evaluation of the proposed tool is presented along with the REB questionnaire.

2.1. Airship architecture

Herein two models for the stratospheric airship design have been introduced. The first one is the high-altitude architecture with the mission to carry the desired payload to 70,000 ft and remains stationary for a long time (e.g, several months and even years). The precise sizing characteristics are not the purpose of this work. The stratospheric airship uses two electrical engines, both placed at ~30% of the airship length from nose as presented in Figure 2 and Figure 3. The engine location allows the airship to use the thrust vectoring to generate sufficient pitch and yaw moments. The hybrid architecture is designed to employ the communication system, solar panels, fuel cells, and batteries and stay stationary for a long time. The hull uses a circular cross-section multi-ellipsoid geometry, and the tail has a cross-shaped four fin empennage configuration (X-layout) with inflated fixed fins and the ruddervator configuration to provide stability in both longitudinal and lateral-directional directions.
The second model is a scaled-down version of the base architecture to carry the desired payload to 10,000 ft and corresponding to the low-altitude demonstrator to validate the control and navigation systems. The low-altitude demonstrator model is considered to validate the simulator model in low altitude scenarios using the actual flight test results and then scale up to the stratospheric model. The geometry of the second airship is presented in Figure 2 with different parameters in Table 1.

2.2. Flight simulator architecture

The desktop flight simulator has been developed for the hybrid airship where beyond the line-of-sight operations are of interest. The proposed flight simulator is developed as a modular platform using the FGFS such that it is scalable and low cost. FGFS is offering a free and open-source multi-platform capability with atmospheric and orbital flight characteristics. It has been widely used in aerospace research and industry. The Flight simulation uses a simulated atmosphere, power, equations of motion, aerodynamics, buoyant forces, gravity, mass, added mass and inertia as shown in Figure 4 to study the behavior of the airship in different flight conditions [28]. Hence, different types and scales of the airship model can be simply simulated to study the behavior of the base design at various altitudes and flight conditions. To set up the flight simulator architecture, the geometry of the airship described in Table 1 has been modelled in FGFS using the Flight Dynamics Model (FDM) provided by JSBSim [29]. Accordingly, the corresponding aerodynamics of the hybrid airship along with the buyout forces, added mass, mass balance, ground reactions, atmosphere and propulsion contributions have been considered in the development of the flight simulator. These details are all gathered in separate Extensible Markup Language (XML) configuration files to enable the modular platform for the flight simulator architecture.
The matrix form of the equations of motion for an aircraft can be shown using the following equations for the longitudinal and lateral-directional motions, respectively [30]:
s X u X T u X α g · cos θ 1 Z u s U 1 Z 1 Z α Z q + U 1 s + g sin θ 1 ( M u + M T u ) M α s + M α + M T α s 2 M q s u s δ e s α s δ e s θ s δ e s = X δ e Z δ e M δ e
s U 1 Y β s Y p + g c o s θ 1 s U 1 Y r L β s 2 L p s s 2 A ¯ 1 + s L r N β N T β s 2 B ¯ 1 + N p s s 2 s N r β s δ s ϕ s δ s ψ s δ s = Y δ L δ N δ
For airships, in addition to the aerodynamic terms, significant force and moment terms due to the static buoyancy and inertial terms due to the displaced mass of air could be seen. Accordingly, the equations of motion for airships may be written as [31]
M u ˙ v ˙ w ˙ p ˙ q ˙ r ˙ = F d u , v , w , p , q , r + S u ˙ g , v ˙ g , w ˙ g , u g , v g , w g , p g , q g , r g + A u + v + w + p + q + r + G λ 13 , λ 23 , λ 33 + C c o n t r o l   f o r c e s   a n d   m o m e n t s + P p r o p u l s i o n   f o r c e s   a n d   m o m e n t s
where M is the mass matrix, F d is the dynamics vector, S is the atmospheric disturbance vector, A us the aerodynamics vector, G is the gravitational force/moment vector, C is the control forces and moments and P is the propulsion forces and moments.
Considering the equations of motion presented in equation 3, the decoupled longitudinal equations of motions of the airship could be presented as [33]
m x u ˙ + m a z x q ˙ q ˙ = m z q W + X a o + X u u + X w w + X q q θ m g B cos θ 0 m g B sin θ 0 + T t + T d S + T d p cos μ + X c
m z w ˙ m a x + z q ˙ q ˙ = m x q U + Z a 0 + Z u u + Z w w + Z q q + m g B cos θ 0 θ m g B sin θ 0 T d s + T d p sin μ + Z c
( m a z M u ˙ ) u ˙ ( m a x + M w ˙ ) w ˙ + I y y q ˙ = m g ( a x U + a z w ) + M a 0 + M u u + M w w + M q q + θ m g ( a x sin θ 0 a z cos θ 0 ) + B ( b x sin θ 0 b z cos θ 0 ) m g ( a x cos θ 0 + a z sin θ 0 ) B ( b x cos θ 0 + b z sin θ 0 ) + T t c z + T d s + T d p d z cos μ d x sin μ + M c
And the lateral equations are expressed as follows [33]
m y v ˙ m a z Y p ˙ p ˙ + m a x Y r ˙ r ˙ = m x r U + m z p W + Y a 0 + Y v v + Y p p + Y r r + ϕ m g B + Y c
m a z + L v ˙ v ˙ + I x x p ˙ I x z r ˙ =
m a z r U p W + L a 0 + L v v + L p p + L r r ϕ a z m g + b z B + T d p T d s d y sin μ + L c
m a x V v ˙ v ˙ I x z p ˙ + I z z r ˙ = m a x r U p W + N a 0 + N v v + N p p + N r r + ϕ cos θ 0 a x m g + b x B + T d p T d s d y cos μ + N c
where all the symbols are presented in the Nomenclature section at the end.
To define the equations of motion, two different functions are usually used. The first one is based on the Euler angle estimations providing roll, pitch, and yaw angles. A Direction-Cosine matrix (DCM) function is usually defined to estimate the Earth-to-Body relationship using the roll, pitch and yaw angles in radians. The second function is responsible for estimating the equations of motion in accordance with the quaternion definition. Likewise, a DCM function is defined to consider the Earth-to-Body-Axis rotation working with the four components of the Quaternion. The definition of the state vectors is explained in Table 2 as follows:
The control surfaces are bound with the FrSky Taranis X9 radio transmitter through a Wireless USB Dongle to transfer the pilot’s commands and control the airship during flight. Also, a HUD has been designed for the desktop simulator to provide aircraft performance data and environment information on the screen as shown in Figure 5 to increase pilots’ situational awareness. Finally, as the airship flight simulator is designed to enhance the flight test and training procedures, the autopilot features consist of basic modes such as pitch hold and altitude hold developed with the help of PID controllers. Features for data logging and real-time plotting are also available with a “.CSV” output file working in real-time and can be connected to the real-time plotting tools. The CSV file is used by the VR-HMD to update the HUD elements in real-time.

2.3. VR simulation

To accurately simulate the final goal of deploying a VR-based solution to monitor and pilot an airship in BVLOS scenarios a VR application was developed using the Unity software. Unity was chosen as the main VR engine due to its ease of use and multiplatform compatibility capabilities. Within the VR application, the user/pilot will be able to view a POV screen showing the simulated view from a POV camera located on the airship. Overlayed on top of the POV screen and locked to the pilot’s view will be the HUD which will display all the necessary flight information the pilot will need to safely operate the airship. To give the pilot better awareness of the controls, a digital twin of the radio flight controller has also been included within the VR environment. Not only the position of the virtual radio flight controller is tracked, but the orientation of the individual buttons, switches, and control sticks is also tracked and displayed. Thus, reducing the disconnect the pilot might experience between their physical environment and the virtual environment while wearing the VR-HMD.
Figure 6 shows a simplified process flow of how the flight simulator graphics and data are handled and displayed on the wireless VR-HMD. The Airship simulator receives flight input to control the simulated airship, at the same time an extra script records the flight data and controller data and exports them in a single CSV file in real-time. The VR application reads the CSV file and updates the HUD elements as well as the controller elements, the desktop with the POV view of the simulator is also captured and displayed in the VR environment. Using the flight data, controller data, and desktop capture the VR environment is rendered within the application. VR pixel streaming applications such as Virtual Desktop, ALVR, and Air Link are used to wirelessly stream the rendered view of the VR application onto the VR-HMD. Each frame on the VR application is rendered based on the Orientation of the VR-HMD in its physical space providing more immersion to the pilot within the VR environment.
The resulting flight simulation described in Figure 6 is presented in Figure 7 with a view from the proposed VR-HMD. Using a live data export script written in Nasal within FlightGear, the live flight data, as well as the radio controller input values, were saved onto a CSV file. A custom ReadCSV script within Unity was created to locate and opens the data file exported by FlightGear. The ReadCSV script queries the last line within the CSV file on every frame and stores the values in an array variable simply named ‘DataArray’. The order in which the values being read from FlightGear are placed within DataArray is determined by the order used to save the data.
Many of the variables within the ReadCSV script were made public to create the GUI seen in Figure 8. This GUI is used to set up information such as the file ‘Path’ to the data CSV file. Another important setup through the GUI in Figure 8. is pairing the data received from FlightGear to the different elements within Unity. For example, the ‘Heading Text’ variable seen in Figure 8 refers to a Text Renderer object in Figure 9 that displays the Heading information in the HUD that is locked to the users' view. The ‘Heading Text’ value changes based on the values within the DataArray variable. To let the application know which index within DataArray refers to in the heading of the aircraft, the ‘DataName’ and ‘DataIndexInt’ variables are set. In this example, the DataName is set to ‘heading’, and the DataIndexInt is set to 8, which is the index within the DataArray variable that corresponds to the heading of the aircraft. A similar setup can be seen for pitch, which pairs pitch to the index value of 2.
Using that single GUI all the data received from FlightGear are paired to the objects within the virtual environment. This pairing is what allows the animations on the controller and the values on the HUD to be updated.
The screen displaying the POV of the aircraft is created using a desktop duplication plugin for Unity called uDesktopDuplication. The plugin provides the ability to use the built-in capability of the Windows OS to capture the desktop and display it within the Unity environment. Using the plugin to display the desktop screen on a curved surface within the virtual environment provides more immersion to the user.
As described in Figure 5, a secondary third-party pixel streaming application is used to transmit the visuals from the PC to the wireless VR-HMD. In the case of the test shown in Figure 6, ALVR was the streaming application used. Although any VR pixel streaming application can be used depending on personal preference. ALVR was used for this paper due to it being free to use. VR pixel streamers such as ALVR stream visual data from the PC to the wireless VR-HMD, while streaming head and controller orientation as well as any inputs from the HMD to the PC. A common downside of using streaming applications such as ALVR and Virtual Desktop is that they have an inherent lag in streaming over Wi-Fi. The lag in streaming can be made worse with a poor internet connection and/or a resource-hungry application.

2.4. VR Flight Simulator Test and Analysis

After the successful completion of the proposed symbology design, the VR-HMD flight simulator presented in Figure 6 was utilized for human flight tests. To understand the effect of the primary flight display (PFD) symbology on pilots, a complete flight envelope from takeoff to the desired station altitude is simulated. For all test cases, Billy Bishop Toronto City Airport (CYTZ) situated in the city of Toronto is used as the local terrain, and a suitable flight path is developed to test users on specific operations that affect the airship safety (CFIT, loss of control and collision with object).
The test procedure was defined as follows:
1)
Start the flight and take-off at CYTZ airport (Runway 08) on reaching ~ 10 Knots and maintain a constant pitch of within 5 degrees.
2)
Reaching the altitude of 2,000 ft, turn to the right and try to reach the roll rate of 3 deg/sec and then turn left and try to reach zero roll rate by maintaining a constant pitch of always less than 5 deg.
3)
Adjust the Ballonet and Helium volume and station for 10 sec at the cruise altitude of ~ 5,000 feet with airspeed below 15 knots.
4)
On crossing the cruise altitude of 7,000 ft, turn to the left and try to reach the roll rate of 3 deg/sec and then turn right and try to reach zero roll rate by maintaining a constant pitch of always less than 5 deg.
5)
After crossing the altitude of 9,000 ft, Adjust the Ballonet and Helium volume and reach a climb rate of less than 20 ft per sec to prepare for station at the altitude of 10,000 ft by aligning the airship.
6)
Reduce the speed and maintain the 10,000 ft altitude.
7)
Align the flight path angle with the other airships in the network and remain stationary.
This flight plan tests the user’s ability to avoid all unsafe conditions while maintaining proper flight parameters. Towards the end of the test, the user must follow the proper flight path angle and other parameters to keep the airship at the desired stationary altitude at the proper waypoint.
Table 3 presents different variables considered while recording each user’s flight and the reason of choosing them. Each one of these parameters help to study the impact of the proposed VR-HMD tools compared to the existing desktop flight simulators.

2.4.1. REB Questionnaire

a)
Mental demand (Low/High): How much mental activity was required for thinking, deciding, calculating and remembering or searching certain information that is being presented.
b)
Physical Demand (Low/High): How much physical activity was required for pushing, pulling, turning or controlling activating the controllers
c)
Temporal Demand (Low/High): How much pressure does the operator feel due to the rate or pace at which the tasks or task elements occurred.
d)
Performance (Good/poor): How successful was the operator in accomplishing the goals of a given task set by the experimenter.
e)
Effort (Low/High): How hard did the operator have to work both mentally and physically to accomplish the level of performance.
f)
Frustration level (Low/High): How insecure, discouraged, irritated stressed and annoyed versus secure, gratified, content, relaxed and complacent did the operator feel with the information presented.
The users were supposed to rate each individual component on a scale of 1 to 10, where 1 being the lowest and 10 being the highest.

3. Results and discussion

The resulting flight simulation view of the proposed simulator described in Figure 4 is presented in Figure 10 for different POVs. As VR-HMD flight simulator was developed in the environment of the FGFS, the user can choose, organize, or modify the graphical modes using the available setup menus and camera views, such as from the control tower, from the cockpit and from different positions from the airship, as shown in Figure 10.
The technical goal of this study was to develop a system that could connect two different software and two different hardware in real-time with minimal lag between data transmission. The two different software being a flight simulator with a VR capable graphics engine. In this case, the flight simulator that was chosen was FlightGear and the VR capable graphics engine was Unity. The two pieces of hardware that were being connected were a PC and a wireless VR-HMD, in this case, the Oculus Quest. The connection point between FlightGear and Unity was a single CSV file that both applications used to share information. FlightGear to store data and Unity to read the stored data. The connection point for the PC and Oculus Quest was the pixel streaming application ALVR. ALVR transmitted graphical data to the Oculus Quest and transmitted positional and input data to Unity on the PC.
The connection points between the software and hardware are where the biggest issue in lag needs to be addressed. In the case of the CSV file, lag occurs during the writing and reading process. To successfully read or write to a file it must first be opened, then written to or read from, and finally closed and repeated individually by each application. The speed at which the reading and writing process occurs depends on the language being used. Another limiting factor is the frequency FlightGear logs data on the CSV file. If the frequency is too high, it can place a significant load on the PC which will affect the performance of any application running at the time. If the frequency is too low, then the data received by the user will be too outdated to use and the transmission cannot be considered real-time. A balance was found for FlightGear to write to a CSV at a period of 0.01s. For Unity, the file was read every frame which translates to around 0.0167s (60 Hz). Since the speed of the aircraft is not very high 0.1s was considered an acceptable margin to work within at this stage.
For the connection point between the PC and Oculus Quest, the bottleneck occurs at the pixel streaming application and Wi-Fi connection. On average the acceptable latency of data transmission between PC and VR for any pixel streaming application is between 22-32ms in ideal conditions. Ideal conditions being a strong Wi-Fi connection for the VR-HMD, a LAN connection for the PC, and a 5GHz connection. Internet speeds do not affect the latency. In situations of high latency, the resolution of the graphics is affected, until no transmission occurs. Another effect of high latency is that the user will receive outdated visual information. This means the user will see information that has already occurred in the flight simulator and will be too late to react to any situation. Another issue will be input lag. Input lag stands for the time it takes between when the user inputs a command and when the resulting action occurs. This would cause less than ideal flying conditions for the user.
A final global aspect affecting lag and latency is the hardware specifications of the PC and VR-HMD. The tests referred to in this paper were conducted on a Desktop PC and a Laptop. The Desktop PC ran on an AMD Ryzen 9, 3900X CPU, dual Nvidia GeForce RTX 2080 GPU, 64GB RAM, and 1Tb SSD. The laptop ran on a Core i7 (7th Gen) CPU, Nvidia GeForce GTX 1050 GPU, 32GB RAM, and 1TB HDD. Both devices were able to run FlightGear, Unity, and ALVR/Virtual Desktop with no latency issues. Performance on differently configured PCs will give a better understanding of which configuration would be ideal for the proposed system.
The test subjects were tested on three different scenarios with 10 different users while following the same flight path. All participants in the test were amateur users with linited experience of using VR headsets and flight simulation tools. In the first test case, the test subjects fly the airship with the desktop flight simulator. Secondly, the test subjects fly the airship via the VR-HMD flight simulator equipped with an internal HUD. Finally, the test subjects fly the airship via the VR-HMD flight simulator equipped with the internal HUD and tracks the remote controller motions along with test procedure projection on the screen of the virtual FrSky controller. As presented in Figure 11, the test procedure was also shown on the screen of the virtual FrSky controller and the VR screen to let users know about each step of the test well ahead of time. For all cases, the operator’s feedback was recorded.
Upon completing the flight tests, participants’ flight test results were recorded and they were requested to fill out the NASA TLX rating scale forms along with their feedback. In the following, the results are tabulated based on their respective flight tests for further analysis. It should be noted that in the following the results from the VR-HMD flight simulator equipped with an internal HUD is presented as VR-HMD 1 and the VR-HMD flight simulator equipped with the internal HUD and tracks the remote controller motions along with test procedure projection on the screen of the virtual FrSky controller is described as VR-HMD 2.
Figure 12 presents the altitude versus flight time for each participant. As can be seen, all participants were able to fly the airship at proper altitude and maintain flight plan requirements. However, the required time to accomplish the flight plan for the VR-HMD 1 simulator was higher than the desktop simulator and the VR-HMD 2 simulator.
Figure 13 presents the pitch angle versus flight time for each participant. As can be seen, users had better performance while operating the VR-HMD 2 simulator and the desktop simulator compared to the VR-HMD 1 simulator. Users were expected to maintain a value below 5 degrees for the pitch angle.
Figure 14 presents the roll rate versus flight time for each participant. The users were supposed to reach the roll rate of 3 deg/sec at certain altitudes to calculate any significant difference that may affect the overall flight safety.
Figure 15 presents the ground airspeed versus flight time for each user. The participants were supposed to maintain different ground speed values at certain altitudes to complete the flight plan.
Finally, figure 16 presents the rate of climb versus flight time for each user. The participants were supposed to maintain the desired altitudes at each phase of the flight plan while controlling the rate of height change as well.
The mental workload experienced by all the participants during all three flight tests is shown in Figure 17. The mental workload seems to be high among participants using the VR-HMD 1 simulator compared to the Desktop simulator and the VR-HMD 2 simulator. Also, the HOD decreases the mental workload in most of the participants. The main reason for the reduction in mental workload could be due to the test procedure projection on the screen of the virtual FrSky controller which helps the user having a step-by-step guideline.
Figure 18 presents the physical demand experienced by all the participants during all three flight tests. Similar to mental workload, the physical demand seems to be high among participants using the VR-HMD 1 simulator compared to the Desktop and VR-HMD 2 simulators.
Figure 19 depicts the overall temporal demand experienced by the participants during all three flight tests. The flight plan was carefully designed not to exert any sense of rush on the participants. Also, they were reminded to complete the tasks in their own time during the pre-flight briefing. The average amount of rush experienced by the participants using the Desktop and VR-HMD 1 simulators were higher than the VR-HMD 2 simulator.
In the next step, the participants were asked to rate their performance on a scale of 10. Their performance rating could depend on their ability to maneuver the airship properly, follow the flight path and maintaining stationary. As can be seen in Figure 20, the participants performed well when using the VR-HMD 2 and Desktop simulators compared to the VR-HMD 1 simulator.
Figure 21 presents the amount of effort required to complete the flight test using different methods. As expected, the effort needed to accomplish the flight test procedure using the Desktop and VR-HMD 2 simulators where less than the VR-HMD 1 simulator.
Finally, the participants were asked to mark the amount of frustration experienced while using all three different methods, and the results were graphed in Figure 22. The participants reported lowest values for the VR-HMD 2 compared to the other two methods.

5.1. Further developments

The proposed VR-HMD flight simulator can also be seen as a GCS system, and as shown in Figure 23 it is conceived to fully define the GCS concept and transmit flight information as well as POV visuals in real-time via the actual images broadcasted by the onboard video cameras. Accordingly, the same concept developed for the VR-HMD Simulator may be used for the VR-HMD GCS. A 360-degree camera of some sort as shown in Figure 23(a) to allow a VR-oriented view for the GCS may be integrated with the Raspberry PI and Pixhawk shown in Figure 23(e) using the available 4G/5G network. The VR-HMD simulator allows pilots to accomplish a part of real flight tests with the same data transmission techniques in a simulated environment. In addition, the development of the VR-HMD GCS may be enhanced by using an AR headset to visualize augmented flight using a first-person POV or a third-person POV such as the one shown in Figure 7 with the use of a graphical model of the actual airship. Furthermore, haptics and gloves may be integrated with the VR/AR-HMD GCS to increase situational awareness of the pilot in BLOS scenarios. Our current focus is to use the latest technology in the field to enhance the command-and-control station systems and move towards the goal of from simulated training to actual flight with a single united system.
Utilizing haptic sense into the proposed flight simulation tool can enhance the current work. The term “Haptics” was proposed by Revesz 1950, after observing blind performance and referring to an unconventional experience rather than traditional methods of touch and kinesthesis. More specifically, this term means "active touch" rather than passive touching [33,34]. For the next step, we want to incorporate haptic gloves to control the aerial vehicle with the use of a virtual controller defined within the virtual environment. The stand-alone VR headset will be connected to the haptics and the flight simulation tool. The VR headset will be used to visualize basic flight simulation while the vehicle could be controlled via the haptic gloves and a virtual controller defined within the virtual environment. Figure 24 shows the initial haptic based VR flight simulator where a pair of SenseGlove Nova Gloves was bound with a VR Oculus Quest and its controller to control the airship via a virtual Roll/Pitch/Yaw controller and a throttle. Initial results showed a significant decrease of the amount of physical and mental demand required by the users during flight.

6. Conclusions

This paper provided a system that can connect a flight simulator to a wireless VR-HMD and transmit simulated flight information as well as POV visuals in real-time. The purpose of such a system was to test the flight of stratospheric airships in BLOS scenarios. In this work, a desktop flight simulator was developed using the scaled-down geometry of the airship designed for stratospheric applications along with the corresponding aerodynamics and other characteristics of the aircraft in the FlightGear flight simulator. Moreover, the control surfaces were bound with a FrSky Taranis X9 radio transmitter. The VR-HMD streamed the flight environment and enhanced the design procedure of the stratospheric airship via the simulation tool. Our results showed that the VR-HMD flight simulator that is equipped with the internal HUD and tracks the remote controller motions along with test procedure projection on the screen of the digital twin of the FrSky controller showed better performance, less effort, less temporal demand, and less frustration compared to the desktop flight simulator. The current iteration of the system is ideal to train pilots on using similar systems in a safe and immersive environment. The proposed VR-HMD flight simulator may also be seen as a GCS prototype, and it is conceived to define the GCS concept and transmit flight information as well as POV visuals in real-time via the real images broadcasted using an onboard camera. Also, utilizing haptic sense into the proposed flight simulation tool can enhance the current study to lower the physical and mental demand during flight.

Author Contributions

Conceptualization, M.R. and J.C; Methodology, M.R., J.K., P.P. and J.C.; Software, M.R. and J.K.; Formal analysis, M.R. and J.K.; Writing—original draft, M.R.; Preparation, M. R.; Data curation, J.K.; Writing—review and editing J.K., P.P. and J.C. All authors have read and agreed to the published version of the manuscript.

Funding

This work was funded by Mitacs through the Mitacs Accelerate Program (reference number: IT16648) and Columbiad Launch Services Inc.

Conflicts of Interest

The authors declare no conflict of interest.

Nomenclature

Roman Symbols
A ¯ 1 Coefficient in denominator of the transfer function
a Distance from aerodynamic center to the center of gravity
B ¯ 1 Coefficient in denominator of the transfer function
b Distance from the aerodynamic center to the center of buoyancy
C Control forces and moments
d Rate of change of thrust position in x, y and z direction
g Acceleration of gravity
I x x Airplane moments of inertia about X
I x z Airplane product of inertia about Z
I z z Airplane moment of inertia about Z
L p Roll angular acceleration per unit roll angle
L r Roll angular acceleration per unit yaw rate
L β Roll angular acceleration per unit sideslip angle
L δ Roll angular acceleration per unit control surface angle
M The mass matrix
m Airplane mass
N p Yaw angular acceleration per unit roll rate
N r Yaw angular acceleration per unit yaw rate
N T β Yaw angular acceleration per unit sideslip angle (due to thrust)
N β Yaw angular acceleration per unit sideslip angle
N δ Yaw angular acceleration per unit control surface angle
P Power contribution, propulsion forces and moments
p Perturbed value of airplane angular velocity about X
p ˙ Rate of change of perturbed value of airplane bank angle
q Perturbed value of airplane angular velocity about Y
q ˙ Rate of change of perturbed value of airplane pitch angle
r Perturbed value of airplane angular velocity about Z
r ˙ Rate of change of perturbed value of airplane heading angle
S Reference area
s Laplace domain variable
T Thrust of the airship
t Time
U 1 Velocity component along X direction
u Velocity component along X direction
v Velocity component along Y direction
w Velocity component along Z direction
Y p Lateral acceleration per unit roll rate
Y r Lateral acceleration per unit yaw rate
Y β Latera acceleration per unit sideslip angle
Y δ Lateral acceleration per unit control surface angle
Greek Symbols
β Angle of sideslip
δ Control surface deflection angle
δ r Rudder deflection angle
θ Pitch angle
ρ Air density
μ Thrust incidence
Perturbed value of airplane bank angle
ψ Perturbed value of airplane heading angle

References

  1. Santos, J. S. A., Góes, L. C. S. and Pant, R. S. (2015) ‘Design and flight testing of an autonomous airship’, 22nd AIAA Lighter-Than-Air Systems Technology Conference, 2015, (June). [CrossRef]
  2. Smith, I. S. (2013) ‘HiSentinel & Stratospheric Airship Design Sensitivity’, Southwest Research Institute, KISS Workshop, available at: https://kiss.caltech.edu/workshops/airships/presentations/smith.pdf (accessed Sep. 19, 2021).
  3. Sceye (2021), ‘Sceye | A new generation of HAPS | High Altitude Platform Stations’, available at: https://www.sceye.com/ (accessed Aug. 25, 2021).
  4. Lobner, P. (2020), ‘DARPA Integrated Sensor is Structure (ISIS) airship’, available at: https://lynceans.org/wp-content/uploads/2020/12/DARPA-LM_ISIS.pdf (accessed Aug. 25, 2021).
  5. Stavros, A. (2013) ‘Lockheed Martin Lighter-Than-Air Programs Lockheed Martin Lighter-Than-Air Technologies’, (May), available at: https://kiss.caltech.edu/workshops/airships/presentations/horvarter.pdf (accessed Sep. 19, 2021).
  6. Thales (2017), ‘What’s up with stratobus’, available at: https://www.thalesgroup.com/en/worldwide/space/news/whats-stratobus (accessed Aug. 25, 2021).
  7. Chakraborty, I., Ahuja, V., Comer, A. and Mulekar, O. (2019) ‘Development of a modeling, flight simulation, and control analysis capability for novel vehicle configurations’, AIAA Aviation 2019 Forum, (June), pp. 1–24. [CrossRef]
  8. Melin, T. and Uyoga, D. (2018) ‘Formation Flight Mechanics and its Integrated Logistics’, Transportation Research Procedia. Elsevier B.V., 29, pp. 233–243. [CrossRef]
  9. Martins, L. S. N. (2020) ‘Development of a Flight Simulation Training Device and Remote Pilot Station: The URBLOG Unmanned Hybrid Airship Vehicle Case’, Universidade Beira Interior, 2020.
  10. Schaffernak, H., Moesl, B., Vorraber, W., Koglbauer, I.V. ‘Potential Augmented Reality Application Areas for Pilot Education: An Exploratory Study.’ Educ. Sci. 2020, 10, 86. [CrossRef]
  11. Oberhauser, M., Dreyer, D., Braunstingl R. and Koglbauer, I., (2018) ‘What’s Real About Virtual Reality Flight Simulation? Comparing the Fidelity of a Virtual Reality with a Conventional Flight Simulation Environment’, Aviation Psychology and Applied Human Factors, 8(1), pp. 22–34. [CrossRef]
  12. Oberhauser, M. and Dreyer, D. (2017) ‘A virtual reality flight simulator for human factors engineering’, Cognition, Technology and Work. Springer London, 19(2–3), pp. 263–277. [CrossRef]
  13. Cross, J. I., Boag-Hodgson, C., Ryley, T., Mavin, T., and Potter, L. E., (2022) ‘Using Extended Reality in Flight Simulators: A Literature Review,’ IEEE Transactions on Visualization and Computer Graphics. [CrossRef]
  14. Ernst, J. M., Ebrecht, L. and Schmerwitz, S. (2019) ‘Virtual cockpit instruments displayed on head-worn displays - Capabilities for future cockpit design’, AIAA/IEEE Digital Avionics Systems Conference - Proceedings, 2019-September. [CrossRef]
  15. McGowin, G. et al. (2020) ‘Examining Enhanced Learning Diagnostics in Virtual Reality Flight Trainers’, Proceedings of the Human Factors and Ergonomics Society Annual Meeting, 64(1), pp. 1476–1480. [CrossRef]
  16. Rauschnabel, P. A., Felix, R., Hinsch, C., Shahab, H., Alt,F. (2022) ‘What is XR? Towards a Framework for Augmented and Virtual Reality, Computers in Human Behavior,’Volume 133. [CrossRef]
  17. Mütterlein, J. (2018) ‘The three pillars of virtual reality? Investigating the roles of immersion, presence, and interactivity’, Proceedings of the Annual Hawaii International Conference on System Sciences, 2018-January, pp. 1407–1415. [CrossRef]
  18. Kamoonpuri, J. M. (2020) ‘Development of a 3D Holographic Flight Situational Awareness System’, BSc thesis, Department of Aerospace Engineering, Ryerson University, available at: https://digital.library.ryerson.ca/islandora/object/RULA%3A8752/datastream/OBJ/view (accessed Aug. 25, 2021).
  19. Halim, I., Casey, J., Baghaei, N. (2018) ‘Designing a virtual reality flight simulator’, ICCE 2018 - 26th International Conference on Computers in Education, Main Conference Proceedings, pp. 518–520.
  20. Pradhan, P., Chung, J., Chittaluri, V. and Park, H. U. (2017) ‘Development of Holographic User Interface for UAV Ground Control Using Microsoft Hololens’, 63rd Aeronautics Conference, (June), pp. 1–8.
  21. Auer, S., Gerken, J., Reiterer, H., and Jetter, H., (2021), ‘Comparison Between Virtual Reality and Physical Flight Simulators for Cockpit Familiarization’, Proceedings of Mensch und Computer 2021, pp. 378-392. [CrossRef]
  22. Aukstakalnis, S. (2017) ‘Practical Augmented Reality: A Guide to the Technologies, Applications, and Human Factors for AR and VR’. Boston: Addison-Wesley Professional, available at: http://ezproxy.lib.ryerson.ca/login?url=https://search.ebscohost.com/login.aspx?direct=true&db=nlebk&AN=1601678&site=ehost-live (accessed Aug. 25, 2021).
  23. Safi, M., Chung, J., Pradhan, P. (2019) ‘Review of augmented reality in aerospace industry’, Aircraft Engineering and Aerospace Technology, 91(9), pp. 1187–1194. [CrossRef]
  24. Parrish, K. (2016) ‘Japan Airlines is slapping HoloLens onto mechanics and flight crew students for paper-free training’ available at: https://www.digitaltrends.com/virtual-reality/hololens-japanese-airline-training/ (accessed Jun. 25, 2021).
  25. Pradhan, P. and Chung, J. (2021) ‘Development and Evaluation of Flight Deck using Augmented Reality’ Presented at CASI AERO 2021 Conference, Toronto, ON, Canada.
  26. Pradhan, P. and Chung, J. (2019) ‘Augmented Reality Cockpit Display System in Real-Time Flight Simulation Environment’ Presented at Ryerson University, Toronto, ON, Canada.
  27. VRcompare (2021) “VRcompare - The Internet’s Largest VR & AR Headset Database,” available at: https://vr-compare.com/ (accessed Jun. 25, 2021).
  28. Rostami, M., Chung, J. Multidisciplinary Analysis Program for Light Aircraft (MAPLA). In Proceedings of the Canadian Society for Mechanical Engineering International Congress, Charlottetown, PE, Canada, 27–30 June 2021.
  29. Berndt, J. S (2011) “JSBSim, An open source, platform-independent, flight dynamics model in C++”, The JSBSim Development Team, 2011.
  30. Rostami, M., Chung, J., and Park, H. U. (2020) “Design optimization of multi-objective proportional–integral–derivative controllers for enhanced handling quality of a twin-engine, propeller-driven airplane,” Adv. Mech. Eng., 12(6), 2020. [CrossRef]
  31. Cook, M. V., (1990) “The Linearised Small Perturbation Equations of Motion for an Airship”. https://hdl.handle.net/1826/1482.
  32. Stengel R. (2004), “Flight Dynamics”, First Edition, Princeton University Press, 2004.
  33. Robles-De-La-Torre, G. (2016) ‘The importance of the sense of touch in virtual and real environments’, IEEE Multimedia 13 (3), pp. 24-34. [CrossRef]
  34. Srinivasan, M. A. (1995) ‘Haptic Interfaces, In Virtual Reality: Scientific and Technical Challenges’, Report of the Committee on Virtual Reality Research and Development.
Figure 2. The airship model equipped with two electrical engines.
Figure 2. The airship model equipped with two electrical engines.
Preprints 70936 g002
Figure 3. Side, back and top view of the airship geometry.
Figure 3. Side, back and top view of the airship geometry.
Preprints 70936 g003
Figure 4. Required sub-sections to construct the Flight Simulation module.
Figure 4. Required sub-sections to construct the Flight Simulation module.
Preprints 70936 g004
Figure 5. HUD elements presented on the screen of the FGFS to increase pilots’ situational awareness.
Figure 5. HUD elements presented on the screen of the FGFS to increase pilots’ situational awareness.
Preprints 70936 g005
Figure 6. Simplified flowchart describing the process of displaying real-time flight information from a PC-based flight simulator onto a wireless VR-HMD.
Figure 6. Simplified flowchart describing the process of displaying real-time flight information from a PC-based flight simulator onto a wireless VR-HMD.
Preprints 70936 g006
Figure 7. View from within the Oculus Quest running the simulator.
Figure 7. View from within the Oculus Quest running the simulator.
Preprints 70936 g007
Figure 8. Data import GUI used to set up data from FlightGear into the simulation.
Figure 8. Data import GUI used to set up data from FlightGear into the simulation.
Preprints 70936 g008
Figure 9. Close-up of the Heading Tape on the head-locked HUD.
Figure 9. Close-up of the Heading Tape on the head-locked HUD.
Preprints 70936 g009
Figure 10. Different camera views within the flight simulator developed using the FGFS.
Figure 10. Different camera views within the flight simulator developed using the FGFS.
Preprints 70936 g010
Figure 11. Test procedure that is shown on the virtual RC controller screen and VR screen to let users know about each step.
Figure 11. Test procedure that is shown on the virtual RC controller screen and VR screen to let users know about each step.
Preprints 70936 g011
Figure 12. Recorded data for the altitude against the flight time for different pilots.
Figure 12. Recorded data for the altitude against the flight time for different pilots.
Preprints 70936 g012
Figure 13. Recorded data for the pitch angle against the flight time for different pilots.
Figure 13. Recorded data for the pitch angle against the flight time for different pilots.
Preprints 70936 g013
Figure 14. Recorded data for the roll rate against the flight time for different pilots.
Figure 14. Recorded data for the roll rate against the flight time for different pilots.
Preprints 70936 g014
Figure 15. Recorded data for the ground airspeed against the flight time for different pilots.
Figure 15. Recorded data for the ground airspeed against the flight time for different pilots.
Preprints 70936 g015
Figure 16. Recorded data for the rate of climb against the flight time for different pilots.
Figure 16. Recorded data for the rate of climb against the flight time for different pilots.
Preprints 70936 g016
Figure 17. Mental demand experienced by all the participants using all three test procedures.
Figure 17. Mental demand experienced by all the participants using all three test procedures.
Preprints 70936 g017
Figure 18. Physical demand experienced by all the participants using all three test procedures.
Figure 18. Physical demand experienced by all the participants using all three test procedures.
Preprints 70936 g018
Figure 19. Temporal demand experienced by all the participants using all three test procedures.
Figure 19. Temporal demand experienced by all the participants using all three test procedures.
Preprints 70936 g019
Figure 20. Performance of all the participants using all three test procedures.
Figure 20. Performance of all the participants using all three test procedures.
Preprints 70936 g020
Figure 21. Effort needed by all the participants using all three test procedures.
Figure 21. Effort needed by all the participants using all three test procedures.
Preprints 70936 g021
Figure 22. Frustration experienced by all the participants using all three test procedures.
Figure 22. Frustration experienced by all the participants using all three test procedures.
Preprints 70936 g022
Figure 23. Binding the VR headset and radio controller with an on-board 360 camera and the Raspberry PI to get the flight data and display them on the VR screen in Real-time using the 4G/5G network.
Figure 23. Binding the VR headset and radio controller with an on-board 360 camera and the Raspberry PI to get the flight data and display them on the VR screen in Real-time using the 4G/5G network.
Preprints 70936 g023
Figure 24. View from within the Oculus Quest VR running the flight simulator and the actual person wearing the SenseGlove Nova set for command and control.
Figure 24. View from within the Oculus Quest VR running the flight simulator and the actual person wearing the SenseGlove Nova set for command and control.
Preprints 70936 g024
Table 1. Airship geometry parameters.
Table 1. Airship geometry parameters.
Variable Value Description
dmax 17 ft Maximum hull diameter
fr 3.86 Fineness ratio (lairship/ dmax)
XCG 28.9 ft Center of gravity location from nose
XCB 28.9 ft Centre of buoyancy location from nose
ZCG-CB 3.28 ft Vertical distance between CG and CB (CG below CB)
lairship 65.62 ft Total Airship Length
me 375 lb Empty mass
Sf 63.5 ft2 Fin Reference Area
Sh 228.2 ft2 Hull Reference Area
Vol 10594.4 ft3 Hull Volume
Tmax 45 lbf Maximum Engine Thrust (Each)
Table 2. The state vectors used in the Euler-Angle and Quaternion simulations [32].
Table 2. The state vectors used in the Euler-Angle and Quaternion simulations [32].
Vector Euler Angle Quaternion
X (1) Body-axis x inertial velocity, m/s Body-axis x inertial velocity, m/s
X (2) Body-axis y inertial velocity, m/s Body-axis y inertial velocity, m/s
X (3) Body-axis z inertial velocity, m/s Body-axis z inertial velocity, m/s
X (4) North position of center of mass WRT Earth, m North position of center of mass WRT Earth, m
X (5) East position of center of mass WRT Earth, m East position of center of mass WRT Earth, m
X (6) Negative of CG altitude WRT Earth, m Negative of CG altitude WRT Earth, m
X (7) Body-axis roll rate, rad/s Body-axis roll rate, rad/s
X (8) Body-axis pitch rate, rad/s Body-axis pitch rate, rad/s
X (9) Body-axis yaw rate, rad/s Body-axis yaw rate, rad/s
X (10) Roll angle of body WRT Earth, rad q1, x component of quaternion
X (11) Pitch angle of body WRT Earth, rad q2, x component of quaternion
X (12) Yaw angle of body WRT Earth, rad q3, x component of quaternion
X (13) NA q4, cos (Euler) component of quaternion
Table 3. Flight variables under consideration.
Table 3. Flight variables under consideration.
Variable (unit) Description
Time (sec) Helps in calculating the time taken by the user to accomplish the test phase.
Ground Airspeed (knots) As speed plays an important factor throughout the flight phase, it is helpful to determine any unsafe condition (loss of control due to a reduction in speed) that could lead the airship into an accident.
Altitude (ft) Gives a realistic idea about the flight regime and the user’s ability to fly the airship at proper altitude to avoid any unsafe conditions (collision with terrain).
Rate of Climb (ft/sec) It is important to understand the rate of change of height while performing each step of the proposed test procedure.
Roll rate (deg/sec) Helps to evaluate the difference between the flight plan and the user’s performance to calculate any significant difference that may affect the overall flight safety.
Pitch Angle (deg) As an essential parameter that aids in providing stall information to the pilot, this is useful to evaluate pilot performance.
Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content.
Copyright: This open access article is published under a Creative Commons CC BY 4.0 license, which permit the free download, distribution, and reuse, provided that the author and preprint are cited in any reuse.
Prerpints.org logo

Preprints.org is a free preprint server supported by MDPI in Basel, Switzerland.

Subscribe

© 2024 MDPI (Basel, Switzerland) unless otherwise stated