Technical Paper

EISSN 2508-7150
Journal of Aerospace System Engineering http://dx.doi.org/10.20910/JASE.2021.15.4.75
Vol.15, No.4, pp.75-84 (2021)

Development of ROS-based Flight and Mission State Communication Node

for X-Plane 11-based Flight Simulation Environment
Sungwook Cho1,†
1
Major of Aeronautical and Mechanical Engineering, Division of Aeronautics, Cheongju University

Abstract

A novel robot-operating-system-based flight and mission state communication node for X-Plane 11 flight control
simulation environments and its simulation results were discussed. Although the proposed communication method
requires considerable implementation steps compared with the conventional MATLAB/Simulink-based User Datagram
Protocol (UDP) block utilization method, the proposed method enables a direct comparison of cockpit-view images
captured during flight with the flight data. This comparison is useful for data acquisition under virtual environments and
for the development of flight control systems. The fixed/rotary-wing and ground terrain elements simulated in virtual
environments exhibited excellent visualization outputs, which can overcome time and space constraints on flight
experiments and validation of missionary algorithms with complex logic.

Keywords: X-Plane 11 Flight Simulator, Robot Operating System (ROS), Node

simulation program based on real-time aerodynamics analysis

1. Introduction
and with improved computer graphics performance.
In this study, an X-plane 11 of Laminar Research and a
The development of various unmanned aerial systems, such
commercial flight simulation program, which was approved as
as drones, has resulted in the emergence of a high-value-added
a level-2 pilot flight training device by the Federal Aviation
service market for filming, surveillance, performance, and
Administration, were used as the base environment of the flight
delivery. Furthermore, Team Urban Air Mobility Development
control simulation. Unlike the previous studies, in this study, a
Korea, consisting of 37 government-led industry-academic
bridge node that interlinks with a C/C++-based ROS under a
associations is actively pursuing air mobility options [1–6].
Linux environment was developed. This bridge node matched
Unmanned aircraft flight simulators are critical for
the cockpit image information with the flight/mission state
developments of these systems. The flight simulation
information during simulation, and enabled the input of various
technology displayed in Figure 1 is typically used under various
flight control commands, as displayed in Figure 2.
environments during the development process for achieving
The remainder of this study is organized as follows: first, the
cost reduction, integrity verification of the software-side
technological trend related to the development of a flight
internal/external control laws and mission algorithms,
control simulation environment using X-Plane is presented, and
performance verification and improvement, and hardware-side
the existing results and the results of this study are compared.
system integrity verification and improvement. In particular, the
Next, the developmental results of this study are summarized,
choice of the simulation environment varies according to the
and the communication/control/flight and mission performance
technical maturity. An independent six-degrees-of-freedom
information with transmission/reception (Tx/Rx) steps is
(6DOF) unmanned aerial vehicle dynamic modeling and
presented. Finally, the execution results of using simulation are
visualization system is typically combined with a commercial
presented.
Received: Jun. 04, 2021 Revised:Aug. 11, 2021Accepted:Aug. 12, 2021
† Corresponding Author
Tel: +82-43-229-7875, E-mail: [email protected]
Ⓒ The Society for Aerospace System Engineering
76 Sungwook Cho

2. Related Research 2.2 Comparison of the Graphical User Interface- and

Command Line Interface Development
2.1 X-Plane Flight Control Simulation Environment Environments
Development Trend
In this study, an X-Plane 11 was used to simulate a C/C++-
X-Plane 11 is typically used for fixed/rotary-wing flight based ROS development environment [15] using
experiments and incorporates actual 6DOF model features, MATLAB/Simulink and LabVIEW based on Microsoft. The
such as external induction control rule and mission ROS-based command line interface (CLI) development
plan/allocation design of fixed/rotary wings into high- environment based on C/C++ on Ubuntu of Debian Linux was
dimensional algorithms. The flight and mission states were used. The general advantages and disadvantages of graphic user
communicated using the UDP communication block through interface (GUI)- and CLI-based development environments are
graphical programs such as MATLAB/Simulink or LabVIEW summarized in Table 1. This information may convey that a
[7–14]. CLI-based development environment has more advantages than
To verify the integrity of flight control systems, many disadvantages. This study used the ROS development
researchers have linked X-Plane and MATLAB/Simulink to environment to overcome CLI constraints to the flight control
construct a processor-in-the-loop environment [7–9]. In system.
particular, the X-Plane simulator with high fidelity is typically First, the ROS environment enabled node-based R&D. Thus,
used to verify flight control systems for difficult flight when constructing a flight control system, assigning one node
experiments, such as multiple unmanned aircraft operations and per block and the use of software configuration management
shipboard landing [10, 11]. Moreover, the manufacturer of X- systems, such as Git/Github, enabled convenient process
Plane provides a Plane Maker program that can directly provide management of software and research. Second, the use of
simulations for various user-defined aircrafts [12, 13]. X-Plane convenient and published communication methods and
is highly useful when performing R&D on aerial image protocols can be used at the right places for each node. Third,
processing algorithms based on actual environments because of public algorithms or libraries can be used appropriately for
its high-fidelity simulation [14]. specific R&D scenarios.
The difficulties in the GUI-based development environment
are as follows: 1) the communication of various sensor systems

