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:
- pixhawk 2.x
- running ardupilot 4.x, on ChibiOS
- low latency control
- 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?