UAV Interconnect Bus
INAV implements universal interconnect bus for various types of sensors and executable devices.
It's compatible with all existing controllers that have a spare UART and designed to be able to connect multiple sensors to one shared bus. Devices on the bus can be daisy-chained together for neater wiring.
Physical layer​
Option 1: Differential signalling​
This option is taken from automotive applications and uses CAN bus transceivers (MCP2551 or SN65HVD232) to convert between twisted pair and UART. A special converter is required between each device and a bus. While this option is more expensive it's also very reliable.
Advantages: high reliability, long wires possible.
Option 2: Shared wire​
This option is designed for tight spaces or very cost-sensitive solutions. Wiring should follow Siemens Application Node AP2921: On-Board Communication via CAN without Transceiver (https://www.mikrocontroller.net/attachment/28831/siemens_AP2921.pdf)
Advantages: low price, low wire count
Data format on the wire​
From data format point of view it's plain asynchronous serial with following parameters:
115200,8,n,1
**FIXME: Chose a baud rate that has high reliability across multiple MCUs **
Notes​
Both differential signalling and shared wire connection options are verified to work.
Device addressing​
Each slave device on a bus has a unique DevID which defines device functionality (GPS, Optical flow, RC receiver etc). DevID is one byte and also serves as a device priority - master controller will favor devices with lower DevID
During discovery phase on the bus each device is assigned a SlotID which it must use for communicating with the master. DevID is only used during discovery phase.
Device capabilities​
During discovery each device must report capability flags (16-bit field, see IDENTIFY command).
| Flag mask | Name | Description |
|---|---|---|
| 0x01 | HAS_READ | Indicates that device supports READ command and should be polled periodically |
| 0x02 | HAS_WRITE | Indicates that device supports WRITE command and can accept data |
Transactions on a bus​
Everything on a bus is coordinated by a master device (flight controller) and all transactions are organised in slots. There are at most 32 slots (active devices) possible on a single bus.
Master begins transaction with one byte. Highest 3 bits indicate a command, while lower 5 bits indicate a SlotID. The rest of transaction depends on which command is being executed.
A 2ms guard interval is mandatory between transactions and is used by all devices to reset internal state. First byte after guard interval is assumed to be a command from master device.
Data integrity​
Each transaction on a bus ends with a 1-byte CRC calculated by CRC-8/DVB-S2 algorithm. CRC is calculated over all transaction bytes starting with command byte. CRC is calculated by the data originator and verified by the master.
Commands on a bus​
| Hex | Binary | Name | Description |
|---|---|---|---|
| 0x00 | 000xxxx | IDENTIFY | Performs device identification and slot assignment |
| 0x20 | 001xxxx | NOTIFY | Notifies a device about assigned (or re-assigned) slot |
| 0x40 | 010xxxx | READ | Performs a read transaction from a slot |
| 0x60 | 011xxxx | WRITE | Performs a write transaction on the bus |
| 0x80 | 100xxxx | reserved | Not used |
| 0xA0 | 101xxxx | reserved | Not used |
| 0xC0 | 110xxxx | reserved | Not used |
| 0xE0 | 111xxxx | reserved | Not used |
IDENTIFY (0x00)​
| Byte | Originator | Description |
|---|---|---|
| 0 | Master | Value of (0x00 + SlotID) |
| 1 | Master | DevID of requested device |
| 2 | Master | UIB Protocol version (0x00) |
| 3 | Master | CRC1 (over bytes 0-1) |
| 4 | Slave | Poll interval (low byte) |
| 5 | Slave | Poll interval (high byte) |
| 6 | Slave | Device flags (low byte) |
| 7 | Slave | Device flags (high byte) |
| 8 | Slave | Device parameters [0] |
| 9 | Slave | Device parameters [1] |
| 10 | Slave | Device parameters [2] |
| 11 | Slave | Device parameters [3] |
| 12 | Slave | CRC2 (over bytes 0-10) |
During discovery phase master sends IDENTIFY commands for each supported DevID. Device with corresponding DevID must respond with desired poll interval (in milliseconds) and flag field. Master will send it's protocol version in IDENTIFY request. Slave device should respond only if it's able to talk this protocol version. Also, device which has detected it's DevID must remember the SlotID of the transaction - this will be the SlotID assigned to the device; it should also remember the protocol version it should be using to communicate.
Device parameters field (4 bytes) is device-specific and may be used to pass extended capabilities or non-standard flags to the host driver.
NOTIFY (0x20)​
| Byte | Originator | Description |
|---|---|---|
| 0 | Master | Value of (0x20 + SlotID) |
| 1 | Master | DevID of requested device |
| 2 | Master | UIB Protocol version (0x00) |
| 3 | Master | CRC1 (over bytes 0-1) |
Used to assign a slot to a device. Device shouldn't respond, but only keep record of assigned SlotID.
READ (0x40)​
| Byte | Originator | Description |
|---|---|---|
| 0 | Master | Value of (0x40 + SlotID) |
| 1 | Master | CRC1 (over byte 0) |
| 2 | Slave | Data payload length (may be zero) |
| 3... | Slave | Data packet (up to 32 bytes) |
| last | Slave | CRC2 (from start of packet) |
Device with SlotID that was assigned to it during discovery phase must respond to this command with a variable-length data packet. If device has no new data available it should respond with zero payload length.
WRITE (0x60)​
| Byte | Originator | Description |
|---|---|---|
| 0 | Master | Value of (0x80 + SlotID) |
| 1 | Slave | Data payload length (may be zero) |
| 2... | Master | Data packet (up to 32 bytes) |
| last | Slave | CRC2 (from start of packet) |
Device with SlotID that was assigned to it during discovery phase must silently accept the data. No acknowledgement it done by the device. Together with NOTIFY this command brings a possibility to have several devices on the same DevID/SlotID.
Devices​
It's recommended that each device use first byte of READ payload as flag field with following values:
| Bit | Mask | Description |
|---|---|---|
| 0 | 0x01 | UIB_DATA_VALID - indicates data validity |
| 1 | 0x02 | Unused, must be zero |
| 2 | 0x04 | Unused, must be zero |
| 3 | 0x08 | Unused, must be zero |
| 4 | 0x10 | Unused, must be zero |
| 5 | 0x20 | Unused, must be zero |
| 6 | 0x40 | Unused, must be zero |
| 7 | 0x80 | Unused, must be zero |
Device ID = 0x12 : Rangefinder​
Flag UIB_DATA_VALID will indicate that reading is valid (surface is in range and measurement is correct)
Recommended payload format:
typedef struct __attribute__((packed)) {
uint8_t flags;
uint16_t distanceCm;
} rangefinderData_t;
Device ID = 0x13 : GPS sensor​
Flag UIB_DATA_VALID will indicate that reading is valid, UIB_DATA_NEW - that data is fresh
Recommended payload format:
typedef struct __attribute__((packed)) {
uint8_t fix_type;
uint8_t sat_count
uint8_t hdop;
int32_t longitude;
int32_t latitude;
int32_t altitude_msl;
int16_t vel_north;
int16_t vel_east;
int16_t vel_down;
int16_t speed_2d;
int16_t heading_2d;
} gpsDataPacket_t;
Device ID = 0x80 : RC Receiver​
Flag UIB_DATA_VALID will indicate that receiver has a valid link to transmitter. This is an inverse of FAILSAFE flag in common digital receivers.
Recommended payload format:
typedef struct __attribute__((packed)) {
uint8_t flags; // UIB_DATA_VALID (0x01) - link ok
uint8_t rssi;
uint8_t sticks[4]; // Values in range [0;255], center = 127
uint8_t aux[8]; // Analog AUX channels - values in range [0;255], center = 127
uint16_t reserved; // Reserved for future use
} rcReceiverData_t;
Values of sticks[] and aux[] array should be in range [0;255] and will correspond to [1000;2000] values.