Fig. 1 Block diagram for the X-Plane 11-based flight simulator (red box/line: proposed contribution)

Fig. 2 X-Plane 11-based UDP Rx/Tx system using robot operated system
 Development of ROS-Based Flight and Mission State Communication Node
77
for X-Plane 11-Based Flight Simulation Environment

Table 1 Comparison of GUI-based and CLI-based

development environments
Comparison and Command Line Graphical User
Analysis Interface (CLI) Interface (GUI)
Basic Direct coding by Coding by dragging and
Information entering commands on dropping functional
IDE or terminal blocks expressed as
images/icons
Ease of use Requires a high level of Desired functions can
expertise and coding be implemented with
skills and environment personnel with a low
construction skills level of expertise and Fig. 4 ROS node configuration graph
coding skills
Difficulty High Low
Memory use Low High
Execution speed Fast Slow 3. Technology Development Result
Integration/ Various libraries can be High expandability
expandability integrated (however, using the secured
requires environment libraries (separate 3.1 Environment Setting for the X-Plane 11 UDP
construction skills) library installation
difficult)
Communication
Open-source Many sources are open Few sources are open
Algorithm Difficult Easy In this study, the Tx/Rx connection between X-Plane 11 and
development ROS was implemented using UDP. The environment setting
method in X-Plane 11 for the UDP communication and the
implementation results of the data Tx/Rx node in ROS are
displayed as follows. Through IPv4 port forwarding, X-Plane
11 can be simultaneously connected to multiple simulators,
visualized based on an external system, and operated on
external devices such as iPhone/iPad, and set the UDP port.
This study activated the UPnP for IPv4 port forwarding
function, as displayed in Figure 3(a). The program was restarted
and configured to enable UDP communications by designating
the required port number.
Furthermore, the data communication speed was configured
(Fig. 3(b)), and the computer IP address was obtained to receive
the required data and use the communicated data was
configured as displayed in Figure 3(c). The port number should
match the “receive on (legacy)” in Figure 3(a).
Fig. 3 User Datagram Protocol (UDP) communication The simulation environment in this study was constructed on
environment setting in the X-Plane 11 flight a laptop with two Ubuntu operating systems and the same
simulator (a: enable/disable IPv4 port forwarding wireless communication environment; thus, an internal
communication network address such as 192.168.xx.xxx was
option, b: output rates setup option, c: destination
used. Furthermore, for the data output displayed in Figure 3(d),
network setting option, d: data selection for
the "Network via UDP" was used to enable Tx/Rx of selected
Rx/Tx) data through UDP communication.

applied in embedded systems that are continuously 3.2 State Information Reception and Control Input
minimized/alleviated, 2) the information exchange between
Transmitter Node Development
nodes or blocks following the widening scope of flight control
systems R&D, resulting from the rapid development of various
In this study, the Tx/Rx data were received in the ROS
machine/deep learning-based algorithms, and 3) the
environment through the UDP. The joystick-based control input
collaboration-based software R&D process management in
was connected to the corresponding fixed/rotary-wing airframe
large development organizations.
to control the input data to the previously selected Tx/Rx-
To overcome such difficulties, this study proposed a CLI-
permitted data. A node that transmits this data to X-Plane 11
based development environment using Ubuntu ROS. A flight
was developed. The node structure (including the Tx/Rx node)
control simulation environment was proposed by integrating X-
and the Tx/Rx node file configuration are displayed in Figures
Plane 11 to the proposed environment.
4–5.
78 Sungwook Cho

