===== Communication, Remote Control and Autonomous Flights ===== A general idea of a UAV is to move in 3D airspace. It can be manually controlled via remote, usually a human operator, or an autonomous flight with various autonomy levels.\\ According to the Drone Industry Insights (2019. [[https://dronelife.com/2019/03/11/droneii-tech-talk-unraveling-5-levels-of-drone-autonomy/]]), there are 6 levels of drone operations autonomy, as we presented in the introductory chapters on autonomous flying and ground vehicles. Regardless of the autonomy level, communication between UGV and UAV ecosystems are crucial for the reliability, durability and safety of the operations. For the performance, in case of the cutting edge cases like drone racing or collision avoidance. In the following chapters, we present various aspects and communication protocols used in drones. ==== UAV Communication ==== UAV ecosystem uses many levels of communication protocols. Starting from on-board communication between systems, through aerial-to-aerial and aerial-to-ground, finishing on satellite communication. Communication in UAV operations is essential to its safety, reliability and performance. Here we discuss the most popular communication protocols used in drones (Figure {{ref>UAVcommunication}}).
{{ :en:drones:screenshot_from_2020-07-12_17-10-20.png?400 |}} UAV communication general schematics
=== On-board protocols === On-board communication protocols are used to exchange communication between the drone components, usually flight controller (FC), sensors and actuators. Those protocols are commonly known and shared with UGVs and IoT world, so we just briefly present their list here without in-depth review.\\ Actuators are specific for drones; however, we discuss them in the following sub-chapter in-depth, along with remote control protocols (RC protocols).\\ The most common on-board, low-level communication interfaces and protocols are: * I2C, * SPI, * Serial/UART (COM), * CAN (not so common), * One-wire (rare). The exact protocol use is usually driven by the set of sensors and components present onboard the UAV. Flight controller sometimes exposes a set of dedicated ports (connectors), sometimes they are universal plugs that can be used as configured in the FC configuration.\\ In many cases, an elementary set of sensors is integrated with the FC, Additionally, for GPS positioning, the NMEA protocol is frequently used. === Remote Control and Actuators Communication Protocols === Remote Control is an essential part of drones. While there do are fully automatic systems that take off, implement the mission and then land 100% automatically, in any case, there is a backup solution using manual operation such as RC control. Additionally, following mission progress and current system conditions is essential; thus, telemetry is a natural part for all flying objects, whether they perform autonomous or remote-controlled flight at the moment. As from the beginning, RC was used to control actuators directly (usually control surfaces), so actuators communication protocols were and still are an essential part of the onboard communication. In Figure {{ref>rccommunication}} we present a list of protocols and their assignment to the sections of the control sequence.
{{ :en:drones:communication.png?600 |}} RC communication protocols
Regarding colours used in Figure {{ref>rccommunication}}, blue corresponds to the //RC Radio Protocols// section, green to the //RC Onboard Protocols// section, the //Telemetry// section applies to green and blue, while red corresponds to the //Actuators// section, as presented below. == RC Radio Protocols == Remote control units communicate over FM radio one or bidirectional way, from the Ground Station/Controller to the aerial unit, referred to as a Receiver, even if nowadays links are bi-directional and both parties play the role of transmitter and receiver. On the physical level, we distinguish "analogue" RC that is (or rather "was", as it is rare to find users now) operating on 27MHz and 25MHz bandwidth. This kind of communication couldn't share radio bandwidth, so every pair (transmitter+receiver) sharing the same radio space needed to use a slightly different frequency, not to interfere. Transmitter and Receiver had both exchangeable oscillators, and it was pretty common; operators sharing common space had first to agree, who is using which frequency. That was rather uncomfortable in use. For those reasons, the analogue transmission is mostly abandoned now, even if its great advantage was a long communication range, virtually up to the horizon. The Digital era brought the use of 2.4 and 5.8 GHz open frequencies. As transmitters and receivers became more complex, computerized and smart, many protocols introduced "channel" hopping, changing their frequency actively during operation once the interference has been detected. Radio communication between Transmitter and Receiver is mostly manufacturer dependent, but the following ones are most common: * DSM family by Spectrum. Spectrum is considered to be a highly reliable radio manufacturer: * DSMX - latest of "DSMs", also available as cheaper hardware from Orange manufacturer. DSMX is a new version of DSM2 and is backwards compatible: DSMX Transmitter can handle DSM2 Receiver. DSMX uses up to 60 channels. * DSM2 - also by Spectrum, uses two frequencies to transmit data. * DSSS - a single channel, rather old technology by Spectrum. Channel is selected and fixed during whole transmission, opposite to the FHSS model (see remark below). * ACCESS / FRSKY by FrSky RC, bringing, i.e. automated re-binding and up to 24 channels. * FAAST by Futaba - 18 / 14 / 12 channel ones (18 channel is 16 linear + 2 binary), 12 channel is fastest one with legendary reliability. * FHSS and S-FHSS - new frequency-hopping spread spectrum protocol by Futaba, replacing FAAST. * A-FHSS by HiTEC - similar to other manufacturers, another spread spectrum frequency hopping technology. * AFHDS and AFHDS2 by FlySky - another RC protocol, the second one offers telemetry (bi-directional). Pretty popular due to the cheap hardware. * HiSky protocol - used in popular WL Toys. * DEVO - used in Walkera products (former are WK2401/2601/2801 currently abandoned). FHSS (Frequency-Hopping Spread Spectrum) - in short, it is a technology that pseudorandomly changes transmission radio frequency over the available spectrum (the sequence is known to both Transmitter and Receiver). == RC Onboard Protocols == Most popular RC protocols, once decoded by the RF, connecting Receiver and Flight Controller include: * PWM (Pulse Width Modulation) historically that is the most popular protocol and still a kind of backwards compatible "backup" that most devices can still "understand" - the major disadvantage is, every channel requires separate wiring. Hence, it is not suitable for miniature drones. * PPM (Pulse Position Modulation), also referred to as CPPM - similar to PWM, but it is not the duty cycle (as in PWM) but "distance" of the fixed pulse from the ticks defined by the clock signal; As classical PWM pulse takes between 1ms and 2ms max, and the 50Hz frame gives us 20ms, it is (theoretically) possible to send up to 10 channels, ordered. This is limited as the frame itself also requires some "space" between pulses. This way, PPM "queues" channels and send information about more than one in single wiring, one after another. Thanks to it, there is only one data wire necessary to connect the Receiver and FC. PPM has 250 distinguishable values resolution and about 4ms jitter. * PCM (Pulse Code Modulation) - similar to PPM but fully digital transmission (binary), can detect errors. * Serial protocols that include (among others): * SBUS - in general, it is an inverted UART signal. Used mostly in Futaba and FrSky Receivers. Up to 18 channels. Some FCs struggle to invert UART (i.e. STM32F4 lacks inverters on GPIO inputs), so implementation requires external hardware to invert it back to standard UART signal. * IBUS - as SBUS, but plain, can be connected and decoded to any UART (used in FlySky Receivers). Two-way communication, one channel for actuators, the other for sensors (telemetry). * XBUS - serial implementation by JR, up to 14 channels. * MSP (Multiwii Serial Protocol) - a standard for communicating with FCs, allows you to "inject" RC commands from, i.e. ground station software. MPS is available as software libraries and present in many ground station implementations, both open source and commercial. * Crossfire - recent protocol by TBS, also similar to SBUS but includes telemetry. * SUMH and SUMD - serial, digital protocol by Graupner. * FPort - a collaborative work of FrSky and Betaflight (FC firmware) developers to bring one-wire, bidirectional communication between Receiver and FC. == Telemetry == Telemetry is all about informing the operator on the current UAV and mission status. For this reason, FC, and eventually Receiver, collects data from sensors and send it back via downlink to the Ground Station Controller/Transmitter. As mentioned above, telemetry protocols on the local level correspond with Receiver-to-FC communication (if the protocol supports it). Still, if the specific protocol does not contain bi-directional communication nor telemetry, sensors are eventually connected to the separate port (usually another UART) in the Receiver. It is the Receiver's duty to collect it and send it to the Transmitter. Nowadays, most FCs can connect external sensors and Receiver-to-FC protocols used are those bi-directional ones. Telemetry data can be sent directly via the bi-directional RC link on the radio communication level, so they mostly use 2.4GHz transmission. Eventually, it can be sent with a separate downlink, parallel to the RC link, using dedicated Transmitter-Receiver pair (note, here Transmitter is in the drone, Receiver in the ground station). In most cases, it is a UART over the radio, operating on publically available frequencies, mostly 433MHz and 868MHz/915MHz. Note, those frequencies vary by geographical region: while 433MHz is a worldwide standard, 915MHz is used in part of Asia and the US/Canada, while forbidden in the EU. On the opposite, 868MHz is common in Europe but forbidden in the US. Be careful when ordering modules. == Actuator protocols == It is a set of protocols that drive servomotors and Electronic Speed Controllers (thus indirectly, motors). So far, in the case of the majority of servos, there is just one solution, old fashioned PWM signal. In the case of ESCs, it is not so straightforward as modern ESCs are programmable and deliver feedback on motor rotation; thus, most modern ones use bidirectional communication between ESC and FC. ESC protocols are sometimes referred to as "motor protocols". The ESC protocol's main purpose is to "tell" the ESC how fast to spin the motor. == ESC Protocols == Those are protocols that indirectly drive motors. In the miniature brushed motors and early RC ESCs for brushless motors, FC was using PWM signal, as in servos. It is no longer a case, as ESCs are using microcontrollers and their features are programmable. Modern ESCs deliver backwards to the FC information about motor status, temperature, configuration settings and so on, so requires complex protocols, bi-directional. Here we present a list of the most popular ESC protocols: * Analogue (pulse length based) protocols include: * PWM - as mentioned above, historical, still operating. Many ESCs can use it as a fallback if there is an advanced protocol's incompatibility between ESC and FC. It is worth mentioning that there are actually two PWM ESC protocols: * Analogue PWM, where 0% duty cycle is equivalent to motor stop, and 100% is equivalent to full throttle; * Standard PWM (as in servos), where 1ms duty cycle is motor stop and 2ms if full throttle. However, differently as in servos, the motor requires faster updates, so the PWM frequency is usually much higher than the servo's 50Hz standard. As 2ms is "full throttle", the maximum possible PWM frequency is 500Hz. * OneShot family: OneShot125 and OneShot42 - for OneShot125, the pulse length is between 125 and 250 microseconds; thus, the maximum frequency is 4KHz; for OneShot42, the pulse is 42 microseconds, so it is 12KHz maximum frequency * MultiShot - it is 32kHz operating one, 10x faster than OneShot125. It is the fastest one in the family, but there are not so many ESC capable of handling it. * Digital, binary protocols: * DShot family: DShot150/300/600/1200 - a family of digital protocols with 150Kbps (DShot150) to 1200Kbps (DShot1200) transmission speeds, respectively to the protocol variant. They use 4bit CRC to check communication for any errors that may appear, i.e. due to electromagnetic interference. * ProtoShot - an approach to integrate both digital (as i.e. in DShot150) and analogue (OneShot) protocols, all in one. Use of analogue protocols requires throttle calibration (setting motors not to spin at all and spin with their maximum RPM). Digital protocols do not require throttle calibration. == Servos == Servos are connected with 3 cables, power (+/-) and control. PWM frequency is constant, but it is the duty cycle that controls the servo rotation. Analogue (classical) servos use a 50Hz PWM frequency. Modern, digital servos use 300Hz and up.\\ As digital servos are still not very popular, here we describe analogue servos' control principles. Analogue servo uses PWM standard frequency that is 50Hz, so the period is 20ms. A 0-degree rotation angle is equivalent to the 1ms high/19ms low digital control signal duty cycle, while 180 degrees is for a 2ms duty cycle. Naturally, this scale tends to be linear, so 90 degree is equivalent to 1.5ms: see figure {{ref>servodutycycle}} for graphical representation of the control signal.
{{ :en:drones:platforms:standardservopwm.png?600 |}} Standard servo duty cycle explained
As one can see from the above, the most common case is a servo operating in the 0..180 degrees range. Servos with other rotation range may use different duty cycles. === Video === Here we consider a video downlink. Regarding technology, we distinguish two types: * analogue transmission, * digital transmission. Even if it seems to be obsolete, the analogue transmission has a great feature that is zero (or close to zero) latency. This is important in FPV racing and applications that require immediate response, close to realtime. This kind of video encoding is one of the old fashioned analogue TV, PAL and NTSC standards. Encoded video stream is sent via open radio frequencies, most commonly using 5.8 GHz. The standard resolution is 576 lines for PAL and 480 lines for NTSC, both interlaced. The digital video transmission in amateur and semi-professional solutions include video encoded with one of the popular "computer" codecs, MPEG, H.264 and recently H.265. The majority of solutions transmit the digital video stream via WiFi connection, usually using UDP protocol. For this reason, the range is limited and strongly affected by nearby WiFi environment, i.e. access points. The transmission frequencies are 2.4GHz and 5.8GHz. Resolution is up to 720p, but recent encoding advances present the ability to deliver 1080p to the ground station. As in most cases, the device used to display the image is just a mobile phone; it is unnecessary to transmit a high-resolution stream, record it locally in the drone and then download it once the mission is finished. There are multi-channel, professional downlink solutions available, like, i.e. DJI Lightbridge, obviously with a high price in case of the advanced semi-professional cinematography. Professional, high-grade solutions for live broadcasting from the sky use DCI transmitters to deliver stable 4k video directly from the sky. Still, those are available for extreme prices and limited in use for large drones only, as this kind of link consumes a huge amount of energy. === Other Communication Protocols === Many communication protocols are shared with IoT, computer networks, the automotive industry, UGV, airborne systems and even the space industry. Here we focus shortly on those used in drones or are on their way to be used in the nearest future. === Satellite communication protocols === Obviously, satellite communication protocols are frequently used in terms of drone (and operator) positioning. While it is possible to receive raw satellite signals over the radio and use it to decode the signal and obtain a lon/lat position using the triangulation method (see the chapter on navigation for more details), it is common to rather use ready GNSS (also referenced as GPS) receiver module, that communicates to the flight controller or other device, providing 2D/3D position (3D includes altitude), positioning accuracy, number of satellites in view (it directly impacts positioning quality) and so on. Manual decoding requires a huge amount of resources, thus is implemented with integrated circuits. Here we focus on communication between an FC and GNSS receiver rather than between satellites and receiver.\\ GNSS modules use textual and binary communication, depending on the particular receiver chip and PCB board design. In particular, most GNSS receivers can deliver information using the NMEA protocol that is a standard communication protocol at the moment, usually in a textual form over the serial connection (the most common is 9600 bps). At the moment, a binary communication protocol is being introduced as more efficient and simply delivering position data much faster, yet it is still a niche solution.\\ Sample NMEA data for Tallinn/Estonia Old City Central Market square is present below:\\ ''$GPGGA,095531.290,5926.238,N,02444.715,E,1,12,1.0,0.0,M,0.0,M,,*6A''\\ ''$GPGSA,A,3,01,02,03,04,05,06,07,08,09,10,11,12,1.0,1.0,1.0*30''\\ ''$GPRMC,095531.290,A,5926.238,N,02444.715,E,,,100920,000.0,W*74''\\ Receivers are free to use (you do not need to purchase any licence/contract), and they're able to position using multiple satellite constellations.\\ Obviously, there are additional services(i.e. improved quality on positioning) that are charged for use, and it may be reasonable to use them in some scenarios.\\ Additionally to the satellite communication, there is also aerial and satellite communication that provides additional live data, i.e. related to the correction of the impact of the current state of the ionosphere, ephemeris, and other factors causing incorrect and inaccurate positioning. Those are handled by GNSS receivers and too complex to provide them here, but please note, they constitute an important factor in the quality of the drone positioning and is essential to the precise and secure operations and their performance in most scenarios. === ADS-B === ADS-B (Automatic dependent surveillance-broadcast) is an airborne protocol that drones barely use now, but that is changing over time. Each commercial aircraft broadcasts information about its current position, velocity, direction, and so on that can be received using special modules or even out of tuned DVB-T receiver (USB TV stick). ADS-B can be freely received and decoded, but it is forbidden to broadcast it without permission and licence. Communication uses a 1090 MHz band.\\ It is free to receive ADS-B, but it is forbidden to broadcast ADS-B. Broadcasting requires certified equipment and is done concerning flight control and flight information services! The simplicity of reception of the signal caused open-source implementations and the rise of flight information services like, i.e. very popular FlightRadar24 that directly benefit from ADS-B reception via distributed receiver network operated by amateurs.\\ Theoretically, ADS-B can be used to implement a collision-avoidance system once FC is aware of other aircraft in its nearby area.