|
Beyond-Line-Of-Sight (BLOS) Unmanned Aircraft control
|
In the command and control system shown next for use on small Unmanned Aircraft,
several important features are supported:
-
we use a 9,600 bps, duplex, satellite link which can be implemented using a
small, light, relatively inexpensive satellite phone modem. This link is used
for the duration of the flight. See
comms BLOS
.
-
Air Traffic Control (ATC) messages picked up on the VHF frequency band are
digitally encoded, for example, using the Code Excited Linear Prediction (CELP)
algorithm at 4,800 bps and are switched by SW1 in the diagram below to the
multiplexer, which combines the FEC coded status message data with the digitised
ATC voice and sends this information to the satellite modem for transmission to
the satellite. SW1 is controlled by the Received Signal Strength Indicator
(RSSI) from the VHF receiver, so the switching of Tx CH B from video line scan
data to ATC voice data is immediate on detection of voice data.
-
In the absence of any ATC voice data, SW1 switches in video line scan data at
4.8 kbps (600 pixels x 8 bit mono imagery) derived from a 640 x 480 pixel
imaging array. One line is sent every second to enable the Ground Control
Station (GCS) to build up a strip map showing the progress of the UA.
-
On the uplink from the GCS to the Unmanned Aircraft, 4,800 bps of the 9,600 bps
duplex data rate is used for direct UA control, which might be in response to an
ATC request or order. In order to make it more difficult for an unauthorised
person to gain control of the UA, this data is encrypted with a lossless
encryption algorithm, and then coded with Forward Error Correction (FEC) at the
GCS, so FEC decoding followed by decryption must be applied in the Unmanned
Aircraft receiver.
-
a
unique, contiguous, message number
+
GPS synchronised, UTC time
+
date
must be included in each uploaded flight plan update message, in each UA remote
control message and in each UA status message download to avoid what is referred
to as a "spoofing" attack in which a copy of an earlier message is
inadvertently, or deliberately, transmitted to the UA, or, to the GCS.
-
SW2 is used to switch the Channel B data received between digital-to-analog
conversion of the digitally encoded voice data reply to the ATC and the flight
plan update system. The control of SW2 is both by the VHF Receiver and by the
Aircraft Remote Control, with the Aircraft Remote Control having priority.
-
Again, to make it more difficult for an unauthorised person to gain control of
the Unmanned Aircraft, the flight plan update information is both encrypted with
Forward Error Correction applied at the GCS, with FEC decoding being applied on
the UA to retrieve the original data.
-
One of the advantages of applying FEC to both the status messages from the UA to
the GCS and the flight update plans and the UA remote control commands from the
GCS to the UA is that the Bit Error Rate of the duplex communications link can
be continuously monitored by tracking the number of errors detected by the FEC
data processing.
Diagrammatic view of the duplex, 9,600 bps, communication channel
In summary, the single 9,600 bps duplex channel is used to:
-
relay voice communications from FIS-B to the GCS
-
relay duplex voice communications to and from the Tower, an ATC_1 centre and an
adjacent ATC-2 centre;
-
support the download of progressive line scan imagery when voice channel 1 relay
is not in use
-
support the download of Unmanned Aircraft status messages sent from the UA to
the GCS at a rate of 1 message per second
-
support the upload of UA configuration control commands and flight plan change
commands
-
support the remote control of the Unmanned Aircraft from the GCS
The Rx signal summing, Tx signal switching, section
The Rx and Tx data multiplexing, front-end, section
return to top
|
Bandwidth required for Unmanned Aircraft operations
|
- from
http://www.caa.gov.au/pilotcentre/projects/vhf25khz/Discussion_paper_25_kHz_channel.pdf
-
We have
demonstrated
that the Unmanned Aircraft Status Message can be less than 4,800 bits in size.
We envisage an always-ON link over which one status message per second is sent
from the Unmanned Aircraft to the Ground Control station.
-
We sum the three voice channels picked up by the three VHF receivers
on the Unmanned Aircraft
and then digitise
(for example, using the CELP algorithm)
the resultant voice signals to a 4,800 bps data stream. The voice channels
correspond to:
TOWER or FIS-B (Flight Information Service - Broadcast)
ATC_1 centre = an arbitrary ATC centre
ATC_2 centre = an adjacent ATC centre
-
We need to be able to transmit three channels (forward left, forward and forward
right) of video information when the Unmanned Aircraft is on the ground to
enable the remote pilot to steer the Unmanned Aircraft on the runway, and avoid
all obstacles (including other aircraft). The video cameras need to convey at
least the same visual information as seen by a real pilot, that is +/- 115
degrees azimuth and +/- 15 degrees in elevation. Hence the need to use three
cameras.
return to top
|
LOS bandwidth required for Unmanned Aircraft operations
|
We assume the use of an
efficient modulation scheme
, such as GMSK or QPSK to achieve a modulation efficiency in excess of 1
bit/s/Hz:
|
modulation scheme
|
modulation efficiency
in bits/s/Hz
|
comments
|
|
GMSK
|
1.35
|
Gaussian Minimum Shift Keying
frequency shift keying used in GSM 900 / 1800
|
|
QPSK
|
1 - 1.6 (typ)
2 (max)
|
quaternary (4) PSK
|
The suggested bandwidth requirement for each Unmanned Aircraft is shown next.
-
remote control = Unmanned Aircraft remote control, typically on take-off,
landing and in an emergency
-
FPU = Unmanned Aircraft Flight Plan update
So, from the above, one can support the Command and Control communications
(apart from the video data required at take-off and landing, including emergency
landing) for 80 Unmanned Aircraft per MHz of bandwidth. Since one might like to
use a LOS link to an aircraft at Flight Level 600 (= 60,000 ft = 18.3 km) one
would define a LOS distance of at least 20 km.
Since the video transmission will only occur when the aircraft is moving
relatively slowly at take-off and landing, one could use the high fidelity
COFDM modulation format
as used in DVB-T (Digital Video Broadcasting-Terrestrial) which has a bandwidth
of 8 MHz (actually, 7.61 MHz + guard band). This modulation scheme is sensitive
to Doppler shift, and degrades when the speed difference between the transmitter
and the receiver exceeds 185 kph.
The license free, 5.8 GHz Industrial, Scientific and Medical ("ISM") band, is a
large, contiguous, 125 MHz band stretching from 5,725 MHz to 5,850 MHz. It
appears that manufacturers have selected bands in the 5.8 GHz ISM band to suit
their communication system technology. One could support up to 5 Unmanned
Aircraft, each using three video channels, in the ISM band at 5.8 GHz.
return to top
|
BLOS bandwidth required for Unmanned Aircraft operations
|
In the Beyond-Line-Of-Sight situation, the Status Messages and the digitised
Tower, ATC_1 and ATC_2 data is send using a modem via a satellite link with a
GSM back-up link. Again, as in the LOS situation, we will
assume the use of an
efficient modulation scheme
, such as GMSK or QPSK to achieve a modulation efficiency in excess of 1
bit/s/Hz.
Again, as in the LOS case, one can support the Command and Control
communications (apart from the video data required at take-off and landing,
including emergency landing) for 80 Unmanned Aircraft per MHz of bandwidth.
However, in this BLOS case, the number of Unmanned Aircraft that need to be
supported are those that will fall within the antenna footprint of the
satellite.
For the video data transmission
via a satellite link, we have suggested the use of MPEG-2 video compression in
which a 720 x 480 pixel frame at a rate of 30 frames per second requires a bit
rate of about 4 Mbps. Again we assume the use of an efficient modulation scheme,
such as QPSK, GMSK or better, to achieve 1 b/s/Hz or better. This will allow
each MPEG-2 video channel to be squeezed into a 4 MHz band, including guard
band.
It is suggested that the amount of satellite bandwidth required for video data
transmission required during take-off and landing, including emergency landings,
is 4 + n x 4 MHz, where n = the number of Unmanned Aircraft taking off and
landing within the antenna footprint of the satellite.
return to top
|
Example of a UAS Status Message Syntax
|
Here is the message syntax used at Barnard Microsystems for the status message
transmitted at regular intervals from the Unmanned Aircraft to the Ground
Control Station via a GSM modem or satellite phone modem based
Beyond-Line-Of-Sight ("BLOS") communications link. See
comms BLOS
.
The compact binary implementation of this format is shown in the
Status Message
section.
-
The status message consists of a set of data blocks, each block beginning with
the BEGIN keyword SectionName, and ending with an END keyword.
-
The data items are listed between the BEGIN and END keywords.
|
BEGIN SectionName_01
MessageItem_01 ItemValue_01
MessageItem_02 ItemValue_02
END
|
-
A comment can be included after the exclamation mark.
-
A sub-section can be nested within a section, with the sub-section also starting
with a BEGIN SubSectionName and ending with an END keyword.
|
BEGIN SectionName_01
! comments can be added after an exclamation mark
MessageItem_01 ItemValue_01
BEGIN SubSectionName_02
MessageItem_03 ItemValue_03
MessageItem_04 ItemValue_04
MessageItem_05 ItemValue_05
END SubSectionName_02
MessageItem_02 ItemValue_02
END
|
-
Section names can be added, or omitted.
The main section names are as follows:
|
Header
|
Status message header
|
|
IMU
|
Inertial Measurement Unit information
|
|
FCU
|
Flight Control Unit parameters
|
|
Power
|
Power systems status
|
|
Warnings
|
Status of warnings: eg. wheels down,
|
|
Comms
|
communications systems status
|
|
Payload
|
payload status: will vary with payload(s) present
|
|
GPS
|
GPS NMEA codes for this interval (get one at least eveyr second)
|
|
Sense
|
Sense and Avoid system (if fitted) status
|
By way of example, here are some example sections. We start with the
HEADER Section.
|
BEGIN HEADER
time 16:35:23.100
date 20071114
ua_ID GB_BML_014_DeltaW
msg_num 133
END
|
The IMU Section
|
BEGIN IMU
gyro_x 23.105
gyro_y 13.243
gyro_z 12.596
accel_x 3.933
accel_y 0.022
accel_z 0.223
mag_x 15.877
mag_y 225.112
mag_z 8.254
inclin_y 1.989
inclin_z 3.850
temp 11.213
END
|
The GPS Section
|
BEGIN GPS
$GPRMC,143903.00,A,5112.31099,N,00158.66984,W,0.004,,151007,,,A*64
$GPVTG,,T,,M,0.004,N,0.007,K,A*20
$GPGGA,143903.00,5112.31099,N,00158.66984,W,1,07,1.21,136.0,M,48.2,M,,*41
$GPGSA,A,3,21,05,06,24,13,31,16,,,,,,1.90,1.21,1.47*0B
$GPGSV,3,1,09,21,46,150,41,05,10,118,37,06,61,070,49,07,,,47*45
$GPGSV,3,2,09,24,51,093,48,13,08,340,37,10,,,39,31,53,216,40*42
$GPGSV,3,3,09,16,42,293,47*4A
$GPGLL,5112.31099,N,00158.66984,W,143903.00,A,A*7B
$GPZDA,143903.00,15,10,2007,00,00*6A
END
|
The Aircraft Sense Section
|
BEGIN SENSE
BEGIN OBJECT
ObjectID 1
long 23:45:32.44
lat 3:45:32.44
bearing 121.2
altitude 2600
climb_rate 11.2
speed 344
END
BEGIN OBJECT
ObjectID 2
long 23:45:32.44
lat 3:45:32.44
bearing 121.2
altitude 1550
climb_rate 11.2
speed 344
END
END
|
return to top
Although a 9.6 kbps BLOS sat comms link is used, both the transmit and the
receive paths are divided into two equal data rate channels A and B, each
operating at 4.8 kbps. A 9.6 kbps duplex data link represents a small,
lightweight, relatively inexpensive solution for an always-ON satellite based
data link between the Unmanned Aircraft and a distant Ground Control Station.
This link is operational even when the Unmanned Aircraft is beyond the line of
sight of staff at the GCS.
The backup system is a GSM modem based system, but this fails in areas where
there is no GSM coverage, or very weak GSM coverage, such as over oceans and in
remote parts of the earth.
We send a status message from the UA to the GCS every second, corresponding to
the GPS data update rate. The transmitted message size is 4,800 bits. The status
message data is Forward Error Correction encoded using the standard Reed Solomon
RS(255,223) format, in which 223 bytes of message data are supplimented with 32
bytes of FEC information to make up a 255 byte data block. We can fit 2 such
data blocks in our 4,800 bit maximum message size, with 720 bits to spare. The
720 bits = 90 Bytes are used for the Payload status information, since this
information is not considered "mission critical". This payload information
section included a 4 Byte checksum, but is not FEC encoded to enable the
detection of a transmission error in this section, but not the correction of any
errors.
A typical message length in plain text form, as shown above, is 3,600 text
characters, where each character is represented by a Byte. This message size
dramatically exceeds our above mentioned limit. In order to compress the
information, we use a binary format. For a small Unmanned Aircraft, the status
message consists of:
-
two blocks of 223 Bytes of binary data each. Each block is then FEC encoded
using RS(255,223) to become 255 Bytes in size.
-
we can transmit important information in each message (such as GPS location,
bearing), with other information (such as battery voltage), being reported less
frequently. To ensure correct interpretation of the different message data set
formats, we identify a Data_Set_ID in the header of each message.
-
each data item starts with a one byte Status_Item_ID (= B0) followed by the
Status_Item_Value, which can be 8 bits (B1), 16 bits (B1:B2), 24 bits (B1:B2:B3)
or 32 bits (B1:B2:B3:B4) in length.
-
a maximum of 256 types of Status_Item_ID
-
Byte numbering is as follows:
B0:B1:B2:B3:B4
See the
Status Message
section for the binary message syntax, and details on the message size.
return to top
Overview
This section outlines the mall Unmanned Aircraft
Message Syntax
|
Small UA Message Syntax
|
|
All times shall be represented in Universal Time Coordinated (UTC) in seconds
since Jan 1, 1970 using IEEE UNSIGNED INTEGERs
|
|
All angular parameters shall be expressed in degrees.
|
|
BLOCK 0 size = 90 Bytes
BLOCK 1 size = 255 Bytes after FEC coding
BLOCK 2 size = 255 Bytes after FEC coding
To be compatible with STANAG 4586, we transmit the Status Message in two
datagrams:
Part 1 = Block 0 = 90 Bytes
Part 2 = BLOCK 1 + BLOCK 2 = 510 Bytes
Both datagrams are < 524 Bytes.
|
|
BLOCK 0 has a 4 Byte Unsigned INT checksum
BLOCK 1 is FEC encoded using RS(255,223)
BLOCK 2 is FEC encoded using RS(255,223)
|
|
No coverage of weapon systems
|
|
We use the International Telephone Dialling Code for the country code. Every
country in the world has a unique Telephone Dialling code number. The largest
number is 1929 (the North American Numbering Plan) for Puerto Rico.
|
return to top
Here is an example from the Paparazzi Project, from 1033_paparazzi.pdf. Note the
use of the XML Format.
return to top
|
