ROS2 over CAN bus (through UAVCAN) sounds very promising. I suppose the main requirement you want to fulfill would be ROS2 based communication between small microcontrollers and rich microcontrollers, which is hard on ROS2 due to the size and complexity of an DDS implementation.
A solution the ROS2 community uses to solve this is DDS-XRCE which is used in the micro-ROS project. This approach has one big con which is that you need an Agent convert DDS-XRCE to DDS and vice versa.
I think utilizing UAVCAN on both micro-ROS and ROS2 would provide an appealing solution, which doesn’t need a master/agent thus having no single point of failure.
But the catch would be how to be ROS2 compatible while maintaining the democratic property of UAVCAN. As you propose in your study
What I suggest is to make the decentralized ROS master responsible for establishing the correct configuration of every node in the network by writing the correct subject-ID register values in accordance with the namespace in which the node resides. Expanding upon the above example, if the BMS node is launched in the ROS namespace
/foo/bar/, it will automatically populate a topic/foo/bar/bms_status, wherebms_statuscomes from the register nameduavcan.pub.bms_status. The specific subject-ID values are to be chosen by the decentralized ROS master automatically, which are then committed to the shared log described above.
Is a bit alarming to me, using the term “ROS master” seems to insinuate that we introduce a single point of failure, is this correct? Wouldn’t it be smarter to implement a discovery-like implementation to setup a democratic configuration as in DDS? A discovery protocol as described by An, Kyoungho, et al. could be a great addition to solve the configuration problem while maintaining a democratic network.