KR101133665B1 - Unmanned aerial vehicle and distributed embedded system - Google Patents

Abstract

The present invention relates to an unmanned aerial vehicle and a distributed embedded system, and the unmanned aerial vehicle according to an aspect of the present invention, receives a plurality of various control packets, and provides a variety of navigation control embedded board from the outside to provide a sensing information packet collected from the sensor It includes mission control embedded boards that receive control commands to provide navigation control packets to navigation control embedded boards, and receive sensing information packets from navigation control embedded boards. Navigation control embedded boards include packet priority and application process priority. It processes navigation control packet and sensing information packet according to the rank and performs real time communication for information sharing and synchronization between embedded boards.

Description

Unmanned aerial vehicle and distributed embedded system

The present invention relates to an unmanned aerial vehicle and a network-based distributed embedded system for the same.

In an embedded system, each embedded board generally operates to distinguish each role or function in consideration of work efficiency. In order to construct an efficient embedded system, communication between each embedded board is essential.

For example, two types of embedded boards are provided inside an unmanned aerial vehicle to perform operations for each role or function. One is the Flight Control Computer (FCC) and the other is the Mission Control Computer (MCC) that performs a variety of applications. The FCC and the MCC exchange data packets with each other, process packets, and perform operations according to functions given to each other. Efficient communication must also be carried out between such FCCs and MCCs.

However, due to the support of multiple embedded boards for complex tasks in such embedded systems or in general embedded systems, conventional communication protocols are vulnerable to real-time data processing and are not suitable for board-to-board synchronization.

Accordingly, an object of the present invention is to provide an efficient communication between embedded boards in a distributed embedded system for performing a function of an unmanned aerial vehicle to maximize the efficiency of an unmanned aerial vehicle and an embedded system.

The object of the present invention is not limited to the above-mentioned object, and other objects that are not mentioned will be clearly understood by those skilled in the art from the following description.

According to an aspect of the present invention, an unmanned aerial vehicle includes a navigation control packet capable of controlling a plurality of navigation modules, outputs a control signal to each navigation module, and collects a sensing information packet collected from a sensor. A navigation control embedded board for providing a navigation control command from a user and a navigation control embedded board to provide the navigation control packet, and a second embedded board receiving the sensing information packet from the navigation control embedded board The navigation control embedded board receives the navigation control packets from the mission control embedded board through real time communication and processes the navigation control packets sequentially according to the priority of an application process, and when the priority is set in the navigation control packet, Process the received navigation control packet according to priority; .

Embedded system according to another aspect of the present invention, the navigation control embedded board for performing a navigation control function; And

Including a mission control embedded board that performs a mission control function different from the navigation control function,

The navigation control and mission control embedded board transmits and receives packets to each other, and processes the received packets to perform the navigation control and mission control functions.

The packet includes an Ethernet header, a destination port unit indicating an application to process a received packet among applications executed on each embedded board, a priority unit indicating a priority of the packet, and a data unit.

Each embedded board processes the packet according to an application processor's priority and the priority set in the received packet.

Specific details of other embodiments are included in the detailed description and the drawings.

According to an embodiment of the present invention, an MCC and FCC communication protocol in an embedded system, such as an unmanned aerial vehicle, is proposed to provide predictable communication overhead, to provide a board-to-board synchronization method, and to efficiently embed the priority setting function. System operation is possible.

BRIEF DESCRIPTION OF THE DRAWINGS The advantages and features of the present invention and the manner of achieving them will become apparent with reference to the embodiments described in detail below with reference to the accompanying drawings. However, the present invention is not limited to the embodiments disclosed below, but will be implemented in various forms, and only the present embodiments are intended to complete the disclosure of the present invention, and the general knowledge in the art to which the present invention pertains. It is provided to fully convey the scope of the invention to those skilled in the art, and the present invention is defined only by the scope of the claims. It is to be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. In the present specification, the singular form includes plural forms unless otherwise specified in the specification. As used herein, “comprises” and / or “comprising” refers to the presence of one or more other components, steps, operations and / or elements. Or does not exclude additions.

Hereinafter, an embedded system included in an unmanned aerial vehicle will be described as an example of an embedded system, but the present invention is not limited thereto, and any embedded system that transmits and receives packets between at least two embedded boards may be applicable. .

An unmanned aerial vehicle and an embedded system according to an embodiment of the present invention will be described with reference to FIGS. 1 to 8B. 1 is a block diagram illustrating an unmanned aerial vehicle and an embedded system according to an embodiment, FIGS. 2 to 5 are conceptual diagrams for describing a communication protocol between embedded boards, and FIGS. 6A to 8B are embedded according to an embodiment of the present invention. These graphs show the performance of the communication protocol applied to the system.