Table. 2 DATA command of X-Plane 11 UDP Table. 4 Selected flight and mission state data in the X-
communication Plane 11

Fig. 5 ROS package folder/file tree structure

Table. 3 GETT command of X-Plane 11 UDP variable of the general flight dynamics, the angle of attack, the
communication sideslip angle, the horizontal and vertical path angle, and the
control input. The mission state indicates the state variable of
aircraft instrument/electronics/electricity and control
surface/engine. We simulated control surface failure for
controlling the surface angle such that it corresponded to the
mission state and the rest to flight state. Moreover, the '-' sign
indicates the calculated data through received data, not the data
In this study, the DATA command was used in the UDP communicated through X-Plane.
communication [16–18]. Although an additional Software The files of the Tx/Rx node were arranged in folders, as
Development Kit is provided in X-Plane 11, the kit is complex. displayed in Figure 5. In this study, the C/C++-based variables
Thus, the required data were communicated in packets through and functions were categorized as the header files in the
the corresponding command language, and an explicit code was "include" folder, cpp files in the "lib" folder, and then accessed
implemented. Table 2 presents a scheme of the packet as inherited forms in the main function in the "src" folder. In the
configuration of the DATA command. "config" folder, the parameters required to run the Tx/Rx node
The DATA command used the first five bytes to identify the (e.g., Tx/Rx IP address, port number, pub/sub, and topic
communication method, as displayed in Table 2. Up to eight name/type) were declared and used within the node as
pairs consisting of a four-byte Tx/Rx information index and a encapsulated forms. In the “launch” folder, launch files were
four-byte value were communicated [14]. The ASCII code was placed to use the Tx/Rx node in individual/integrated forms. In
used and the UDP interface was used to index input matched the “msg/srv” folder, the protocol file that is necessary to use
the left-side data order on the network. Furthermore, four-byte the Publisher/Subscriber/service communication of the ROS
data were transformed to a 32-bit float using dynamic casting was placed. Typically, in ROS communication node
in C++. However, in the case of GPS data, the actual location development, C-language and Python-based process-oriented
may not match the map location because the DATA command development process is standardized and used on the official
returns as a float form. This mismatch was resolved by first ROS website. However, in this study, the object-oriented usage
receiving the 0th aircraft's GPS information in the 64-bit form method of ROS functions was directly determined and
through the GETT command, as listed in Table 3. Next, encapsulation/classification/inheritance was performed to
dynamic casting was used to convert this result into the double recycle key function codes and maximize the debugging
format. The flight and mission states were communicated, as performance between them. This object-oriented development
displayed in Table 4 to develop a basic flight control system. If method enabled code reusability and maximized capacity when
the order changed by adding/editing/deleting the assigned various ROS communication methods were applied on a node.
Tx/Rx data in X-Plane, then it was reflected in the ROS Tx/Rx
node. Furthermore, additional information, such as the rotation 3.3 Control Input Node Development Using a
speed*, quaternion, etc., was calculated using the received data. Joystick
The flight state assigned in this study indicates the flight state
Four types of joysticks were used in the study, as illustrated
 Development of ROS-Based Flight and Mission State Communication Node
79
for X-Plane 11-Based Flight Simulation Environment

in Figure 6. In Mode I, the pitch angle control and throttle

