<p><strong>Short Answer</strong></p>
<p>There are several different <em>protocols</em> that have different uses and different limitations. The ones mentioned that have a name like <code>SER</code> and description of <em>UART</em> are built into most controllers. Things like <code>CAN</code> and  <code>USB</code> are a bit more modern and <code>USB</code> replaces <code>SER</code> on modern computers. These last two may or may not be built into a controller.</p>
<p><strong>Long Answer</strong></p>
<p>The <code>SER</code> is an RS-232-<em>like</em> protocol that uses one wire for Transmit and one wire for Receive. It is one of the simplest protocols and has been around since about 1960. It is intended to connect two and <em>only</em> two devices together (semi-permanently) and has a lower speed than most other protocols. There is some configuration required on both devices to enable communication.</p>
<p>The <code>USB</code> protocol came out in the late 1990's to overcome some of the limitations of <code>SER</code>. It still has two wires but they are both used at the same time for transmit and receive. The protocol <em>self configures</em> so the user does not need to make any setting changes. The speed is much higher and up to 127 devices can talk on the same bus. This has replaced the <code>SER</code> on all modern computers and is the standard for most tables, phones, etc.</p>
<p><code>CAN</code> also came out in the 1990's but was used almost exclusively for automotive purposes. It is somewhat similar to <code>USB</code>, but does not require a <em>host</em> computer to oversee communications. It can work at a higher voltage and is a little less susceptible to noise than <code>USB</code>. It also can have many devices sharing one bus.</p>
<p><strong>UAS Usage</strong></p>
<p>A controller is limited to (usually) 1-3 serial ports. This means it can only talk to a few things. The <code>SER</code> is generally used for things like Telemetry / Data collection.</p>
<p>The <code>CAN</code> is used for <em>add-on</em> sensors like GPS and safety devices that keep the Drone flying / moving.</p>
<p>The <code>USB</code> is used to connect the controller to the companion computer for things like software updates, data transfer, etc.</p>
<p>Each one has a particular use that leverages the strengths of the protocol.</p>

CC BY-SA 4.0
2021-08-26T19:01:04.963Z
I'm not sure about the "has a lower speed than most other protocols" part, it is still used pervasively in legged robots.

Or maybe it doesn't matter as much as latency
tribbloid
CC BY-SA 4.0
2021-08-26T20:59:27.113Z
Serial / RS-232 is a great protocol and used in many places. The 'standard' (whatever that is) maximum is generally considered to be 115.2kBit/s. Admittedly there are some that go up into the MBit/s region. USB is about 480MBit/s to 10GBit/s depending on version.
Kevin
CC BY-SA 4.0
2021-08-26T22:32:25.400Z
Hmmm, maybe I missed something in the manual of those legged robots? Let me double check
tribbloid
CC BY-SA 4.0
2021-08-25T14:08:48.537Z
2021-08-25T14:08:48.537Z
Kevin
<p>When I'm reading the extension capability of 3DR Solo, I realise that its breakout board interface has some peculiar limitation.</p>
<p>Here is the context of the entire 3DR Solo design: it is an open-source, fully extendable quad that doesn't stand out as a consumer flying camera, yet became popular within researchers and developers (it is still popular). And typically serve as the reference board for an open source UAV system.</p>
<p>It has 2 computers: a controller and a companion computer:</p>
<ul>
<li><p>controller:</p>
<ul>
<li>pixhawk 2.x</li>
<li>running ardupilot 4.x, on ChibiOS</li>
<li>low latency control</li>
</ul>
</li>
<li><p>companion computer</p>
<ul>
<li>freescale iMX.6</li>
<li>running a custom yocto poky linux distro</li>
<li>high latency, complex, high level processing</li>
</ul>
</li>
</ul>
<p>According to <a href="https://3drobotics.github.io/solodevguide/hardware-accessorybay.html" rel="noreferrer">this doc</a>, here are all the UART and CAN interfaces:</p>
<pre><code>9.  SER5 TX (DEBUG) UART5 TX output from Pixhawk™ 2.
10. SER2RT  UART2 RTS output from Pixhawk™ 2 for flow control. Connect to device's CTS pin.
11. SER2Tx  UART3 RX signal to Pixhawk™ 2. Connect to device's TX pin. Voltage is 3.3V.
24. SER5 RX (DEBUG) UART5 RX input to Pixhawk™ 2.
25. SER2CT  UART2 CTS input to Pixhawk™ 2 for flow control. Connect to device's RTS pin.
26. SER2Rx  UART3 TX signal from Pixhawk™ 2. Connect to device RX pin. Voltage is 3.3V.
12. CANH1   CAN bus high to the Pixhawk™ 2.
13. CANL1   CAN bus low to the Pixhawk™ 2.
</code></pre>
<p>Here are all the USB interfaces:</p>
<pre><code>1.  USB D-  Negative differential data signal to iMX6 OTG USB port.
2.  USB D+  Positive differential data signal to iMX6 OTG USB port.
</code></pre>
<p>In short, all UART &amp; CAN are from controller, and all USB are from companion computer.</p>
<p>I wonder what the purpose of this design is (and other similar designs in UAV)? Assuming that if I need to add another low-latency robotic part, do I have to route it through pixhawk or USB?</p>

