# For a typical dual controller + companion computer UAS, is it normal to have UART only from controller, and USB only from companion computer?

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?

– ifconfig
Aug 19 at 15:30
• 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) Aug 19 at 15:36
• 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
Aug 20 at 18:23
• 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
Aug 21 at 1:46
• Yeah. Or: the necessity is lightweight enough to be handled within the controller. But things will change Aug 21 at 1:49

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.

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.

• 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 Aug 26 at 19:01
• 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. Aug 26 at 20:59
• Hmmm, maybe I missed something in the manual of those legged robots? Let me double check Aug 26 at 22:32