output control were configured to the vertical direction of the
left stick and the right stick, respectively.
In the Linux operating system, an additional activation
command is typically required to use a joystick. A 360° motion
stick and direction keys/side triggers/buttons, as illustrated in
Figure 6, were computed into axes, and the buttons output in
the array form when running the joystick node in ROS. In this
study, various control inputs were created using these arrays as
the input.
In this study, a stick refers to the state in which a 360°
movement is possible on the joysticks (Figure 6). The stick
information was used to implement control of the aileron,
elevator, rudder, and thrust control, which corresponded to the Fig. 6 Block diagram of the proposed ROS joystick
primary flight control surface roll/pitch/yaw/throttle. The control mapper node
Extreme 3D Pro Joystick (Logitech) has one stick; thus, the and in secondary flight control surfaces for trim control
stick’s up/down/left/right linear movements were mapped to the selection. Automatic/manual control mode transitions in flight
aileron and elevator in the roll/pitch direction, and the control systems can be simulated based on communication
clockwise/anti-clockwise rotations were mapped to the rudder protocols, which can be used for the verification of the integrity
in the yaw direction. Moreover, the additional vertical knob in of flight control algorithms before flight experiments.
the lower subdivision of the flight control space was mapped to Furthermore, various flight experiment scenarios were
the throttle control. The equations used for the primary flight simulated using independent control surface selection to set the
control surface mapping are expressed as follows: angle. The secondary flight control surface corresponded to the
flap/slat/speed brake controllable within X-Plane 11, and the
𝛿𝛿𝑎𝑎𝑎𝑎𝑎𝑎 = 𝜉𝜉𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟 𝑗𝑗𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟  mapped results in X-Plane's Plane Maker were used for the
𝛿𝛿𝑒𝑒𝑒𝑒𝑒𝑒 = 𝜉𝜉𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝ℎ 𝑗𝑗𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝ℎ  motion control. For example, for a typical fixed-wing aircraft
𝛿𝛿𝑟𝑟𝑟𝑟𝑟𝑟 = 𝜉𝜉𝑦𝑦𝑦𝑦𝑦𝑦 𝑗𝑗𝑦𝑦𝑦𝑦𝑦𝑦  DA-62 from Diamond (Fig. 7), the primary flight control
𝛿𝛿𝑡𝑡ℎ𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟 = 𝜉𝜉𝑡𝑡ℎ𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟 𝑗𝑗𝑡𝑡ℎ𝑟𝑟𝑟𝑟𝑠𝑠𝑠𝑠 (1) surface corresponded to the aileron located at the outermost side
of the main wings, an elevator located at the stabilizer, a rudder
Where 𝛿𝛿 is the control command, 𝜉𝜉 is the direction and scale, located at the vertical tail, and throttle for engine output control.
and j is the joystick input. The secondary flight control surface corresponded to the flap
The arrow keys react to the up/down and left/right located inside the main wings, and a trim tab located on the
movements in the [−1 0 1]𝑇𝑇 form. To realize this control, elevator/rudder, respectively.
an arbitrary scale was parameterized with high resolution, and
discrete-time integration and min/max saturation were 3.4 Cockpit-View Acquisition Node Development
performed to first compute the secondary flight control surface
and trim control value, which were then mapped to the actual X-Plane 11 does not support external environment sensors,
input value. The functional choices were distinguished using such as image/LIDAR, and does not provide additional
the buttons. The equations used for the secondary flight control communication channels. Therefore, ROS/Gazebo and AirSim
surface and trim control mapping are expressed as follows: have attracted considerable attention. Although they have low
fidelity of physical motion expression and actual environment
𝛿𝛿𝑎𝑎𝑎𝑎𝑎𝑎 = 𝑠𝑠𝑠𝑠𝑠𝑠[𝑚𝑚𝑚𝑚𝑚𝑚{𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖(𝜉𝜉𝑎𝑎𝑎𝑎𝑎𝑎 𝑗𝑗𝑎𝑎𝑎𝑎𝑎𝑎 )}] visualization, these simulation environments support various
𝛿𝛿𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡 = 𝑠𝑠𝑠𝑠𝑠𝑠[𝑚𝑚𝑚𝑚𝑚𝑚{𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖(𝜉𝜉𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡 𝑗𝑗𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡 )}] (2) sensor systems.

where sat is the saturation, map is mapped to a specific

value, and integ is the discrete-time integration. The surface
trigger and buttons were used for the transition between
automatic/manual control modes in ROS Tx/Rx nodes,
Fig. 7 Control surface mapping example with the fixed-
wing aircraft (i.e., DA-62, Diamond)
80 Sungwook Cho

3.5 ROS Node and X-Plane 11 Communication

Experiment

In this study, two computers with the Linux Ubuntu 18.04

