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](https://3drobotics.github.io/solodevguide/hardware-accessorybay.html), 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's the purpose of this design (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?

Thanks a lot for your opinion