Discussion - companion board for INAV

[digitalentity]

Finding a compact board that would support all of required sensors may become tricky, also wiring may become a pain in the back.

Suggestion - create a very simple board (or family of boards) that will talk to main FC over a new half-duplex protocol and act as a bridge between actual sensor and FC with INAV firmware.

To keep things compatible with most boards out there and also to keep additional costs low I suggest we use common UART in half-duplex mode. Transfer will happen in TDMA fashion with all data transfer scheduled by the FC (master). For physical interface I see two options:

1. Use differential two-wire signalling as a physical transport - we can use CAN transceivers (like TJA1055 or MCP2551) to convert between UART and physical medium. Pros: high reliability and noise tolerance. Cons: extra costs for transceiver chip on each device on the bus; extra device between FC and the bus.
2. Use simple open-drain bus - like the one used in I2C, S.Port and HoTT. Pros: only three wires required, doesn't require additional hardware - can be implemented using built-in controllers on any STM32 chip, more cost-effective solution; Cons: less robust.

Bill of materials price for the convertor board would be abour 4-5$, fairly large SMD components can be used to allow DIY-style.

List of possible use-cases for the convertor board:

1. A bridge between APM-style GPS+Compass unit and FC without I2C bus
2. Bridge between ultrasonic or optical rangefinder for all boards
3. Support for "mouse" optical flow sensor (ADNS3080) for boards without SPI

[giacomo892]

Nice idea.

I see also some others use-cases:

1) dual GPS operation to prevent glitches and having overkill redundancy. 2) lateral collision avoidance sensors (additional sonars for example) 3) barometer (so we can avoid to connect it to main i2c port on the FC) 4) integrated buzzer :) since no board has it

[moggiex]

@digitalentity I think I understand what you're trying to do here, my suggestion would be to try & keep everything as simple as possible.

With that in mind, could a secondary flight controller be used as a "slave" device to achieve this?

Matt

[digitalentity]