First, referring to FIG. 1, a vehicle according to an embodiment includes a flight control computer (FCC) and a mission control computer (MCC). The MCC receives a navigation control command wirelessly from a user (eg Wibro or RF) and transmits a navigation control packet that conforms to a protocol with the FCC to the FCC. In addition, the sensor information transmitted from the FCC, information about the navigation device or the image taken through the camera and the like wirelessly transmitted to the user. The FCC receives the navigation control packet from the MCC and outputs a control signal to a plurality of navigation control modules, such as a collective pitch actuator that controls the altitude of the vehicle. In addition, the FCC receives sensing information detected by a GPS or an Inertia Measurment Unit (IMU), and transmits a sensing information packet conforming to the protocol to the MCC.

Here, the communication protocol between the MCC and the FCC (Real Time Direct Protocol, hereinafter called RTDiP) may be a protocol suitable for synchronization in a single homogeneous network. It is possible to set the priority of the process and the packet processing by eliminating the kernel interference when sending and receiving packets between MCC and FCC. In addition, both reception and transmission can be performed by zero-copy to improve the reception and transmission speed.

With reference to FIG. 2, a packet transmission / reception process (hereinafter referred to as RTDiP-Send / Recv) of the FCC and the MCC will be described.

Referring to FIG. 2, the case where the FCC and the MCC transmit (a) and receive (b) the packet is shown with the prior art. In each of (a) and (b), the left figure is the prior art, and the right figure is the figure of the present invention.

First, as shown in (a), the prior art is copied from the user area (User) to the kernel area (Kernel) and then transferred to the hardware stage, but FCC or MCC is not copied to the kernel area user Direct copy from hardware to user. This is the case, for example, when the FCC outputs the sensor information packet to the MCC or when the MCC outputs the navigation control packet to the FCC.

And as shown in (b), the prior art processes the received packet using bottom half in the kernel area, but the FCC or MCC does not use bottom half. Therefore, packets can be processed according to the priority of the application process.

Here, referring to FIG. 3, a structure of a packet transmitted and received between the FCC and the MCC will be described. A packet transmitted and received between the FCC and the MCC includes an Ethernet header, an RTDiP header, data, and an error code. (CRC). The Ethernet header here is the same as a normal Ethernet header. The RTDiP header includes a destination port indicating an application to process a received packet among applications executed in an FCC or MCC, a length indicating a length of a packet, and a priority indicating a priority of processing a packet. A flag indicating a priority and a packet type are included. However, the Ethernet header may be replaced with a header of another protocol, for example, a header of a CAN and MOST communication protocol.

Referring to Figure 4 further describes the process of the FCC receives the navigation control packet transmitted from the MCC.

When the navigation control packets of the structure shown in FIG. 3 are transmitted from the MCC, the device driver of FIG. 3 stores each navigation agent packet in a buffer of each port according to the information of the destination port. . For example, a packet for APP1 to be processed by the first application APP1 is stored in the first buffer Buffer1, and packets 1 to APP2 and Packet1 for APP2 to be processed by the second application APP2 are stored. Store in the second buffer (Buffer2). The first packet Packet1 for APP2 and the second packet Packet1 for APP are processed first according to priority information of a priority unit among the packets Packet1 for APP2 and Packet1 for APP2 to be processed by the second application. Store APP2) in the buffer. The arrival of each packet (data) is detected through polling I / O according to the API used by the user, and data is sent to the user area by calling a system call (e.g., a call recv). Is copied.

At this time, the processing order may be determined according to the priority set by the user. That is, if the first application APP1 has a higher priority than the second application APP2, a packet for APP1 to be processed by the first application APP1 is first provided to the first application APP1. After processing, the packets Packet1 for APP2 and Packet1 for APP2 to be processed by the second application may be provided to the second application APP2 and processed.

However, when the priority information is not included in each packet or the priority is the same, the transmitted packets may be sequentially processed. For example, when a user raises altitude and sends navigation control commands to turn to the right and go straight, navigation control packets for each of them are transmitted from the MCC to the FCC in real time, and the FCC sequentially processes each of the transmitted navigation control packets. The control signal is output to each navigation module. However, in the event of an accident, such as a sudden obstacle, the user first sends a command to bypass to the left to avoid the obstacle, and the FCC sequentially raises the navigation control packets to increase the altitude, turn to the right and go straight. Rather than processing, a higher priority, left-handed navigation control packet can be processed first.

