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'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

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?