Yes, a secondary flight controller could be used (in fact it's a great idea). However I'm thinking also about higher reliability for bigger machines.

[digitalentity]

Sensor bus protocol proposal (using one-wire UART as an interface).

0. Baud rate of the bus is 100kbps
1. Transmission is scheduled and initiated by master (FC). Transmission is divided into slots of 5ms long. Slots are assigned by master. Device (sensor) is only allowed to transmit if polled by master. A guard interval of 2ms exists between slots and is used by devices as a bus reset - next byte after guard interval is a scheduling command from master.
2. Device (sensor) is globally identified by a 8-bit DevID (also defining priority) - lower absolute value means lower priority (as in CAN Bus).
3. At run-time devices are discovered and assigned a run-time 6-bit slot number (up to 64 devices may co-exist on one bus)

Master initiates transmission by sending command+slot identifier packed into 1 byte: cc ssssss - where CC is command code and SSSSSS is slot identifier.

Command code 00 - DISCOVER

DISCOVER command is followed by 1 byte of DevID. A device with matching DevID must respond with 2 bytes of desired poll interval and 2 bytes of CRC-16. A slot number must be remembered by the device and used in further transmission

Command code 01 - READ

This command doesn't have any argumentrs. A device that was assigned a slot must respond with 8 bytes of data and 2 bytes of CRC. Response delay shouldn't be longer than 2ms (to avoid mixing it up for guard interval).

At 100kbps speed transmission of 1 byte command + 10 byts of response will take ~1.3ms. If device makes 0.5ms delay we still fit info <3ms total activity time to allow 2ms guard interval after transfer finishes.

Notes:

A maximum of 8 bytes of data is allowed for compatibility with CAN Bus so one message will fit into one CAN frame. A sensor may have more than one ID (i.e. GPS)

List of possible IDs:

Proposed assignment scheme: 4 bits data class + 4 bits data type

Class 0x0 - AHRS/MARG sensors 0x00 - reserved for something really high priority 0x08 - Magnetic field vector (3D)

Class 0x1 - Altitude and climb rate data 0x10 - GPS altitude and climb rate 0x11 - Barometric altitude 0x12 - Rangefinder altitude

Class 0x2 - 2D-position and velocity data 0x20 - GPS coordinates (LAT/LON) + validity flag (LAT/LON fit into 31 bits, this leaves us 2 bits for flags) 0x21 - GPS velocities (2D) and CoG + validity flag 0x22 - Optical flow vector (2D) and quality

Class 0x8 - RC control 0x80 - RC channels (4 channels with 10-bit resolution + 4 channels with 6-bit resolution)

Class 0xF - sensor statistics and information (low priority, low rate) 0xF0 - GPS sat count, HDOP etc

[DzikuVx]

@digitalentity

• airspeed is missing
• no WRITE messages?
• forward obstacle distance?

[digitalentity]

@DzikuVx that's just an idea of what sensor assignment may look like. Airspeed and surroundings - good catch :)

WRITE messages could be implemented in a similar way as READ ones - only with different source of data on the wire.

[moggiex]

Daft question gents, this line got me thinking:

0x80 - RC channels (4 channels with 10-bit resolution + 4 channels with 6-bit resolution)

Thinking about FrSky kit whom has no "satellite" receivers support (there is the ability with the X8R I believe but the range is still low > 2.6Km) , could a second receiver be added to the child board, thus if the main one hits failsafe, the secondary one could be checked and if working, used instead?

Thinking of your note around "bigger machines", on a bigger machine a secondary receiver could be easily placed in a different position to the main receiver.

Just a thought!

Matt

[Redshifft]

RC Receivers are insignificant over Flight controller, sensors and code to control a Multirotor.

[digitalentity]

@moggiex good idea, it would be good to have multiple receiver support - we need to think about it.

[digitalentity]

@Redshifft yes, sensor are more important, but reliable pilot input is also quite important thing to have. If we can add extra reliability - why shouldn't we?

[Redshifft]

@digitalentity You don't need to be far away before any RC link is useless to try and guide a multirotor home - might be inconvenient to drop RC link the but the FC and sensors will get you home and backed up by a second sensor suite which on the side could even be logging waypoints to get back safely. You could even add to that Airplane style mag-less navigation to home. It's more likely any RX backup will be subject to the same cause of failure as the primary ( generally blanking or interference)

[digitalentity]

@Redshifft Any redundancy is better than no redundancy. Also, nobody is restricting you to use two receivers of the same type. One, for instance, could be DragonLink, the other - Crossfire. Even if all sensors fail, if you have a working RC link - you still may be able to switch to manual and bring the plane back. For copters, however, things are different - here I totally agree with you that having a set of backup sensors is better than a reliable link.

[digitalentity]

Other ideas for this "UAVBus" protocol:

• Camera and VTX contrtol
• External OSD
• Telemetry uplink (device will convert FC data to LTM/MAVLink/etc and send out to the air)

[cabinw]

@digitalentity Got similar idea. It's really convenient for both multi-rotors and fixed-wings. @moggiex Great idea! Using a secondary flight controller could be very helpful especially for long range fpv flights.

I've designed a companion board for spracing f3 mainly for integrated OSD and separated BEC for servos. A companion board is not only for adding functions but also useful for deploying and wiring.

Hope get more infos about "UAVBus" protocol.

[digitalentity]

See this for first draft of UAV Interconnect Bus https://github.com/iNavFlight/inav/wiki/UAV-Interconnect-Bus

[stale[bot]]

This issue / pull request has been automatically marked as stale because it has not had any activity in 60 days. The resources of the INAV team are limited, and so we are asking for your help. This issue / pull request will be closed if no further activity occurs within two weeks.

[stale[bot]]

Automatically closing as inactive.

[dimon777]

There is a big class problems which are not directly related to the flight aspect and require not only sensor boards but full companion computer. Deep sensor fusion (which require more powerful CPU). Inferring/classifying the land objects types during low pass flights or on the approach. It would be great if INAV would expose/allow such integration. I was able to connect RPI nano board to Pixhawk and expose FC to commands from RPI over Mavlink.

[digitalentity]

@dimon777 what commands are you talking about specifically?

[dimon777]

@dimon777 what commands are you talking about specifically?

Disclaimer: I am not a professional drone expert :) yet!

@digitalentity So for example, we want to implement an obstacle avoidance. The solution for this problem can't be generalized, because it is too complex and environmentally and situationally specific. I have a set of simple sensors or in more complex use case set of matrix sensors outputting point cloud. This point cloud is fused with other sensors: gyro, acc, baro, cameras, perhaps with some static data like terrain heightmaps etc. to allow navigation in a complex environment and help drone become environment aware. What commands? Anything from roll/pitch/yaw/throttle corrections to help drone safely deliver that pizza to the customer avoiding trees, power lines, people, animals and what's not and make sure a parcel is not landed into the water from the overnight rainfall. This requires lot of computation and I feel ultimately not a job for a FC. If this makes sense.