[UAVCAN] Architectural compatibility with other transport protocols and heterogeneous redundant transports

[pavel-kirienko]

There is a possibility that in the observable future, UAVCAN will support other transports besides CAN. The topic is reviewed in detail in this forum post: https://forum.uavcan.org/t/alternative-transport-protocols/324

Some UAVCAN implementations are more equal than others. The upcoming rewrite of Pyuavcan will be transport-agnostic, meaning that it is going to be architecturally compatible with UDP, and it will be extensible for other transport definitions that may come up in the future. Libuavcan and libcanard, on the other hand, are made to be CAN-only, non-transport-agnostic, due to historic reasons and also for reasons of resource optimization (it is expected that genericity will cost resources, which are limited on small CAN nodes).

Do we want the Rust implementation to be transport-agnostic or not?

[Hoeze]

Having one protocol to rule them all would be cool :+1:

Having UAVCAN supporting newer bus types would be very useful for applications with higher data rate requirements. Also, UDP support would allow bridging UAVCAN between CAN/ethernet. Therefore, I could have a CAN bus for small sensors and access them via TCP/IP.

[kjetilkjeka]

Finally internet again :rocket:

Do we want the Rust implementation to be transport-agnostic or not?

I think Rust is a language where this is possible without many problems. The idea was to do this through the TransportInterface trait which can be implemented for different protocols. The idea is to use this to support static dispatch