Stretching an unmanned vehicle’s Command and Control (C2) communication beyond visual line of sight (BVLOS) not only subjects it to strict regulations, particularly aviation regulations, but it also presents significant technical challenges. Let’s identify and discuss some of them here.
C1½
A typical C2 system used in small unmanned vehicles relies on:
- seeing the vehicle visually and controlling it using a one-way RC comm link assisted by the vehicle’s autopilot; and
- using a two-way radio-telemetry command comm link between the ground control station (GCS) and the vehicle.
For such systems, losing the visual line of sight means not only losing actual sight of the vehicle but also losing the control and command comm links. Further, BVLOS does not necessarily mean beyond the horizon—it also could be just around the corner.
As stated in Stretching Comm Links: From Indoors to the Globe, if your autonomous vehicle needs to go BVLOS and stay connected, it will need to use some sort of re-transmitter, like cell towers or communication satellites. Unfortunately, public cellular and satellite communication services rely on shared public computer networks that do not provide hard real-time guarantees. Network latency varies depending on signal quality, utilization of the network, routing, etc.
Dropping hard real-time requirements for comm links changes the requirements for command comm links and implies autonomy - trusting the autopilot with control of the vehicle (which is a pretty hard requirement). Control comm links must be real-time to prevent random delays between moving the RC stick and turning the rudder, while command comm links do not require real-time guarantees if the autopilot can safely operate the vehicle in all situations and can reject any received commands when they cannot be executed safely.
The Protocol
Real-time guarantees set significant constraints on communication protocols. In particular, message sizes must be limited to allow for both transmission and processing (which must be non-blocking and time-bound) within a limited timeframe. In the real-time MAVLink serial protocol, for example, the message size is limited to 263 bytes. This limit makes the MAVLink very “chatty”, meaning:
- When a Ground Control Station (GCS) connects to an autopilot, the autopilot sends 1000+ on-board parameters to GCS sequentially using separate messages for each parameter. (UPDATE: The new ftp parameter stuff no longer requires transmitting parameters one by one upon vehicle connection.)
- The GCS sends mission items to the autopilot sequentially using separate messages for each mission item.
- The vehicle status is reported to the GCS using multiple separate messages of different types.
This chatty communication does not pair well with high-latency channels. For example, if the channel latency is 240 milliseconds (geostationary satellite round-trip time), then sending a sequence of 1000+ messages would require 240+ seconds. Additionally, separate transport protocol packets are required for each message, so the total packet size can be much larger than the total size of the message payloads. Chattiness also affects the protocol reliability, as it’s hard to ensure reliable delivery of a long sequence of messages.
In addition, MAVLink has no concept of a request and response. The sending and receiving serial streams are not blocked by each other. In particular, the command ACK message is linked to the command message only by time, meaning the ACK message must be received within a certain period of time after the command has been sent.
The existing MAVLink specification does not work well if the real-time guarantees are taken away. Using MAVLink messages without real-time guarantees requires defining a non-real-time MAVLink profile. Specifically, the MAVLink profile should:
- Support sending/receiving multiple MAVLink messages in one request/response in order to send/receive all on-board parameters or all mission items simultaneously.
- Use a request–response pattern for command ACK messages.
One way to achieve this is to define a non-real time MAVLink profile on top of MQTT, HTTP, or WebSocket application layer protocols. (Support for request–response patterns was introduced in the MQTT 5 specification).
Strictly speaking, QGroundControl and Mission Planner are not real-time GCSs, because they are not supported on real-time operating systems. If we drop the real-time requirements for the autopilot-to-GCS comm link, then it makes sense to do it at the beginning of the link rather than at the end.
The System
Telemetry systems may use both real-time and non-real-time MAVLink profiles as well as custom protocols for internal communications.
The architecture of the BVLOS C2 telemetry system, which is based on public satellite and cellular communication services, would be much simpler if it were based on just the TCP/IP transport protocol. Unfortunately, satellite communication services are not quite there yet, so we have to deal with proprietary communication protocols such as Iridium Short Burst Data (ISBD). The ISBD protocol can only send and receive single MAVLink messages at a time because of its limited 270-byte message size, which is just enough to fit one MAVLink message. Also, in ISBD, both sending and receiving are done in one session, which makes it hard to implement an efficient request–response pattern.
The autopilot’s companion computer can be used as a bridge between the real-time autopilot and non-real-time comm channels. The companion computer, for example, can filter, compress and buffer the outgoing MAVLink messages received from the autopilot before sending them to the communication channels. Further, the companion computer can receive whole missions from the communication channel in one request and send the mission items sequentially to the autopilot one item at a time using the real-time serial MAVLink profile.
The telemetry system architecture should not be constrained by the limitations of the proprietary protocols because, eventually, the proprietary transport protocols will be replaced by TCP/IP based protocols such as MQTT.
The overall architecture of this type of system was also described in the IoT Hub for Unmanned Vehicles blog post.
Summary
Dropping real-time requirements for C2 comm links in MAVLink-based autopilots means:
- Trusting the autopilot with control of the vehicle;
- Using a non-real-time MAVLink profile defined on top of MQTT, HTTP, or WebSocket protocols to command the vehicle; and
- Using both real-time and non-real-time MAVLink profiles and custom protocols for internal communications.