operating system environment were each set to X-Plane 11 (i.e.,
desktop) and ROS-based UDP Tx/Rx node (i.e., laptop), and an
communication experiment environment was developed, as
displayed in Figure 9(a). The same ROS environment was
shared on the same wireless network, and the master-slave
functionality provided by the ROS was used for this purpose.
The desktop computer was selected as the ROS master, and the
laptop was selected as the ROS slave. The ROS-based screen
capture node ran in the master and was used in the slave. As
displayed in Figure 9(b), the simulation environment
construction results were verified for a fixed-wing/
multirotor/tiltrotor.

3.5.1 UDP Rx Node Communication

The communication of the UDP Rx node between X-Plane

11 and ROS are illustrated in Figures 9(c)–(e). The data in Table
4 and the output data through the terminal (Fig. 9.(c)) and the
information printed on the X-Plane 11 screen (Fig. 9(d)) are
identical. An observation revealed that valid data were
Fig. 8 Image captured during the flight (a: forward, b: calculated. The velocity value was received as MPH and the
downward) elevation value as feet but for unification purposes, these were
converted to the SI units m/s and m, which revealed consistent
results. Furthermore, in the ROS, the plot function illustrates
In this study, fidelity refers to the feasibility and degree of
the desired data with time on the x-axis, enabling acquired data,
reflection of the calculation of the simulation object's kinetic
as displayed in Figure 10(b). This result indicates the Rx
information, visualization using graphical performance, and
communication node as the targeted function.
data encoding/decoding/weight lightening for real-time output.
Forward and rear images were acquired using the external
3.5.2 Forward Image Capture
camera attached to the aircraft. The images were then linked
through a single protocol to the flight data acquisition time and
The result of the forward image capture test from the X-Plane
outputted in the form of OpenCV-based image data (Fig. 8) [19].
11 forward/vertical downward image screen capture-based
A screen capture node, which was used as an open software on
ROS communication function is displayed in Figure 10(a). In
the ROS, was applied to the development environment used in
the ROS, an image viewer, on which the output image view was
this study, and certain codes were modified to acquire VGA
displayed, as illustrated in Figure 10(a), and the corresponding
(640 × 480)-level images. This information was received from
data communication speed is depicted in the top left side of the
the UDP Rx developed in this study and set as the final output
figure. Here, the original image was received at a speed of
value after linking with the time and flight state information.
approximately 30 Hz through wireless communication, which
The field-of-view (FOV) was in the X-Plane 11 simulator such
revealed that the near-real-time original image was provided. In
that the screen size ratio was set to 4:3 and horizontal FOV to
the case of time delay information, the X-Plane 11 simulation
60°, which resulted in the FOV value of vertical 47°. Such
time cannot be received because of an internal feature of the
acquisition functionality of forward/vertically downward image
environment. In the ROS, the time reflects the internally
information enabled the performance verification and the
converted CPU time, and verifying the time delay with internal
integrity of the algorithm/framework at higher fidelity than
data is difficult. However, an average of 0.03 ms was assumed
other simulation environments when conducting R&D on
for internal GPU-based visualization of X-Plane 11.
image-based unmanned aircraft flight control. Moreover, the
Furthermore, between X-Plane and MATLAB/Simulink-based
data required for machine/deep learning R&D can be acquired
simulation environments approximately 0.08 ms of time delay
at a nearly real-environment state, reducing the effort of
occurred in command delivery. In total, a minimum of a 0.11
obtaining data through actual flight tests.
ms time delay was assumed to have occurred [21]. Images from
 Development of ROS-Based Flight and Mission State Communication Node
81
for X-Plane 11-Based Flight Simulation Environment

