ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A answers.ros.org

RMW-microxrcedds implementation

#1

Hi.

We have been working on an implementation of RMW using eProsima’s Micro XRCE-DDS.
We made this as part of OFERA project approach to embedded ROS 2.

In a nutshell, this approach consists on changing middleware implementation (from DDS to DDS-XRCE) and change the user API (using rclc) for cross-compile all the stack for the microcontroller. Currently, some tests have been done using NuttX over STM32.
Apart from that NuttX tests, this packages work on a Linux machine without issues and using either RCLCPP or RCLC, see the provided demos to further information.

The implementation consists of a set of new packages:




And modifications to the rclc.

All these packages work with the existing ROS 2 stack (rcl, rmw, typesupport…).
From these packages, rmw and typesupport have tests implemented.
All should compile using standard colcon tools in a ROS 2 environment, colcon build, colcon test.
You just need to add these repositories to your ROS 2 workspace.

For testing purposes, I have attached a file with all the required ROS 2 repositories and micro-ROS specific ones.

Once you cloned the repositories, these are the commands you may want to run to try it:

#Build All
colcon build --cmake-args -DBUILD_SHARED_LIBS=ON
#configure environment variables
. ~/ros2_ws/install/./local_setup.bash
#Run agent node
~/ros2_ws/install/uros_agent/lib/uros_agent/uros_agent udp 8888
#Run rclcpp demo publisher
~/ros2_ws/install/complex_msg_publisher_cpp/lib/complex_msg_publisher_cpp/complex_msg_publisher_cpp
#Run rclc demo publisher
~/ros2_ws/install/complex_msg_publisher_c/lib/complex_msg_publisher_c/complex_msg_publisher_c
#Run rclcpp demo subscriber
~/ros2_ws/install/complex_msg_subscriber_cpp/lib/complex_msg_subscriber_cpp/complex_msg_subscriber_cpp
#Run rclc demo subscriber
~/ros2_ws/install/complex_msg_subscriber_c/lib/complex_msg_subscriber_c/complex_msg_subscriber_c

Furthermore, you can run Micro ROS packages tests with:

colcon test --packages-select rosidl_typesupport_microxrcedds_c rosidl_typesupport_microxrcedds_c_tests rosidl_typesupport_microxrcedds_cpp rosidl_typesupport_microxrcedds_cpp_tests rosidl_typesupport_microxrcedds_test_msg rmw_microxrcedds

All these packages are work in progress and will be updated and extend API. Currently, only publish/subscribe API has been implemented.
Currently working on polishing a NuttX build system.

2 Likes

ROS2 Cross compilation
ROS2 Embedded SIG meeting #1
#2

Great work!

Could you give a run-down on the major differences between libraries you have produced and their equivalents from the github/ros2 organisation (where there are equivalents)? I’m thinking in particular of microROS/rclc.

0 Likes

#3

Hi @gbiggs.

The correspondence of the libraries with existing ones is:

microROS/rmw-microxrcedds <=> ros2/rmw_fastrtps
microROS/rosidl_typesupport_microxrcedds <=> ros2/rosidl_typesupport_fastrtps

microROS/micro-ROS-demos <=> ros2/demos
Not really sure about this last one. But, It is just a package with some dummy samples and different likewise “hello world” code.

microROS/micro-ROS-Agent does not have equivalent or similar in ROS 2.

Regarding RCLC. This is just a fork with small modifications. We have some issues with this package while using our cross-compiling toolchain and building on windows. The intention of this fork, besides enabling the compilation, is to expand its implementation to include more of the ROS 2 concepts, thinking on services or timers.
However, this rclc expansion could be stopped, as a few days ago I found that RCLC is listed on Crystal roadmap, https://index.ros.org/doc/ros2/Roadmap/, so ideally we will embrace that future RCLC.

Anybody knows something about that RCLC on the roadmap?.

Hopefully, this answers your questions.

0 Likes

#4

Hi, @BorjaOuterelo

eProsima’s Micro-XRCE-DDS(version 1.0.1) requires FastRTPS 1.7.0.
However, rmw_fastrtps is not currently in version 1.7.0.
If I use rmw-microxrcedds, can I use Micro-XRCE-DDS version 1.0.1 without problems?

0 Likes

#5

Hi @Kei.

rmw-microxrcedds depends on Micro XRCE-DDS Client v1.0.1.
micro-ROS Agent depends on Micro XRCE-DDS Agent v1.01, so the dependency with FastRTPS 1.7.0 is here, on the agent side.
This force you to use FastRTPS 1.7.0 on your ROS 2 workspace where you want the micro-ROS Agent running.

You can check that there is an ongoing pull request to upgrade ROS 2 repositories to that version:

From that you can get Dirk’s list of ros2.repos used for testing:
https://gist.githubusercontent.com/dirk-thomas/e377d8de1d8d7d41e15e1955a46f96c9/raw/dc498ab63c038df358bd2c0ccfad86dc0e0615cb/ros2.repos

Note the following changes in ros2.repos:

Fast-RTPS

Branch: release/1.7.0

rmw_fastrtps

