ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A

RMW-microxrcedds implementation

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,, so ideally we will embrace that future RCLC.

Anybody knows something about that RCLC on the roadmap?.

Hopefully, this answers your questions.

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?

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:

Note the following changes in ros2.repos:


Branch: release/1.7.0


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

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!

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.

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?

@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.

@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.


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?


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?


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.


yes it does, thanks.

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

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?

I meant projects that put ROS on a microcontroller with an RTOS other than rosserial. This is what I found after googling a bit:

Also the code from bosch comes up often:

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

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?


1 Like

Hi All, (microROS related guys)

just saying since we are not sure to squeeze out of the resource yet.

would it be good if we Sony integrate microROS into spresense?
or is there anyone already start working on that?

any comments and ideas will be really appreciated.


Hi @tomoyafujita.

would it be good if we Sony integrate microROS into spresense?

That will be great, actually.
I am not aware of anybody working on that.

I see you are using NuttX, that’s already supported so Ideally, you won’t find many hurdles. Anyway, If you need support or have any specific questions; we at micro-ROS, are happy to help.

Hi @tomoyafujita,

Glad to see you are interested!

I consider the platform could be nice to have as has enough RAM and Flash to run micro-ROS, PTP support and GPS, expansion board with Arduino-like pinout, camera slot, Cortex-M4 6x cores, sensor addons, …

I have some questions though:

  • Which NuttX version Sprense uses?
  • Is PTP supported in NuttX?
  • How is the multi-core working?
  • Any chance of supporting Ethernet?


@imguruza, @BorjaOuterelo

good to hear, thanks.
this is NOT official information,

but the as far as i checked, the following is the current situation.

seems there are some codes in mainline, cxd56xx

So far, NuttX itself does have PTP configuration. (NuttXConfigVariables)

about the multi-core you can refer to spresense_asmp_framework