Next, a synchronization communication method (hereinafter referred to as RTDiP-Sync) between the FCC and the MCC will be described with reference to FIG. 5.

Packets that do not need to be processed in real time among packets transmitted and received between the FCC and the MCC, for example, sensing information packets, may not be transmitted or received by the above-described method, but may be transmitted and received through a synchronous communication method. The sensing information is not necessarily necessary information continuously in real time, but may be provided to the user periodically. Up to this sensing information, if the FCC transmits to the MCC in real time and the MCC processes the packets in the order in which they are received, the communication overhead increases. That is, in the synchronization communication, only the most recent data becomes valid data when performing synchronization, and in the present invention, the FCC retains only the most recent data, such as, for example, a sensing information packet, and can be processed in the MCC in the manner described below. .

Referring to FIG. 5, the FCC or MCC has a shared memory shared between a user area and a kernel area.

First, a process in the user area sets up the shared memory, and initializes the buffer ID indicating unit (Buffer ID) and the length information Len0 and Len1 of the shared memory. When the sensing information packet is transmitted from the MCC, an interrupt handler of the kernel region checks the buffer ID indicating unit (Buffer ID) set in the shared memory in order to know the address of the buffer to store the transmitted sensing information packet. If so, the transmitted data is stored in shared buffer 0. The interrupt handler updates the length information of the shared data stored in shared buffer 0 to Len0.

Next, a process in the user area sets the buffer ID value of the memory to '1'. For data reliability, when a data is read by a user process, even if an arrival interrupt of new data occurs, the new data is stored in shared buffer 1 so that the data being read by the user process is kept safe. Can be.

Do not use system calls in this process. This is because shared memory can be recognized in the user area. Therefore, communication overhead can be estimated. Experimental results supporting this are shown in FIGS. 6A and 6B. FIG. 6A is a result of testing communication overhead predictability for a general TCP / IP protocol using bottom half, and FIG. 6B is a communication case using a shared memory without using a system call in the present invention. This is the result of testing the overhead predictability. Comparing FIG. 6A and FIG. 6B, it can be seen that the communication overhead is very small when the shared memory is used without using the system call in the present invention.

On the other hand, these APIs of RTDiP-Send / Recv and RTDiP-Sync support asynchronous API and synchronous API.

First, the asynchronous API is explained.

In case of RTDiP-Send / Recv, asynchronous API checks whether there is data arrived by calling system call. If the data arrives, copy the data to the user area and return the length of the data as the return value of the system call. The user process can determine the arrival of data through the return value of this system call. If no data arrives, the system call returns 0.

RTDiP-Sync's asynchronous API, on the other hand, does not use system calls. RTDiP-Sync uses a shared buffer with memory mapping to check if data arrives in the user process area. RTDiP-Sync's asynchronous API eliminates operating system call and provides the user with predictable communication overhead.

User processes that use the asynchronous API can perform other tasks while the application is running without waiting for the RTDiP to respond. This is possible because the application is not blocked.

RTDiP's asynchronous API consists of the following:

Int RTDiP_Recv (int fd, void * data, int length)

RTDiP-Sync API

struct RTDip_Sync RTDiP_Sync_Recv (int fd)

Next, the synchronous API will be described.

In general, even an embedded system rarely runs a single application. For example, in an embedded system that transmits attitude data from an unmanned helicopter, there may be an application process of collecting data of a horizontal sensor from one system and a process of transmitting this information to another embedded system. In this case, it is important to divide the CPU resources efficiently. The API provided by the conventional protocol is difficult to use CPU resources efficiently. This is because the application process uses polling when using an asynchronous API. This increases CPU share of the user process, which wastes CPU resources. Thus, in the present invention, an asynchronous API may be suitable, but a synchronous API is also implemented to accommodate various requirements.

RTDiP's synchronous API consists of the following:

Synchronization API in RTDiP-Send / Recv:

int ku_recv_blocking (struct ku_sock * k_sock, void * data)

RTDiP-Sync's Sync API:

struct RTDiP_Sync Sync_Recv_blocking (struct ku_sock * k_sock)

RTDiP-Send / Recv's synchronous API works as follows. First, when the function is called, it checks to see if there is any data already arriving in the RTDiP data buffer. When data already arrives, the function passes the existing data to the user process and exits the function. On the other hand, if no data exists, add the current process contents to the scheduler wait queue and restart the process. This synchronous API is implemented based on interrupts. That is, when a data packet in RTDiP format arrives at the network controller, the interrupt handler examines the contents of the scheduler wait queue and wakes up the process.

