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

ROS 2 over email: rmw_email, an RMW implementation

Ever wanted to use emails to exchange ROS 2 messages? Yes? Well, now you can with rmw_email! GitHub - christophebedard/rmw_email: ROS 2 over email: a middleware implementation

I wrote a blog post to explain the motivation behind this project, provide an overview of each component, show a couple demos, and talk about performance and limitations: ROS 2 Over Email: rmw_email, an Actual Working RMW Implementation – Christophe Bédard

In short, rmw_email consists mainly of two packages: email, the middleware, and rmw_email_cpp, the RMW implementation.

email is a simple pub/sub & service middleware for string messages. As its name suggests, emails are used to exchange messages: the topic/service name is the email subject and the message content is the email body.

rmw_email_cpp is an implementation of the ROS 2 middleware interface, rmw, using email. It uses an external package that does the hard work to convert ROS 2 messages to YAML and back. Since email only handles strings, the YAML objects are then converted to strings and passed on to email.

Here’s an example with the add_two_ints client/server demo:


For more details, see the blog post or the repository!


This is great and really made my morning! I hope we can see similar RMW implementations for text messaging and postal service in the future.


Is it realtime safe?



Obligatory ref rfc1149 (or as it’s important for ROS 2: rfc2549 (with QoS)).

But in all seriousness: this is a great ‘toy’ example of an RMW implementation.

Should this become a tutorial?

Edit: I would love to be able to answer questions about RMW implementations by directing people to a “ROS2-over-email example” tutorial.


This is amazing! I really enjoyed reading your blog post. I’m curious about your thoughts on the void * abstraction when working with C++ types like std::vector<T> in the introspection typesupport. What changes could be made to that interface to make working with it easier?


This might have legitimate uses, too. Like getting an email about the status of your robot every morning, or sending automatic updates to non-technical people.


interesting idea…maybe could be extending to SMS, too


I am sure that this was fun and informative to write. Any plans to use other transport layers like carrier pigeons, USB drives on airplanes, or SMS messages? :rofl:


Unsurprisingly, it’s really not :laughing:

This did cross my mind, especially since I read @methylDragon’s RMW deep dive before writing the RMW implementation, so I also think an actual RMW implementation tutorial/example would be great. I’ll think about it and see how this could be done.

That’s a good question. Perhaps the introspection layer could simply provide some tools to more easily interpret those type-erased pointers? I haven’t really looked into how the other (more serious) implementations do their serialization, so maybe this exists, but yeah it would be great if it were provided by the type support introspection library directly.

You could definitely skip rmw_email_cpp and use the email middleware directly from a node that does that! :grinning:

It was indeed a ton of fun! And yeah, writing a 2nd/3rd/Nth implementation should be easy (and everyone’s giving some great ideas), so that means I have to do it right? :stuck_out_tongue_winking_eye:


By the way, you just made my Monday. I rarely get to use Tik-Tok memes at work.


Congrats, you are now legally obligated to write rmw_sms!