Public regulated data types and ROS2 Common interfaces

Development & Maintenance
1

Hello, I ave a couple of questios as I might be a bit out the loop (just getting started with UAVCAN)

I am currently involved in the development of a robot and it makes sense for us to use UAVCAN for most of the low level systems (sensors and actuators) and ROS2 for the high level things (navigation mission management, etc). This means that we will need to do some translations from the UAVCAN data types to the ROS2 common interfaces at some point or the other. As I currently see it, there are some approaches that we can take in our project, among them are:

  • use the current public regulated data types that are the closest to what the actuator/sensor needs and on reception on the ROS2 unit translate them to ROS2 messages and services and get the extra information required for some of them from knowledge of the system.
    or
  • Add some of the common interfaces messages and services to the public regulated data types and upon reception on the ROS2 computer inject them to the ROS2 system as they come.

I feel that from my own project maintenance point of view the second approach makes it easier as the full information that I need is contained in the messages. I also feel that the second approach could besomething that could be worth push into the official UAVCAN repo into the reg folder but maybe in a ROS2 section?

What do you guys think? I am saying something idiotic and there is an easier way to do this? Or is this something sound and maybe the community would benefit from having ROS2 data types?

Best,
Pepe

EDIT:
I am adding the ROS2 common interfaces git for reference. As it might be a bit out of topic talking about ROS2

2

Hey Pepe,

Speaking generally, both of these approaches are viable but I want to emphasize that having data types inside the public regulated data types repository is not a necessary prerequisite for using them. You probably have your own custom data types defined for your ROS2 packages/stacks; you are expected to have that in UAVCAN, too. Here’s an example of a vendor-specific DSDL namespace that doesn’t need to have anything to do with the public regulated data types repository to be useful:

I think we might benefit indeed from having a public regulated namespace inspired by the standard data types of ROS2, but before going this way I would encourage you to prototype this in a separate project first. You are not going to need fixed port-IDs for this anyway so there are absolutely no technical limitations expected.

Related: An exploratory study: UAVCAN as a middleware for ROS