Yes, that include the comms stacks.
The wireless communication is IEEE 802.15.4. In the user application point of view, RIOT provides a net interface similar to the interfaces you can find with Linux. RIOT have a fully working UDP/IPv6 stack (I use it in my project). I think TCP is also working, but I never used it, same for IPv4. About Ethernet, it depends on how you would use it.
Before choosing between NDN and MQTT, let me quickly list the pros and cons
NDN
replace the full TCP/UDP/IP stack
is topic-oriented by design
is decentralized by design
can be used on top of TCP/UDP/IP as well as directly on the MAC Layer (ethernet, 802.15.4, …)
is still an active research topic and not standardized
currently don’t provide the ROS2 communication patterns (Pub/Sub, Services)
(but I implemented a beginning of Pub/Sub)
MQTT-SN
is based on UDP/IP
is topic-oriented by design
provide a Pub/Sub communication that fits well ROS.
is quite standardized
is centralized by design (needs a broker)
don’t provide the ROS’ Services communication pattern
For me, as a PhD student, NDN seems more interesting than MQTT, but harder to integrate in ROS2. But the thing is that I need to compare any of my implementation to something. Since I was not able to use DDS on my hardware, I just tried these 2 solutions, which may not be the only two I will try.
I finally was able to integrate my modules with the “normal” ROS2 build system (now you can use “ament build”). The thing is that I needed to modify the build steps of some standards packages (rcl, std_msgs, builtin_interfaces, rosidl_generator_c) to make it work with RIOT’s build system. To make it short, instead of compiling the sources with ament/cmake, I just generate Makefiles used by RIOT to compile the final application. Any feedback on how I managed that would be appreciated ^^.
I also began to experiment with rosidl to generate some serialization code, and currently the project can handle messages composed of strings, (u)int32 and (u)int64 fields. Serialization is made with cbor.
I haven’t posted news from the project for a long time now, but here is the summary of my last developments :
I have updated the ros2 packages I use from beta2 to arment !
I have improved the build system integration between Ament and RIOT, now the build process looks much more like the official crosscompilation for arm.
I don’t need to modify the official packages’ CMakeLists.txt anymore, so that future update will be easier.
In the other hand, I also removed some features that I have no time to maintain anymore (be understanding, I’m working alone on this project ) :
removed rmw_mqtt implementation
removed some examples
Also, my implementation of rclc (ROS Client Library for C) has recently been merged with the official rclc repository (many thanks to the reviewers). I could not reach the point where it would be included in the official ROS2 stack, but at least it is usable with the normal ROS2 stack and the RIOT-ROS2 stack ! You can check these examples for trying with the normal stack.
My roadmap for this year is :
to complete rclc so that it may be included in a future ROS2 version
to have a full implementation of topics, services and discovery with rmw_ndn.
to update to newer versions of RIOT
to write some example tutorials for using on a microcontroller (the main benefit of my project )
to build a complete autonomous robot with this project (and take part to the Eurobot competition)
Of course any contribution is welcome, even just saying that it does not work on your computer !
I am following your work since the beginning because I am very interested in using ROS2 on microcontrollers.
I remember that you used to use the 802.15.4 wireless connectivity of the Atmel SAMR21 to communicate between 2 microcontrollers. Do you have a wired communication now or a least one with a computer? I have quickly looked at the repo and did not find the answer.
Because, as a Eurobot competitor, I am not used of the wireless communication between the components inside a robot.
Hey @astralien3000! Pretty cool to hear about your updates. Very well done and thanks for sharing it and keeping all of us posted.
We are also looking at ROS 2 in microcontrollers as part of a European project and after a look at the structure of the code, I think we can inspire quite a bit from you. Our objective, is to end up with a “framework for microcontrollers” that should supports different alternatives for underlying RTOS, communication middlewares, etc. In particular, for the RTOS, we are looking at using NuttX (link to our fork). Given the maturity of your work (which to me seems much more advanced than ours) I think it’s worth to try re-using your structure and eventually converge if possible.
Provided that this sounds good to you, I’m up for spending some time researching your code and try putting together a prototype of your system with NuttX as the underlying RTOS. Would you be willing to support us if we do so? Ideally we could end up submitting a PR to your code with NuttX support (which from a hardware perspective, opens up your system to many more possibilities). How does this sound?
@rreignier, I currently haven’t managed to do it on wired communication yet. But, like you, I will need some wired communication for Eurobot. I plan to try at least USB/UART and CAN during the (few) remaining months before the competition. Normally, UART (over USB) between a board and a computer should be already possible thanks to RIOT’s module “ethos”, and it would be a great first tutorial if I manage to make it work, actually ! ^^ Even better than board to board communication.
@vmayoral, it sounds interesting, indeed. With my development of the 2 last months, I feel it’s possible to use different underlying OS quite easily now, I was even thinking about porting ROS2 to the Arduino framework (when I would have the time). I would try to help you ! I’m looking forward to have more information on your project.
Fantastic! I’ll allocate time for it and have a look then in the following weeks.
I’m also eager to share more. I hope this will happen soon. Certainly, knowing attitudes like yours, I’ll advocate to try and establish paths for contributions as soon as possible.
Hello @rreignier,
After your question about board to computer communication, I made a proof of concept.
Now if you read the README, you should find a way to make a (RIOT) native ros2 node communicate with a node that is embedded on a microcontroller.
If you want to try this example on your hardware, I would be happy to help you if there is any problem.
Just a little warning : the microcontroller version seems to crash because of a bug I introduced recently. I need to work on that, so if the app complains about heap allocation problem or goes crazy (printing junk on stdout), it’s a known bug. Just don’t control your motors with that for the moment !
I will start looking at how to integrate (if possible) your work in ours (I’m happy interacting publicly here but let me know if you’d prefer a more private channel).
Yes, I think it would be better to use an other channel for some things we would discuss. I have sent you an email.
I have some comments on your diagram :
Does urcl refers to a language-specific client lib ? or to rcl, adapted to microcontollers ?
In the first case, I would say that it would be nice to use and complete rclc
In the second case, I would say that using rcl is better, even if the use of malloc is not the best choice for microcontollers, it is quite well designed, and the most important is that rcl would be the glue between normal ROS2 and ROS2 for microcontrollers.
Why defining a urmw interface ? What would be different from rmw ?
The problem with RTOS abstraction is that, beside well known standards (POSIX, socket, libc, …), there is no library that manage an application layer protocol (MQTT, HTTP, CoAP, etc…) that is ported to several RTOS : each RTOS has it’s specific solution/interface.
The version of RIOT used have been updated, enabling the support of new boards and features.
I have implemented rmw_ndn for the “real” ROS2 stack, so that it can be chosen in place of the default rmw_fastrtps. Here is the repository.
This new implementation is more advanced than the one based on ndn-riot. For instance, it supports pub/sub with multiple publishers (multiple subscribers was already supported) and discovery.
I have managed to make the two stacks (RIOT-ROS2 and ROS2 with rmw_ndn) communicate with eachother.
Yes, I was expecting the Arduino port would receive keen interest. It is still low in my priority list, but I will try to sustain it regularly. Having a fully functional port seems quite far away, but a least compiling the stack with a fake ROS MiddleWare may be possible soon. I will keep you in touch !
Yes it is possible, my project is made to easily switch the RTOS and the protocol used. The problem is that I have no time anymore to make this kind of heavy development. I will try to help anyone that wants to add DDS-XRCE, but I can’t do it myself alone.
@astralien3000, I am also interested in RIOT project. I think that it is a very efficient idea to put various sensors in the environment by using ROS and to collect the sensor information and use the robot like the following papers. The following papers used ROS1. However, ROS2 is more environmentally friendly than ROS1. I want to think about your ideas and talk together. The RIOT is a wonderful project.