Lately, more and more users, partners and community members have been gently hinting at a possible and desirable integration of the mostly famous Arduino, an IDE designed to fit into extremely resource-constrained devices, with micro-ROS, given its special talent to implant ROS 2 nodes into MCU-operated sensors and actuators.
At present, we already ported it to three boards, namely: the the OpenCR 1.0 and the Teensy 3.2 and 4.0 (take a look at the discussion here), with the latter being especially appealing in that it’s the fisrt MCU that works at 600 MHz.
Anyone who wants to give it a try with any other board supporting Arduino (resource-compatible with the micro-ROS library) is very welcome!
As a final remark, we mention that this new integration paves the way for envisioning a not-so-far-in-the-future bare-metal support for micro-ROS.
Awesome to see! Do you know how much memory it takes to run on the Arduino? A consistent problem I have with arduinos is that they’re so small that I have to nickel and dime small amounts of memory to get the 2-3 things I want it to do done.
Edit: I see support for OpenCR and teensy’s. Is there support for Unos / Megas (I have piles of them…)?
Regarding memory profiling, we just published last week a really complete study: you can check it here. Also, have a micro-ROS middleware (Micro XRCE-DDS Client) memory profiling, check it here.
As you can see, there is a lot of potential room for improvement, but we are working hard.
Regarding the Unos and Megas, they are 8 bits MCUs with very few RAM memory… maybe just an XRCE-DDS Client app could fit. Internally we are thinking about a mini layer on top of XRCE with the same RCLC API, maybe it is a cool possibility for this tiny 8-bits ARV.
Given those are very commonly used COTS microcontrollers for education/hobbyists, shouldnt we find some way to support them for the embedded working group (even if that means porting serial)?
This is a very interesting discussion @smac. I’m not into the micro-ROS project since the beginning but as far as I know, in the initial designs and proposals, the micro-ROS MCU target was defined as a device enabled to run an RTOS. This sets the minimum requirements to a few tens of kB of RAM memory and about a hundred kB of Flash memory. Also, 32-bits architectures were targeted. Anyhow, I’ve always thought that a ROS 2 embedded solution should be wider in terms of architecture.
On one side, I think that including these 8-bits AVRs would be nice to spread the usage of micro-ROS to all those places where there is an Arduino inside a drawer. And there must be millions of them. If we had this, micro-ROS could be a fair replacement for rosserial, and also it would offer advanced features such as executors, services, or actions.
On the other side, I see that for the price we paid ten years ago for an 8 bit AVR for education/hobbyists purposes now we can have modern 32 bits solutions such as Adafruir Feather Series, Arduino MKR Series or these brand new SparkFun MicroMod. In all of them, micro-ROS should run seamlessly.
In summary, I would like to do a hands-on test, maybe start testing the Micro XRCE-DDS middleware in some 8-bit AVR and if everything seems ok, try to understand how can we slim down the micro-ROS layers. For sure this is going to be challenging, so if anyone is interested in helping please contact us.
Hi @smac and @pablogs
Indeed the idea of complementing the actual micro-ROS stack with an alternative solution with only the middleware and a thinner layer on top of it has been circling around in the team and community for some time now. At this height, I don’t see any major inconvenience if we start thinking more seriously about including it into our 2021 roadmap.
If so, the more participation from the community, the better!
Yes at first it can feel like a fun puzzle to fit everything onto an 8-bit microcontroller with almost no RAM and there are tons of them out there.
It is also true, though, that nice big 32-bit microcontrollers are so inexpensive now, it is silly for people to continue to spend so much money on Uno and Mega boards.
It might work if micro-ROS was stripped down to nothing more than a state machine and active objects running on bare metal just processing micro DDS messages.
I tend to find, though, that all the time I spend stripping everything away to make it fit is not worth it, only to end up with something so restricted that it is tedious to use.
Hi @altineller! We checked the resources of the tm4c123, and can confirm that micro-ROS should fit into this device! Could you also provide some more details on your current toolchain and build system?
Hello @FraFin, currently I am using a modified version of https://github.com/vmatos/rosserial_tivac, it is basically rosserial arduino ported to TM4C123. Over the times I learned tm4c123 intricately, and I have ported ROS’s complementary filter on the tm4c123. (https://github.com/altineller/fximu2) I use the USB-CDC on the tm4c123, which gives me a virtual serial port, and I use ros serial over this serial link. Which makes them kind of plug and play.
I am looking forward to use micro-ROS on my devices to make them ROS2 compatible. Where can I start from?
Hello @altineller, I see that you have a CMake toolchain in the rosserial_tivac repo. I think that the easiest solution is to start building the micro-ROS stack as a static library plus a set of headers.
Using the micro-ROS Build System you can easily do this. Check here. Once you have installed it following the repo instructions you can do:
ros2 run micro_ros_setup create_firmware_ws.sh generate_lib
cp [YOUR CUSTOM TRANSPORT .C] firmware/mcu_ws/eProsima/Micro-XRCE-DDS-Client/src/c/profile/transport/serial/serial_transport_external.c
cp [YOUR CUSTOM TRANSPORT .H] firmware/mcu_ws/eProsima/Micro-XRCE-DDS-Client/include/uxr/client/profile/transport/serial/serial_transport_external.h
ros2 run micro_ros_setup build_firmware.sh [CMAKE TOOLCHAIN] [COLCON META FILE]
This should create a firmware/build/libmicroros.a and a firmware/build/include/ ready to be linked against your application.
You can check examples of this CMake toolchains and colcon meta files here and here.
The former one is how we use this procedure to generate micro-ROS precompiled libraries for Arduino.
The transport layer can be tricky, but if you are implementing USB-CDC transport it is just filling a set of functions similar to this.
For sure we can guide you along this process. If you require more information open an issue in our build system repo and we can chat there about how to port your MCU.
Hi FraFin, I was wondering if its possible to support Teensy 3.5? I m working on it now, but don’t know how to start. I’ll be appreciated if you can help me!
Hi @UncleMask! Yes, in principle it should be totally doable. As a matter of fact, we are planning to do it ourselves if that can be interesting for you and the community.
Hello dear,
I have tried to build static library (generate_lib) for stm32g474 which is based on Cortex-M4f and unfortunately I was not successful. Also your links link1 and link2 were not about cortex-m4f. How can I exactly to build my micro-ros library for stm32g474.
If I can build it for that micro-controller, can I use it for other stm32g4 series?
We need more details in order to help you @Masoud_Iranmehr, could you open an issue in our Github repo and explain in detail which is your error, which transport are you using, which CMake toolchain have you configured, the colcon meta?