RTDiP-Sync, on the other hand, uses a system call unlike the asynchronous API. But it's not just for data copying, it's just telling the kernel that the user process should sleep now. This is because RTDiP-Sync can determine whether new data has already arrived in the user area. Therefore, when RTDiP-Sync calls a system call, it blocks the user process. Like RTDiP-Send / Recv, RTDiP-Sync is out of block state due to interrupt. This is also done in the interrupt handler.

Synchronous API can reduce CPU resource consumption due to polling. This can provide an environment where multiple application processes can efficiently share the CPU.

The API of the present invention also supports a timed API.

In an embedded system, it is very important to avoid a system hang by default. This is because most embedded systems run without the user operating them. Therefore, you should avoid the situation where the synchronous API is continuously blocked in an unexpected situation while using the synchronous API. For this reason, the synchronous API provides a timeout API that escapes the block state after a certain amount of time. The timeout API is basically done with the synchronous API. Time-limited API It consists of two APIs as follows.

Int Set_ExpireTime (struct ku_sock *, long time)

Sets the block expiry time as the time passed as a parameter to the communication link pointed to by the RTDiP communication structure passed as a parameter.

long Get_ExpireTime (struct ku_sock *)

Retrieves the currently set expiration time.

The time limit can be set differently for RTDiP-Send / Recv and RTDiP-Sync. For example, a communication connection using RTDiP-Send / Recv can set the expiration time to 1 hour in one process and a communication connection using RTDiP-Sync to 10 minutes. The time unit of the timeout API may be 1ms in the Linux kernel 2.6. In other words, if the time argument is set to 1000 in the Set_ExpireTime function, the synchronous API will wait for an interrupt for RTDiP of the device for 1 second and will exit the block state if no interruption occurs. If the expiration time is not specified using the timeout API when using the synchronous API, the time may be set to 60 minutes by default.

Measure and compare the performance of the asynchronous and synchronous APIs described above. Measure CPU throughput for each situation using the timed API. For performance measurements, Huynx's Acumen270 processor board with Intel Xscale PXA270 (520MHz) was used. To measure network performance, the two boards were connected directly with an Ethernet cable without an Ethernet switch or hub. FIG. 7A shows the one-way delay time of RTDiP-Send / Recv, and FIG. 7B shows the one-way delay time of RTDiP-Sync. The unit of one-way delay time is in microseconds (us). The items in the graph include the asynchronous API (Non Block), the synchronous API (Block), and the timeout API (Time API 1ms) with the expiration time set to 1ms.

As the graph shows, both the RTDiP-Send / Recv and RTDiP-Sync APIs perform better. This is because a process sleeping using the synchronous API is not executed immediately after an interruption occurs. The RTDiP process using the synchronous API will only run after the time allotted to other processes running while asleep using the synchronous API. Asynchronous APIs, on the other hand, perform better when interrupts occur while continuing to check for interrupts, so unidirectional latency outperforms synchronous APIs. Therefore, asynchronous interrupts can be used for applications such as system resources that are relatively rich and stricter real time.

RTDiP-Send / Recv and RTDiP-Sync using the time-limited API all show similar time as the synchronous API. This is because the block expiration time set by the timeout API is too long. Both RTDiP-Send / Recv and RTDiP-Sync have a maximum bi-directional delay of 480us ~ 535us at the maximum message size (1450Bytes). As a result, every network packet generates an interrupt. In other words, because the experimental packet arrives before the time expires, all of them are escaped by an interrupt without escaping the block due to the expiration time.

Next, we experimented with CPU utilization. In order to measure the CPU utilization, the one-way latency measurement program used earlier was run for a certain time. At the same time, the CPU measurement program was run to measure the CPU utilization time of each experimental group. CPU utilization was measured using mpstat included in Sysstat. Figure 8a shows the measurement results of the CPU utilization rate of RTDiP-Send / Recv and Figure 8b shows the measurement results of the CPU utilization rate of RTDiP-Sync. Each item in the graph shows the CPU utilization (% user), CPU usage (% sys) used by the system call, the CPU usage (% irq) used to process irq, and the sum of these values. This is CPU utilization (% cpu utilization). As described above, the horizontal axis items include the asynchronous API (Non Block), the synchronous API (Block), and the timeout API (Time API 1ms) in which the expiration time is set to 1 ms using the timeout API.