near-real-time simulation are displayed in the upper right-hand wing/multirotor/tiltrotor control results. In addition, all the
corner of Figure 10. systems realized in this study were interlinked with the actual
X-Plane 11 and ROS-based environment results to conduct
3.5.3 UDP Tx Node communication performance verification and result analysis. The primary
control surface was categorized into four major components in
The communication of the UDP Tx node between X-Plane 11 the current study, but each control surface was controlled
and ROS is displayed in Figure 11. For the joystick connected independently in X-Plane 11, allowing the design of unique
to the ROS, the Extreme 3D Pro of Logitech was used, as control distribution. Moreover, control surface breakdowns
displayed in Figure 9(a), and the ROS-based UDP Tx node was were reproduced in X-Plane 11 for control systems R&D.
applied to the fixed-wing, multirotor, and tiltrotor. In X-Plane Furthermore, aircraft electrical/electronic/instrumental system
11, the self-configured control allocation algorithm of the normal operation/breakdown circumstances were reproduced
simulator was applied, which enabled the control of the aircraft and used to research flight control system response to various
by transmitting four primary control surface information scenarios. The quantitative values of the time delay information
through UDP Tx from the ROS. However, during take- that occurs when image information is interlocked were
offs/landings, the secondary flight surface control and the calculated based on reference literature, but we plan to devise
tiltrotor’s thrust vector control were managed separately. an alternative method and seek its approval through continuous
Additional flight control surface information through the UDP research.
Tx/Rx node was enabled for this secondary control, as
illustrated in Table. 4. Therefore, when starting the X-Plane, the Acknowledgement
fixed-wing, multirotor, and tiltrotor of values displayed in
Figure 9(b) were used for moderate control of all the aircraft This work was supported by the research grant of Research
with a single joystick, as displayed in Figures 11(a)–(d). Institute of Industrial Sciences at Cheongju University
Furthermore, a function that configures the real-time (2019.09.01~2021.08.31).
automatic/manual control modes was implemented through the
joystick buttons. Figure 11(e) displays the conversion between
the automatic and manual modes, and all were made to produce
zero because a loop that generates automatic commands was not
References
implemented.
[1] Media cover letter, Ministry of Land, Infrastructure and
3.5.4 Control Surface Breakdown Reproduction Transport (MOLIT), https://www.molit.go.kr/USR /NEW
S/m_71/dtl.jsp?lcmspage=1&id=95084990, 29th, Dec.
The control surface breakdown was reproduced by 2020
communication the UDP Tx node of X-Plane 11 and ROS, and [2] Media cover letter, Ministry of Land, Infrastructure and
the results are displayed in Figure 12. The breakdown was Transport (MOLIT), https://www.molit.go.kr/USR/NEW
reproduced by transmitting a random constant value to the X- S/ m_71/dtl.jsp?lcmspage=1&id=95083976, 4th, Jun. 2020
Plane 11, with the left-side aileron of the fixed-wing aircraft [3] Media cover letter, Ministry of Land, Infrastructure and
stuck at the assigned angle through the ROS-based Transport (MOLIT), https://www.molit.go.kr/USR/NEW
communication node. In this instance, for such motion to be S/ m_71/dtl.jsp?lcmspage=1&id=95084057, 24th, Jun.
implemented, the aileron embedded on the main wing must be 2020
randomly divided and the range of motion must be previously [4] MOLIT and Joint Consortium, “K-UAM roadmap”, May
configurated through Plane Maker; aircraft with certain textures 2020.
assigned cannot replicate such motion as observed in some [5] Media cover letter, Ministry of Trade, Industry and Energy
cases. Therefore, the desired function was successfully (MOTIE), http://www.motie.go.kr/motie/ne/press e/press
implemented through the ROS-based communication node 2/bbs/bbsView.do?bbs_seq_n=163382&bbs_cd_n=81&cu
developed in this study. rrentPage=1&search_key_n=&cate_n=&dept_v=&search
_val_v=, 12th, Oct. 2020
[6] Media cover letter, Ministry of Land, Infrastructure and
4. Conclusion
Transport (MOLIT), https://www.molit.go.kr/USR/NEW
S/ m_71/dtl.jsp?lcmspage=1&id=95084962, 25th, Dec.,
In this study, an ROS communication node was developed
2020.
for an X-Plane 11-based flight control simulation environment,
and a realistic simulation environment was developed to
describe the UDP-based Tx/Rx, screen capture-based forward
image utilization, and joystick-based fixed-
82 Sungwook Cho

Fig. 9 Development results of the ROS/X-Plane 11-based flight simulation environment; (a) proposed flight simulation
environment; (b) applied vehicles (fixed-wing, multirotor, tiltrotor type); (c) flight state receive results using ROS-
based UDP Rx node; (d) X-Plane 11 flight state result; (e) calculated flight state results

Fig. 10 Development results using the image and multiplot viewer in ROS; (a) subscribed image result using the image
viewer (i.e., rqt_image_viewer, in ROS), (b) multiplot results with respect to the flight states (rqt_plot, in ROS,
upper: roll/pitch angle[deg.], middle: true heading angle[deg.], lower: true airspeed[m/s])
 Development of ROS-Based Flight and Mission State Communication Node