CC BY-SA 4.0
2021-08-19T15:30:04.500Z
Oh, cool! Are you asking about why the used communication protocols were likely chosen or are you asking about the general paradigm of tiered computer systems for controls/vision tasks?
ifconfig
CC BY-SA 4.0
2021-08-19T15:36:27.073Z
nice ID :) Did you write it?
I'm more concern about the general paradigm, but more for payload actuators (e.g. mechanic arms with UART interface), not for vision (for which the UAS chose HDMI)
tribbloid
CC BY-SA 4.0
2021-08-20T18:23:35.840Z
Well, I'm not entirely sure what you're referring to, but this structure of systems using dedicated microcontrollers to deal with digital/analog peripherals over specialized protocols like I2C, SPI, UART, CAN, etc. is very common because few complex computers with a lot of processing power to run complicated controllers have the ability to interface with those protocols directly.
ifconfig
CC BY-SA 4.0
2021-08-20T18:34:13.780Z
My question pops up when reading the architecture of a legged robot (unitree A1), which, due to the complexity of actuation, relies on UART between controller and companion computer. I'm just curious why UAS didn't use the same design, if it will gradually become equally complex
tribbloid
CC BY-SA 4.0
2021-08-21T01:46:46.920Z
Well, the choice to use different protocols is usually a case-by-case decision, so it's really hard to say. But a significant potential reason is that UART is better suited to a non-flying robot where there is less necessity to be extremely quickly reacting to things.
ifconfig
CC BY-SA 4.0
2021-08-21T01:49:31.720Z
Yeah. Or: the necessity is lightweight enough to be handled within the controller. But things will change
tribbloid
<flight-controller><compatibility><ardupilot><mission-computer><uart>
For a typical dual controller + companion computer UAS, is it normal to have UART only from controller, and USB only from companion computer?
tribbloid
# For a typical dual controller + companion computer UAS, is it normal to have UART only from controller, and USB only from companion computer?

(Asked by: username_0 on 2021-08-18)

When I'm reading the extension capability of 3DR Solo, I realise that its breakout board interface has some peculiar limitation.
Here is the context of the entire 3DR Solo design: it is an open-source, fully extendable quad that doesn't stand out as a consumer flying camera, yet became popular within researchers and developers (it is still popular). And typically serve as the reference board for an open source UAV system.
It has 2 computers: a controller and a companion computer:

controller:

pixhawk 2.x
running ardupilot 4.x, on ChibiOS
low latency control


companion computer

freescale iMX.6
running a custom yocto poky linux distro
high latency, complex, high level processing



According to this doc, here are all the UART and CAN interfaces:
9.  SER5 TX (DEBUG) UART5 TX output from Pixhawk™ 2.
10. SER2RT  UART2 RTS output from Pixhawk™ 2 for flow control. Connect to device's CTS pin.
11. SER2Tx  UART3 RX signal to Pixhawk™ 2. Connect to device's TX pin. Voltage is 3.3V.
24. SER5 RX (DEBUG) UART5 RX input to Pixhawk™ 2.
25. SER2CT  UART2 CTS input to Pixhawk™ 2 for flow control. Connect to device's RTS pin.
26. SER2Rx  UART3 TX signal from Pixhawk™ 2. Connect to device RX pin. Voltage is 3.3V.
12. CANH1   CAN bus high to the Pixhawk™ 2.
13. CANL1   CAN bus low to the Pixhawk™ 2.

