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

Is this the place to discuss bugs and fixes to ROS_serial?


If this is not the place, please point me to the correct place. Thanks.

ROS Serial supports several platforms and is inherently multi-platform. The libraries need to compile on the Arduino IDE, some RTOSes and so on. This might be the only part of ROS 1 that is actually multi-platform. Some platforms are more popular than others. For example, Arduino seems to be very popular and others may not be used so much.

I’d suggest that it is a bug if the included “Hello World” style examples fail to compile on a platform using that platforms’ official native build system. Yes, this is a strict definition of “bug”. But be this rule ROS Serial is bug-free on Arduino and completely broken on Mbed.

I have posted some questions on a few forums asking if anyone has built a ROS Serial client on the Mbed platform using the “official” Mbed build tools and the current version of both ROS (Melodic) and Mbed. (5.10+) I’ve not yet heard from anyone who claims to have done this.

In an ideal case, the Mbed would work like the Arduino: A developer would import the ROS_Serial library and a “hello World” example to his IDE click “build” and it “just works”

Where to discuss (1) if this needs to be changed and (2) possible solutions?

ROS Serial is a great idea and could be much more useful if it worked better with some more powerful platforms like an STM32F that runs an RTOS.

Need to discuss if it needs fixing and if so what to do.

Perhaps we just leave it and move on to ROS 2 as I’m guessing ROS 2 will eliminate the need for ROS Serial. As people could run a DDS library on the microcontroller.



That’s not exactly right @Chris_Albertson. Well at least not fully. There’s been a few initiatives over the past years. Of most relevance (disclaimer, my team is working on 3.):

  1. An initial attempt to port a complete DDS implementation to a microcontroller has been made available by Open Robotics at but it hasn’t been maintained for a while.

  2. Another attempt to get an RTPS (the underlying protocol of DDS) library running in uC is

  3. A newer initiative called micro-ROS is ongoing at and proposes a slightly different architecture where it breaks the fully distributed paradigm by introducing a client/server architecture between microcontrollers and an a bridging Linux machine (an SBC for now) for interfacing with the ROS 2 network and hopefully, reaching much smaller microcontroller footprints. Refer to for the middleware implementation.

If you have some cycles to support any of these initiatives I’d recommend contributing to 2 or 3 Probably in that order since both are complementary and 2 could be used either independently or as one of the communication middlewares within 3 (which would be pretty cool).



The problem of course is I already have enough projects that I’m 100% occupied. But I see micro-ROS as the way to go one a follow-on to what I’m doing.

That project is a ROS base controller in an STM32F “Blue PIll” board. It connects to ROS1 via ROS Serial. The STM32 is configured from the parameter server, subscribes to cmd_vel and publishes TF and /odom. Nothing new except I want it to be a plug and play hardware device. The board is under $3 and it will be integrated with a commonly cloned h-bridge.

The follow up will have it’s own IMU and will fuse with odometry and GPS all on the STM32 F7 processor. micro-ros would be ideal for this. Looking at something like this drone flight controller to control a 2 to 6 wheel drive platform.

One question: Is there a preferred development platform for micro-ROS? What do the developers use themselves? I’d like to start with the best-supported hardware platform.