83
for X-Plane 11-Based Flight Simulation Environment

Fig. 11 Development results of the ROS/X-Plane 11-based flight simulation environment, UDP-Tx node, (a) fixed-wing
type aircraft (Diamond DA-62), (b) multirotor type aircraft (DJI Mavic 2), (c) tiltrotor type aircraft, hovering
(open-source), (d) tiltrotor type aircraft, cruise flight (open-source), (e) auto(manualAutoState:2) and
manual(manualAutoState:1) engagement test result

Fig. 12 Development results of the control surface stuck scenario based on the proposed ROS/X-Plane 11-based flight
simulation environment (a: normal operation of the control surface, b: malfunction state of the left aileron,
control surface stuck)
84 Sungwook Cho

[7] A. Bittar, H. V. Figuereido, P. A. Guimaraes, and A. C. Information, NASA, Sep. 2020.

Mendes, “Guidance Software-In-the-Loop simulation [19] B. Gary and A. Kaehler. “Learning OpenCV: Computer
using X-Plane and Simulink for UAVs,” 2014 International vision with the OpenCV library,” O'Reilly Media, Inc.,
Conference on Unmanned Aircraft Systems (ICUAS), pp. 2008.
993–1002, Orlando, FL, USA, May 2014.
[8] D. I. Han, Y. S. Kim, C. Y. Lee, D. W. Lee, and K. R. Cho,
“A Study on Verify of UAV Flight Control Software
Simulated Flight using Model-Based Development and X-
Plane simulator,” Journal of the Korean Society for
Aeronautical and Space Sciences, vol. 43, no. 2, pp. 166–
171, Feb. 2015
[9] B. G. Gang, M. Park, and E. Choi, “The Development of
The Simulation Environment for Operating a Simultaneous
Man/Unmanned Aerial Vehicle Teaming,” Journal of
Aerospace System Engineering, vol. 13, no. 6, pp. 36–42,
Dec. 2019
[10] S. Moon, E. M. Oh, D. I. You, and D. H. Shim,
“Implementation of a X-Plane and MATLAB/Simulink
based Simulation System for Multiple UAVs,” Journal of
Institute of Control, Robotics and Systems, vol. 19, no. 5,
pp. 442–449, May 2013.
[11] S. Koo, D. Lee, K. Kim, C. G. Ra, S. Kim, and J. Suk,
“Guidance and Control System Design for Automatic
Carrier Landing of a UAV,” Journal of Institute of Control,
Robotics and Systems, vol. 20, no. 11, pp. 1085–1091, Nov.
2014.
[12] L. Yu, G. He, S. Zhao, X. Wang, and L. Shen, “Design and
Implementation of a Hardware-in-the-Loop Simulation
System for a Tilt Trirotor UAV,” Journal of Advanced
Transportation, Oct. 2020.
[13] S. Lee, C. Park, Y. Park, and D. Lee, “Development of
Simulation Environment for Proximity Flight Using
Simulink and X-Plane,” Journal of the Korean Society for
Aeronautical and Space Sciences, vol. 49, no. 6, pp. 465–
472, Jun. 2021.
[14] S. W. Ha and M. C. Park, “Improvement of Processing
Speed for UAV Attitude Information Estimation Using ROI
and Parallel Processing,” Journal of The Korea Society of
Computer and Information, vol. 26, no. 1, pp. 155–161, Jan.
2021.
[15] Q. M. Conley, K. Gerkey, B. Faust, J. Foote, T. Leibs, J. Ng,
A. Y. “ROS: an open-source Robot Operating System”,
ICRA Workshop on Open Source Software, vol. 3, no. 3.2,
p. 5, May 2009.
[16] H. Kim, S. Cho, J. Do, H. Jang, and D. Lee,
“Implementation of PILS for Flight Algorithm Verification
of Unmanned Aircraft using LabView and X-Plane
Simulator,” KSAS Fall Conference, pp. 16668–1671, Nov.
2015.
[17] X-Plane 11 UDP network protocol (DATA), https://www.x-
plane.com/kb/data-set-output-table/
[18] X-Plane 11 network information format,
https://github.com/nasa/XPlaneConnect/wiki/Network-