Here are all the USB interfaces:
1.  USB D-  Negative differential data signal to iMX6 OTG USB port.
2.  USB D+  Positive differential data signal to iMX6 OTG USB port.

In short, all UART & CAN are from controller, and all USB are from companion computer.
I wonder what the purpose of this design is (and other similar designs in UAV)? Assuming that if I need to add another low-latency robotic part, do I have to route it through pixhawk or USB?

**Tags:** flight-controller, compatibility, ardupilot, mission-computer, uart
> **Comments:**
> **username_1**: Oh, cool! Are you asking about why the used communication protocols were likely chosen or are you asking about the general paradigm of tiered computer systems for controls/vision tasks?  
> **username_0**: nice ID :) Did you write it? I'm more concern about the general paradigm, but more for payload actuators (e.g. mechanic arms with UART interface), not for vision (for which the UAS chose HDMI)  
> **username_1**: Well, I'm not entirely sure what you're referring to, but this structure of systems using dedicated microcontrollers to deal with digital/analog peripherals over specialized protocols like I2C, SPI, UART, CAN, etc. is very common because few complex computers with a lot of processing power to run complicated controllers have the ability to interface with those protocols directly.  
> **username_0**: My question pops up when reading the architecture of a legged robot (unitree A1), which, due to the complexity of actuation, relies on UART between controller and companion computer. I'm just curious why UAS didn't use the same design, if it will gradually become equally complex  
> **username_1**: Well, the choice to use different protocols is usually a case-by-case decision, so it's really hard to say. But a significant potential reason is that UART is better suited to a non-flying robot where there is less necessity to be extremely quickly reacting to things.  
> **username_0**: Yeah. Or: the necessity is lightweight enough to be handled within the controller. But things will change  

---

## 1 answers

### Answer by username_2 on 2021-08-25. Score: 3 | Accepted answer

**Short Answer**

There are several different *protocols* that have different uses and different limitations. The ones mentioned that have a name like `SER` and description of *UART* are built into most controllers. Things like `CAN` and `USB` are a bit more modern and `USB` replaces `SER` on modern computers. These last two may or may not be built into a controller.

**Long Answer**

The `SER` is an RS-232-*like* protocol that uses one wire for Transmit and one wire for Receive. It is one of the simplest protocols and has been around since about 1960. It is intended to connect two and *only* two devices together (semi-permanently) and has a lower speed than most other protocols. There is some configuration required on both devices to enable communication.

The `USB` protocol came out in the late 1990's to overcome some of the limitations of `SER`. It still has two wires but they are both used at the same time for transmit and receive. The protocol *self configures* so the user does not need to make any setting changes. The speed is much higher and up to 127 devices can talk on the same bus. This has replaced the `SER` on all modern computers and is the standard for most tables, phones, etc.

`CAN` also came out in the 1990's but was used almost exclusively for automotive purposes. It is somewhat similar to `USB`, but does not require a *host* computer to oversee communications. It can work at a higher voltage and is a little less susceptible to noise than `USB`. It also can have many devices sharing one bus.

**UAS Usage**

A controller is limited to (usually) 1-3 serial ports. This means it can only talk to a few things. The `SER` is generally used for things like Telemetry / Data collection.

The `CAN` is used for *add-on* sensors like GPS and safety devices that keep the Drone flying / moving.

The `USB` is used to connect the controller to the companion computer for things like software updates, data transfer, etc.

Each one has a particular use that leverages the strengths of the protocol.

> **Comments:**
> **username_0**: I'm not sure about the "has a lower speed than most other protocols" part, it is still used pervasively in legged robots.  Or maybe it doesn't matter as much as latency  
> **username_2**: Serial / RS-232 is a great protocol and used in many places. The 'standard' (whatever that is) maximum is generally considered to be 115.2kBit/s. Admittedly there are some that go up into the MBit/s region. USB is about 480MBit/s to 10GBit/s depending on version.  
> **username_0**: Hmmm, maybe I missed something in the manual of those legged robots? Let me double check  

---

