UAVCAN to ROS2 bridge?

BrettRD · 2021-03-28T04:16:05.140Z

Hi all,

Since the wonderful announcement that the microros API has support for custom transport, there’s been some talk about integration with CANbus, including a well-polished document (which I can’t find) outlining some of the layers required to move ros2 data over a canbus.

On the other side of the fence, people at UAVCAN have put some thought into how ROS can communicate over a CANbus:

UAVCAN Forum – 14 Jul 20

An exploratory study: UAVCAN as a middleware for ROS

Why? In 2020, arguably the most critical piece of ROS is the software ecosystem built around it. The existing software is the reason why ROS2 is being designed the way it is, with the built-in means of backward compatibility and the old IDL kept...

Reading time: 3 mins 🕑 Likes: 3 ❤

I don’t see this becoming a primary middleware for rclcpp, but it could be very effective as a microros-microros middleware, or as a distributed and robust microros agent.
At very least, there are some great suggestions for mappings between ros2 topic names and (uavcan) CAN IDs, and it offers a ready-made solution for packetising messages.

I’d be interested to see what colcon layer requirements this approach would have, and what complexity would be introduced for non-collision with can-open and other established standards

Cheers,
BrettRD

FraFin · 2021-03-29T09:03:37.464Z

The well-polished doc you’re referring to can be found as an attachment to this post in the EWG meetings thread: ROS 2 Embedded WG meetings - #11 by FraFin (unfortunately, we don’t have the recording of the session).

Further thoughts on the matter from the micro-ROS’ dev team side coming soon!

FraFin · 2021-03-31T10:45:13.391Z

Actually, yes, implementing a rmw_uavcan for micro-ROS sounds quite promising, although a major architecture refactor would be needed on the Agent’s side in order to achieve a UAVCAN to DDS bridge. @BrettRD Do you have any such plan in mind?

BrettRD · 2021-04-03T13:08:12.884Z

My imagination only got so far as a Micro-ROS node forwarding everything to an agent, but I suspect it needs to be more like ros1_bridge.

Most of the existing Micro-ROS targets have native canbus hardware, so that’s probably how most people will get started with a hypothetical rmw_uavcan.
Industrial users would want to use SocketCAN on native canbus hardware in embedded Linux devices.
I’d want to write it such that the system integrator can choose whether the bridge is in ROS or Micro-ROS.

I have no idea how you’d tell an agent that a topic should be forwarded from DDS to UAVCAN, and I don’t know how you’d de-duplicate UAVCAN messages that got to the DDS via multiple agents.
I would expect some proper networking nightmare fuel behind the scenes; a simple benchtop case is likely to have two can-busses, two Linux machines, the dds, two agents, and a dozen micro-ros devices.

At the risk of a combinatorial explosion of this-rmw-to-that-rmw bridges, is it possible to implement something like ros1_bridge in rclc behind a Micro-ROS agent?
Do bad things happen when you run two instances of ros1_bridge?