The CPU utilization rate of RTDiP-Send / Recv is about 2.2 times better than the asynchronous API, and about 3 times better for RTDiP-Sync. The reason the CPU utilization was low while the synchronous API was performing the same amount of work was because, unlike the asynchronous API, it avoided wasting CPU resources due to polling. Therefore, as shown in FIG. 8A, RTDiP-Sync has lower user area CPU utilization in the synchronous API than in the asynchronous API. In case of RTDiP-Send / Recv, the CPU usage is higher than the synchronous API because the system call is called every time the asynchronous API calls the receiving function when polling. This allows the synchronous API to allow multiple applications to use the CPU efficiently.

Those skilled in the art will appreciate that the present invention can be embodied in other specific forms without changing the technical spirit or essential features of the present invention. It is therefore to be understood that the above-described embodiments are illustrative in all aspects and not restrictive. The scope of the present invention is shown by the following claims rather than the detailed description, and all changes or modifications derived from the claims and their equivalents should be construed as being included in the scope of the present invention.

1 is a block diagram showing an unmanned aerial vehicle and a distributed embedded system according to an embodiment.

2 to 5 are conceptual diagrams for describing a communication protocol between embedded boards.

6A through 8B are graphs illustrating the performance of a communication protocol applied to an embedded system according to an exemplary embodiment of the present invention.

Claims (13)

A navigation control embedded board that receives navigation control packets capable of controlling a plurality of navigation modules, outputs a control signal to each navigation module, and provides sensing information packets collected from the sensors; It includes a mission control embedded board receiving the navigation control command from a user to provide the navigation control packet to the navigation control embedded board, the sensing information packet from the navigation control embedded board, The navigation control embedded board receives the navigation control packets from the mission control embedded board through real time communication, processes them sequentially according to the priority of an application process, and when the priority is set in the navigation control packet, the priority Processing the received navigation control packet according to a rank Drone. The method of claim 1, The navigation control embedded board uses RTDiP (Real Time Direct Protocol) when communicating with the mission control embedded board. Drone. The method of claim 1, When the navigation control and the mission control embedded board transmit and receive the sensing information packet and the navigation control packet, respectively, without directly copying to the kernel area. Drone. The method of claim 1, The navigation control packet transmitted from the mission control embedded board is detected whether it is transmitted to the navigation control embedded board by polling and blocking I / O, and the navigation control embedded board is detected by a system call. Provided by the application in question Drone. The method of claim 1, wherein the mission control embedded board A shared memory shared by the kernel region and the user region and the kernel region and the user region, and transmitting and receiving the navigation control embedded board, the navigation control packet, and the sensing information packet through the shared memory. Drone. The method of claim 5, The shared memory includes at least two shared buffers and a buffer ID indicating unit which indicates a shared buffer in which data of the sensing information packet transmitted among the shared buffers is to be stored. The interrupt handler of the kernel region stores the data of the transmitted sensing information packet in a shared buffer indicated by the buffer ID support unit of the shared buffer. Drone. The method of claim 1, wherein the navigation control packet or the sensing information packet An Ethernet header, a destination port part representing an application to process a received packet among applications executed on each embedded board, a priority part indicating a priority to be processed by the packet, a data part, and a flag indicating a type of a packet Including Drone. A navigation control embedded board performing a navigation control function; And Including a mission control embedded board that performs a mission control function different from the navigation control function, The navigation control and mission control embedded board transmits and receives packets to each other, and processes the received packets to perform the navigation control and mission control functions. The packet includes an Ethernet header, a destination port unit indicating an application to process a received packet among applications executed on each embedded board, a priority unit indicating a priority of the packet, and a data unit. Wherein each embedded board processes the packet according to an application processor's priority and the priority set in the received packet. Distributed embedded system. The method of claim 8, Communication between the embedded boards using Real Time Direct Protocol (RTDiP) Distributed embedded system. The method of claim 8, When each embedded board outputs the packet, it immediately outputs the packet without copying it to the kernel area. Distributed embedded system. The method of claim 8, Packets transmitted to each embedded board are detected by polling and blocking I / O, and are provided to a corresponding application in each embedded board by a system call. Distributed embedded system. The method of claim 8, wherein each of the embedded board A shared memory shared by the kernel region and the user region and the kernel region and the user region, and processing the transmitted packet by detecting whether a packet is transmitted through the shared memory. Distributed embedded system. The method of claim 12, The shared memory includes at least two shared buffers, and a buffer ID indicating unit indicating a shared buffer in which data of a transmitted packet among the shared buffers is to be stored. The interrupt handler of the kernel region stores the data and the data length of the transmitted packet in a shared buffer indicated by the buffer ID indicating unit of the shared buffer; Distributed embedded system.

Images