This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| en:drones:autonomous [2020/09/18 08:50] – [Remote Control and Actuators Communication Protocols] pczekalski | en:drones:autonomous [Unknown date] (current) – external edit (Unknown date) 127.0.0.1 | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ===== Communication, | ===== Communication, | ||
| - | A general idea of a UAV is to move in 3D airspace. It can be manually controlled via remote, usually, a human operator or it can be an autonomous flight with various levels | + | 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 |
| - | According to the Drone Industry Insights (2019. [[https:// | + | According to the Drone Industry Insights (2019. [[https:// |
| - | ^ Autonomy\\ Level | ||
| - | ^ Human\\ Contribution\\ to the Flight\\ Control | ||
| - | ^ Machine\\ (Drone Systems)\\ Contribution\\ to the Flight\\ Control | ||
| - | ^ Flight \\ Automation\\ Degree | ||
| - | ^ Remarks | ||
| - | ^ Environment\\ Interaction (i.e.\\ Collision \\ Avoidance) | ||
| - | + | ==== UAV Communication ==== | |
| - | ===== 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, | UAV ecosystem uses many levels of communication protocols. Starting from on-board communication between systems, through aerial-to-aerial and aerial-to-ground, | ||
| <figure UAVcommunication> | <figure UAVcommunication> | ||
| - | {{: | + | {{ : |
| < | < | ||
| </ | </ | ||
| - | ==== On-board protocols | + | === 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).\\ | + | 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: | The most common on-board, low-level communication interfaces and protocols are: | ||
| * I2C, | * I2C, | ||
| Line 28: | Line 21: | ||
| * CAN (not so common), | * CAN (not so common), | ||
| * One-wire (rare). | * One-wire (rare). | ||
| - | The exact protocol use is usually driven by the set of sensors and components, that are present | + | The exact protocol use is usually driven by the set of sensors and components present |
| - | Additionally, | + | Additionally, |
| - | ==== Remote Control and Actuators Communication Protocols | + | === 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, | + | 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, |
| - | 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 on-board | + | 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 |
| <figure rccommunication> | <figure rccommunication> | ||
| - | {{: | + | {{ : |
| < | < | ||
| </ | </ | ||
| Line 43: | Line 36: | ||
| Regarding colours used in Figure {{ref> | Regarding colours used in Figure {{ref> | ||
| - | === RC Radio Protocols | + | == RC Radio Protocols == |
| - | Remote control units communicate over FM radio one or bidirectional way, from the Ground Station/ | + | Remote control units communicate over FM radio one or bidirectional way, from the Ground Station/ |
| - | On the physical level, we distinguish " | + | On the physical level, we distinguish " |
| - | 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 " | + | 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 " |
| Radio communication between Transmitter and Receiver is mostly manufacturer dependent, but the following ones are most common: | Radio communication between Transmitter and Receiver is mostly manufacturer dependent, but the following ones are most common: | ||
| Line 55: | Line 48: | ||
| * DSM2 - also by Spectrum, uses two frequencies to transmit data. | * 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, | * DSSS - a single channel, rather old technology by Spectrum. Channel is selected and fixed during whole transmission, | ||
| - | * ACCESS / FRSKY by FrSky RC, bringing i.e. automated re-binding and up to 24 channels. | + | * 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. | * 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. | * FHSS and S-FHSS - new frequency-hopping spread spectrum protocol by Futaba, replacing FAAST. | ||
| Line 63: | Line 56: | ||
| * DEVO - used in Walkera products (former are WK2401/ | * DEVO - used in Walkera products (former are WK2401/ | ||
| - | <note tip>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).</ | + | <note tip>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 | + | == RC Onboard Protocols == |
| Most popular RC protocols, once decoded by the RF, connecting Receiver and Flight Controller include: | 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 " | + | * PWM (Pulse Width Modulation) historically that is the most popular protocol and still a kind of backwards compatible " |
| - | * PPM (Pulse Position Modulation), | + | * PPM (Pulse Position Modulation), |
| - | * PCM (Pulse Code Modulation) - similar to PPM but fully digital transmission (binary), | + | * PCM (Pulse Code Modulation) - similar to PPM but fully digital transmission (binary), |
| * Serial protocols that include (among others): | * Serial protocols that include (among others): | ||
| - | * SBUS - in general, it is inverted UART signal. Used mostly in Futaba and FrSky Receivers. Up to 18 channels. | + | * SBUS - in general, it is an inverted UART signal. Used mostly in Futaba and FrSky Receivers. Up to 18 channels. |
| - | * IBUS - as SBUS, but plain, can be connected and decoded to any UART (used in FlySky Receivers). Two-way communication, | + | * IBUS - as SBUS, but plain, can be connected and decoded to any UART (used in FlySky Receivers). Two-way communication, |
| * XBUS - serial implementation by JR, up to 14 channels. | * XBUS - serial implementation by JR, up to 14 channels. | ||
| - | * MSP (Multiwii Serial Protocol) - a standard for communicating with FCs, it allows you to " | + | * MSP (Multiwii Serial Protocol) - a standard for communicating with FCs, allows you to " |
| * Crossfire - recent protocol by TBS, also similar to SBUS but includes telemetry. | * Crossfire - recent protocol by TBS, also similar to SBUS but includes telemetry. | ||
| * SUMH and SUMD - serial, digital protocol by Graupner. | * 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. | * FPort - a collaborative work of FrSky and Betaflight (FC firmware) developers to bring one-wire, bidirectional communication between Receiver and FC. | ||
| - | === Telemetry | + | == Telemetry == |
| - | Telemetry is all about informing the operator on 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/ | + | 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/ |
| - | As mentioned above, telemetry protocols on local level correspond with Receiver-to-FC communication (if the protocol supports it), but 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 | + | 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' |
| - | Nowadays, most of FCs are capable of connecting | + | Nowadays, most FCs can connect |
| - | On the radio communication level, telemetry | + | Telemetry |
| - | <note important> | + | <note important> |
| - | === Actuators === | + | == 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" | + | 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" |
| == ESC Protocols == | == ESC Protocols == | ||
| - | Those are protocols that indirectly drive motors. In case of the miniature brushed motors and early RC ESCs for brushless motors, FC was simply | + | 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, |
| * Analogue (pulse length based) protocols include: | * Analogue (pulse length based) protocols include: | ||
| - | * PWM - as mentioned above, historical, still operating. Many ESCs can use it as a fallback | + | * PWM - as mentioned above, historical, still operating. Many ESCs can use it as a fallback |
| * Analogue PWM, where 0% duty cycle is equivalent to motor stop, and 100% is equivalent to full throttle; | * 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 servo' | + | * 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' |
| - | * OneShot family: OneShot125 and OneShot42 - for OneShot125, pulse length is between 125 and 250 microseconds, thus maximum frequency is 4KHz; for OneShot42, the pulse is 42 microseconds, | + | * OneShot family: OneShot125 and OneShot42 - for OneShot125, |
| - | * 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 | + | * 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 |
| * Digital, binary protocols: | * Digital, binary protocols: | ||
| - | * DShot family: DShot150/ | + | * DShot family: DShot150/ |
| * ProtoShot - an approach to integrate both digital (as i.e. in DShot150) and analogue (OneShot) protocols, all in one. | * ProtoShot - an approach to integrate both digital (as i.e. in DShot150) and analogue (OneShot) protocols, all in one. | ||
| Line 108: | Line 101: | ||
| == Servos == | == 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. | + | 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 50Hz PWM frequency. Modern, digital servos use 300Hz and up.\\ | + | 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' | + | As digital servos are still not very popular, here we describe analogue servos' |
| - | A 0-degree rotation angle is equivalent to the 1ms high/19ms low digital control signal duty cycle, while 180 degrees is for 2ms duty cycle. Naturally, this scale tends to be linear, so 90 degree is equivalent to 1.5ms: see figure {{ref> | + | 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> |
| <figure servodutycycle> | <figure servodutycycle> | ||
| - | {{: | + | {{ : |
| < | < | ||
| </ | </ | ||
| - | As one can see from the above, the most common case is a servo operating | + | As one can see from the above, the most common case is a servo operating |
| + | |||
| + | |||
| + | === 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, | ||
| - | ==== Video ==== | + | The digital video transmission in amateur and semi-professional solutions include video encoded with one of the popular " |
| - | ==== Other Communication Protocols | + | There are multi-channel, |
| + | === Other Communication Protocols === | ||
| - | Many communication protocols are shared with IoT, computer networks, automotive industry, UGV, airborne systems and even space industry. Here we focus shortly on those, that are used in drones or are on its way to be used in the nearest future. | + | Many communication protocols are shared with IoT, computer networks, |
| === Satellite communication protocols === | === Satellite communication protocols === | ||
| - | **Obviously, satellite communication protocols are one of the most frequently used, in terms of the drone (and operator) positioning.** | + | 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 triangulation method (see the chapter on navigation for more details) it is common to rather use ready GNSS (referenced | + | 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 |
| GNSS modules use textual and binary communication, | GNSS modules use textual and binary communication, | ||
| - | In particular, most GNSS receivers | + | In particular, most GNSS receivers |
| Sample NMEA data for Tallinn/ | Sample NMEA data for Tallinn/ | ||
| Line 138: | Line 140: | ||
| '' | '' | ||
| - | Receivers are free to use (you do not need to purchase any licence/ | + | Receivers are free to use (you do not need to purchase any licence/ |
| - | Additionally to the satellite communication, | + | Additionally to the satellite communication, |
| === ADS-B === | === ADS-B === | ||
| - | ADS-B (Automatic dependent surveillance-broadcast) is an airborne protocol that drones barely use at the moment, 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 1090 MHz band.\\ | + | 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.\\ |
| - | <note warning> | + | <note warning> |
| - | The simplicity of reception of the signal caused open-source implementations and 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.\\ | + | 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.\\ |
| - | <note tip> | + | <note tip> |