It is intended to connect two and only two devices together (semi-permanently) and has a lower speed than most other protocols. It is one of the simplest protocols and has been around since about 1960. The SER is an RS-232- like protocol that uses one wire for Transmit and one wire for Receive. These last two may or may not be built into a controller. Things like CAN and USB are a bit more modern and USB replaces SER on modern computers. The ones mentioned that have a name like SER and description of UART are built into most controllers. There are several different protocols that have different uses and different limitations. 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? ![]() In short, all UART & CAN are from controller, and all USB are from companion computer. USB D+ Positive differential data signal to iMX6 OTG USB port. USB D- Negative differential data signal to iMX6 OTG USB port.Ģ. SER2CT UART2 CTS input to Pixhawk™ 2 for flow control. SER5 RX (DEBUG) UART5 RX input to Pixhawk™ 2.Ģ5. SER2RT UART2 RTS output from Pixhawk™ 2 for flow control. SER5 TX (DEBUG) UART5 TX output from Pixhawk™ 2.ġ0. high latency, complex, high level processingĪccording to this doc, here are all the UART and CAN interfaces: 9.running a custom yocto poky linux distro.It has 2 computers: a controller and a companion computer: And typically serve as the reference board for an open source UAV system. 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). When I'm reading the extension capability of 3DR Solo, I realise that its breakout board interface has some peculiar limitation.
0 Comments
Leave a Reply. |