I am writing this article today to introduce the ros2arduino and open a discussion forum. ros2arduino is aimed at the ROS2 library available in Arduino, like rosserial_arduino in ros1.
This is currently included in the roadmap for the next release of ROS2.
Below is ros2arduino’s plan on current roadmap.
ros2arduino (using RTPS supporting XRCE such as microRTPS; note that this approach uses a different wire protocol from ROS 2 atop a full DDS/RTPS system)
supports TurtleBot3’s embedded system (OpenCR, it supports Arduino IDE)
supports Arduino MEGA, ZERO and other compatible microcontrollers
make message header and API generator
provide tutorials (e.g., Arduino IDE Setup, custom message, LED/Servo/Sensors control, TF, simple robot)
The previous step of this ros2arduino was to support ROS2 of the TB3 burger.
And now we want to create a library that is commonly available on the Arduino as well as the TB3 burger.
The Github Repository is this link.
The code that is currently in use is from TB3.
But, it can not be used on general arduino boards yet because it depends on microRTPS.
Anyway, since this is open source, I hope you will discuss and contribute together if you want.
Here are some of the things that I think we need to discuss.
Build system : for Arduino IDE’s compile method. (@Ingo_Lutkebohle mentioned modm as one of the considerations.)
S/W architecture
Programming language version
Etc…
I think we can not make it perfect from the beginning.
We will continue to develop for the release and hope that this discussion will lead to a better library.
Glad to see other people are interested in this. I’ve been looking at this myself in my free time. I think there is a bigger opportunity here beyond just support for Arduino to provide a ROS client library to allow any microcontroller application to connect with ROS using DDS-XRCE.
I’ve got an initial draft of the interfaces already defined for a ROS Client Library for MicroControllers (rcluc) that has its own rmw abstraction layer to allow the DDS-XRCE implementation to be interchangeable and focuses on having no dynamic allocation. I’d love if we could work together to get some of the ideas from that incorporated.
Cool! I personally like to allocate memory statically!
I think it would be nice if you could share your thoughts here. (Especially the interface you have drafted)
I’m working on getting what I’ve already done through my company’s open sourcing sign off policy so that I can share it here.
The core idea of it was that it would contain its own rcl and rmw layers. The rcl layer would handle some of the ROS specific logic like adding the prefixes to topic names before handing it off to the rmw implementation. The memory for Nodes, Topics, and Buffers was all allocated statically and controlled via a config file that the application would provide. The rcl layer handled most of the memory management of the preallocated buffers for the create functions so that the rmw implementations wouldn’t each have to reimplement that logic.
The interface into the rcl layer was agnostic of the underlying rmw layer so that you could swap out the underlying DDS-XRCE implementation relatively easily. To do this it relied on a common format for message serialize/deserialize functions. The idea was that each rmw implementation would also provide a generator to take the ROS .msg files, convert to idl, generate the C code need for serializing with their DDS-XRCE client, and generate a wrapper for that with the rcl’s message interface.
That’s very interesting. It looks like a lot of the core ideas in microROS are the same as what I was thinking. Though I had been planning to leave out RTOS support for the first iteration and add it in as configurable later.
Remember our microRTPS is now called micro-XRCE-DDS, and BTW, I am pleased to announce today we launch our first non beta release, Micro XRCE-DDS 1.0.0.
Sorry this took me so long to get posted publicly. Here is the start of what I’ve been working on. I’ve already defined an interface for the library, but am still working on the actual implementation (progress has been slow since I’ve been doing it in my free time).
For the first iteration I was designing it to just run on a bare metal micro and then planned to go back and add optional RTOS support for project wanting to build on top of an RTOS. I had also planned to write an Arduino module for it to provide the communication using the Arduino Serial interface and an example project of how to import it as an Arduino library.
Edit (Oct 26th 2018 - 4:12PM PST)
Since it sounds like there are multiple people/teams looking at this, I think it’d be great if we could schedule a virtual meeting and see if we can drive consensus on a design and a plan for implementation. I’m happy to organize that meeting if people are interested.
I am Borja from eProsima.
I think that meeting you propose is actually a good and nedded idea.
We are part of the OFERA project and would like to participate on that common effort for design and implement such ROS 2 for microcontrollers.
Currently we are doing some effort to open a discussion on possible designs for a framework like this for microcontrollers.
If you want we can join to organice this virtual meeting.
