# An exploratory study: UAVCAN as a middleware for ROS

**URL:** <https://forum.opencyphal.org/t/an-exploratory-study-uavcan-as-a-middleware-for-ros/872>\
**Category:** Applications & Usage\
**Created:** [July 14, 2020, 5:29pm UTC](https://forum.opencyphal.org/t/an-exploratory-study-uavcan-as-a-middleware-for-ros/872 "2020-07-14T17:29:45Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![PetervdPerk](https://forum.opencyphal.org/letter_avatar_proxy/v4/letter/p/bbe5ce/32.png) [@PetervdPerk](https://forum.opencyphal.org/u/PetervdPerk)\
**Post date:** [July 27, 2020, 10:06am UTC](https://forum.opencyphal.org/t/an-exploratory-study-uavcan-as-a-middleware-for-ros/872/2 "2020-07-27T10:06:32Z")

</div>

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](https://www.omg.org/spec/DDS-XRCE/About-DDS-XRCE/) which is used in the [micro-ROS](https://micro-ros.github.io/) project. This approach has one big con which is that you need an Agent convert DDS-XRCE to DDS and vice versa.

 ![](https://forum.opencyphal.org/uploads/default/original/1X/58fced7ad1467df3d317ed2fca1313abbe7e2542.png)

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` , where `bms_status` comes from the register named `uavcan.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.](https://www.dre.vanderbilt.edu/~schmidt/PDF/debs2014_submission_163.pdf) could be a great addition to solve the configuration problem while maintaining a democratic network.

---

_[View the full topic](https://forum.opencyphal.org/t/an-exploratory-study-uavcan-as-a-middleware-for-ros/872)._