Repo: https://github.com/eProsima/rmw_fastrtps.git
Branch : fastrtps-1.7.0

Hopefully, this clarifies a bit on the dependencies.

Although, on this repository specific to micro-ROS, there are lists of repositories for agent and client side:

If you have any other question, I will be glad to help.

1 Like

#6

Thanks @BorjaOuterelo,

There are some problems (include path etc …) due to different submodule commit information of agent and commit information of FastRTPS release/1.7.0 branch, but I will leave an issue in eProsima’s Github.

Anyway, the information you gave me widened the possibilities I could! Thank you!

0 Likes

#7

It’s nice to see work on interfacing microcontrollers with a standard protocol.

From the current documentation of eProsima’s Micro-XRCE-DDS, only Windows and POSIX APIs (Linux, Nuttx, …) are supported. Are there plans to support the serial protocol on 8bit Arduinos and bare metal STM32?

Especially the ATmega328 with it’s 32KB flash and 2KB SRAM (that’s what I call an extremely resource constrained environment) would make a nice demonstration of the DDS-XRCE serial protocol.

0 Likes

#8

Hi @christian

Currently, Micro XRCE-DDS supports defining user-custom transports so it would not be difficult to support new platforms, APIs.
Regarding memory footprint and size, Micro XRCE-DDS could be customised with user configurations so you can tune it to fit in smaller platforms. On our minimal test we measured 2.5KB of SRAM usage, but as I mentioned it could be customized per application.

Currently or lower-end supported-tested platform is the same as for micro-ROS: STM32L1 Discovery. 256KB flash and 32KB of SRAM.

Though, We haven’t tested it on 8bits platforms but could be an interesting test.
Are you currently using it on such platforms?.
Have you identified any possible failling or improvement point for such platforms?

0 Likes

#9

@BorjaOuterelo I am primarily interested in using micro-ROS on a bare metal STM32F103 for serial communication with a companion PC. But it would be beneficial if the same serial protocol and agent could be reused as a replacement for rosserial_arduino to communicate with the widely used Arduino platform.
I.e. if micro-ROS is not capable of running on an Arduino (ATmega328), the ROS community would need to look into alternative approaches like porting rosserial to ROS2.

0 Likes

#10

@christian for STM32F103 depending on the available SRAM, you should not find many issues using micro-ROS.
Currently, we are targeting STM32L152 as our lower-end devices.
We are still working on some size issues but will get there eventually.

For Arduino platforms, to be honest, we haven’t tried it on 8Bit microcontrollers but if it has enough SRAM, it might work but need thoughtful testing. Currently, micro-ROS is going to need a bit of size reduction work but vanilla Micro XRCE-DDS middleware should fit into an Arduino.

Ideally, micro-ROS underlying middleware implementation, Micro XRCE-DDS, could mimic rosserial behaviour, actually, we have improvements on our roadmap in that same direction, so with the aforementioned Micro XRCE-DDS improvements and if we manage to shrink micro-ROS to fit into an Arduino that will be possible.

0 Likes

#11

@BorjaOuterelo

great work! sorry i miss this thread, been a long time.

i understand agent can be working as “bridge”, right?
and one thing i want to confirm, is there any constraints or limitation on microROS side?

thanks

0 Likes

#12

Hi @tomoya

Right, Agent acts on behalf of the clients on the DDS network.

What do you mean with “microROS side”? If you mean client, there is no strong limitation or constrain apart from the aforementioned ones of SRAM usage and the currently supported platforms, but for the latter, the user can easily port to their platform.
Does this respond to your question? Or you are thinking about another kind of limitation?

0 Likes

#13

@BorjaOuterelo

Awesome work. I have been looking for exactly something like this. I am a bit of a noob, but I will try to use this on my STM32F446RET6 and experiment with different sensors.
Will this be eventually used in ROS2 and can it be ported to ROS1? All the official documentations point to the old repos from 2016ish times and were abandoned.

0 Likes

#14

@BorjaOuterelo

yes it does, thanks.

0 Likes

#15

Hi, @tomoyafujita I am just curious about your use case. Can you share with us further information?

0 Likes

#16

Hi @braineniac.

Currently, it works with ROS 2 as it relays on DDS for the communications. Porting to ROS1 will need a different Agent implementation, we are working on changes on micro XRCE-DDS side in that direction. We will make that public soon.
micro XRCE-DDS is the underlying middleware implementation, to clarify.

All the official documentations point to the old repos from 2016ish times and were abandoned.

I am not sure which repositories you refer here. Can you point me to them?

0 Likes

#17

I meant projects that put ROS on a microcontroller with an RTOS other than rosserial. This is what I found after googling a bit:
http://wiki.ros.org/sig/Embedded
http://wiki.ros.org/FreeRTPS%2BFreeRTOS

Also the code from bosch comes up often:

The only place I could find any information about microROS is this discourse topic.

0 Likes

#18

Hi @BorjaOuterelo

i don’t have any solid usecase for now, sorry about that.
but off the top of my head, it would be like some nodes running DDS, and for really small “IoT” nodes would use DDS XRCE. Does that answer your question?

thanks,

1 Like