micro-ROS-Agent
micro-ROS-Agent copied to clipboard
micro-ROS
Running uROS on the MCU without the Agent running on a PC
Hey @pablogs9! @CLansdaleBEC and I were talking about what it looks like for the MCU to run its respective nodes without the Agent running.
I could not quite recall if you had previously mentioned that it was a known limitation the MCU needed to communicate to the agent and then back down.
For instance: Node A on MCU publishes message "Hello" -> Agent on PC -> Node B on MCU subscribes to topic and receives message "Hello"
Rather than Node A publishes message -> Node B subscribes to topic and receives message.
I hope my question makes sense, but for our use case we are utilising the MCU as a safety critical system (meaning it handles some logic to ensure that in the fail case of it being unable to communicate with our PC, we publish commands to the rest of the MCU nodes so they can handle their respective parts).
Hello @edesta-be and @CLansdaleBEC, this is a key point of discussion in the micro-ROS environment.
Initially, XRCE-DDS (the micro-ROS middleware) was designed as a wire protocol for communicating resource-constrained devices with the DDS (the ROS 2 middleware). This is because usually DDS libraries are complex and require lot of resources in terms of memory, threads, networking... So this is where this client-agent approach appears: the client only knows how to to talk a simple wire protocol for describing what it wants to do in the DDS world (XRCE), and the agent knows how to use DDS.
But of course, as micro-ROS evolves, we started to see the necessity of having a micro-ROS to micro-ROS communication. This is not an easy issue to solve due to the variety of platforms and transports supported by micro-ROS but we have implemented an initial brokerless P2P approach that is very experimental. Basically:
- It uses broadcast UDP communications to send messages.
- It uses the same serialization library: micro-CDR.
- It adds a minimal header in order to identify message metadata.
- It is integrated into the XRCE-DDS library without any API change.
- It supports pub/sub and request/response (services in ROS 2)
- It has been tested in micro-ROS for Linux and in ESP32 wifi communication (based on LwIP, so I guess that other LwIP-based should work).
And now the handicaps:
- It does not implement any reliability mechanism, only best-effort communications (yet)
- Nodes do not "discover" each other in order to have real peer-to-peer communication, only broadcasting supported (yet)
- In the XRCE library nodes do not handle situations when P2P is activated and the client is also connected to an agent: topics may be duplicated here (yet)
- In the micro-ROS RMW if you enable P2P, the node won't communicate with the agent so ROS 2 won't see these micro-ROS nodes. This means that by now you have two possibilities: the one that you know, and only micro-ROS to micro-ROS.
Here you have the branch of Micro XRCE-DDS with this experimental brokerless P2P: https://github.com/eProsima/Micro-XRCE-DDS-Client/tree/feature/brokerless_p2p
And we also have prepared a branch for the micro-ROS RMW layer that enables the use of this feature in micro-ROS: https://github.com/micro-ROS/rmw-microxrcedds/tree/feature/brokerless_p2p
So, for example, in order to test a brokerless P2P nodes in a Linux host we can do:
ros2 run micro_ros_setup create_firmware_ws.sh host
# Change the branches. By now, P2P features are enabled by default in these branches.
pushd src/uros/rmw_microxrcedds
git checkout feature/brokerless_p2p
popd
pushd src/eProsima/Micro-XRCE-DDS-Client
git checkout feature/brokerless_p2p
popd
ros2 run micro_ros_setup build_firmware.sh
source install/local_setup.bash
Now you can launch a couple of nodes in two different consoles:
ros2 run micro_ros_demos_rclc int32_subscriber
ros2 run micro_ros_demos_rclc int32_publisher
You should see something like:
root@pgarrido:/uros_ws# ros2 run micro_ros_demos_rclc int32_subscriber
UDP mode => Brokerless P2P
INFO: rcl_wait timeout 1000 ms
Received: 0
Received: 1
As you can see there is communication without an agent, but this a preliminary approach. We (@FranFin @jamoralp ) really would love it if you give us feedback and tell us about your requirements and use cases because right now we are profiling the requirements for the first release of this brokerless P2P.
What would you like to see? Which features are important for you?
Thank you @pablogs9 this is really some great info! Will be running your above example to test it out.
So just one question: Could it be so that if the MCU doesnt register an Agent, it moves to Brokerless communication (as a fallback)? This means that internally, the system stays alive and keeps running. It would almost be a flag that you all would raise if the agent is present or not, and in the case the agent is not present you go to the Brokerless communication. And then vice versa, if the system starts running Brokerless and then registers an agent during the run, you transition the communication over.
In my head this is easier almost because you can leave the current communication paths untouched (the ones involving the agent).
Our specific use case -- we have an MCU that is interfacing with sensors and motors and if our agent goes down we want to ensure that we are still communicating with our peripherals.
This is a great point, next week we are going to have an internal meeting and I will talk about this fallback mechanism. Definitely it possible to implement it in the library and in the micro-ROS middleware layer.
I will come back with the decisions about this agent connection status handling.
Does your MCU use LwIP?
Sounds good! I look forward to hearing about it.
And no -- our MCU will not be using LwIP.
We are currently talking to the board via Serial. However, @CLansdaleBEC is working on talking to the board over Ethernet. (This is our preferred final destination)
Hey @pablogs9 apologies for how long it took to get back to this and just check in, also I'm happy to do any testing you need on my end with the boards I have.
Would love to support however! Ques: Will running MicroROS as a Zephyr app mitigate having to run with an agent?
Hello @edesta-be, running the micro-ROS client in Zephyr still needs to have an Agent.
Regarding the P2P brokerless mode, maybe we can talk with @FranFin in order to schedule a meeting or something to talk about your requirements.
@pablogs9 that would be amazing let me know when works and I can figure out my schedule!
Hi! Apologies for being MIA. I was hoping to check in and see how I can help out with this issue. I know you all are busy so I would be super happy to help however I can!
Let me know, looking forward to your response.
Also++ on my end, the team is super interested to see the potential of running without an agent and using uROS as a the framework for some existing projects! I thought that was pretty exciting :D
Hi @eden-desta! So, @pablogs9 has been working hard on a new Shared Memory feature, about which you can read in this PR. The implementation is complete and only pending to be merged. Basically, now the same Client with two entities matching internally can be aware of it and proceed with the communication without the Agent having to mediate it.
It would be great if you could test it and give us some feedback, also regarding whether this feature addresses your use-case. We are excited to know what you guys think of it! Hopefully, it fits your needs!
Hello @eden-desta, we have implemented some basic inter-node communication inside micro-ROS middleware. Just activate this flag in your colcon.meta. We have tested it but it still in develop branch, so some user testing will be super helpful.
If you are using combined agent + internode communications, some new features in the agent are also required, but our newest foxy and rolling dockerized micro-ROS Agents are ready to use.
Hello everyone, I write here to have a follow up on this issue. Our circumstances are similar. We have a robot Camera, drivers/Motors and some extra peripherals, that has been running on a pic32 without RTOS or Micro-ROS. We would like to introduce MicroRos, however, the current use cases is flexible in the connection to the devices, either a PC or a Tablet. This put us in an uncertain situation, would we be able to run the robot(s) smoothly just running from a tablet without a ROS2 Agent?
Thanks for your work
Hello @VBorjaDD, currently micro-ROS supports two middlewares:
- eProsima Micro XRCE-DDS is a lightweight middleware that needs an agent to interface with ROS 2. Notice that there are community support for Android in the Micro XRCE-DDS Agent: https://github.com/eProsima/Micro-XRCE-DDS-Agent/pull/280
- embeddedRTPS is an embedded RTPS implementation that does not need an agent and communicates directly with ROS2, it is available for LwIP enabled platforms and supported for STMCubeIDE and ESP-IDF
Hi @pablogs9 ,
Since I am new to this micro-ROS I have a few queries related to Embedded RTPS in Micro-ROS with respect to below USECASES ?
-
Does Embedded RTPS Required any agent or agent IP Configuration
-
Usecase1 : I have flashed publisher code with Embedded RTPS Enabled in one ESP32 Device and Another ESP32 Device with same RTPS Enabled Subscriber code both are under same network . but both are not communicating each other on same Topic without agent . what might be the issue? am i missing anything
-
Usecase2 : Instead of 2 ESP32 Devices. One devices is Embedded RTPS Enabled ESP32 device and Second Device is Linux machine with running ROS2 on device. In this case also do we require any agent running or RTPS enabling on my Linux machine side ? if yes please provide installation steps of this embedded RTPS on linux.
-
Usecase3: Does this Embedded RTPS Supports intra communication within a ESP32 Device running with two nodes on same topics as subscriber and publisher ?
Please clarify these queries i have.
@ManvithRaj
- Does Embedded RTPS Required any agent or agent IP Configuration
It does not need an agent. It communicated directly with ROS 2 via DDS.
- Usecase1 : I have flashed publisher code with Embedded RTPS Enabled in one ESP32 Device and Another ESP32 Device with same RTPS Enabled Subscriber code both are under same network . but both are not communicating each other on same Topic without agent . what might be the issue? am i missing anything
Embedded RTPS may need some configuration in order to proper work. Although we have made some integration and we have had some scenarios working with micro-ROS, it is an experimental support. For support on this middleware please check https://github.com/embedded-software-laboratory/embeddedRTPS
- Usecase2 : Instead of 2 ESP32 Devices. One devices is Embedded RTPS Enabled ESP32 device and Second Device is Linux machine with running ROS2 on device. In this case also do we require any agent running or RTPS enabling on my Linux machine side ? if yes please provide installation steps of this embedded RTPS on linux.
If you are using Embedded RTPS you do not need any agent.
- Usecase3: Does this Embedded RTPS Supports intra communication within a ESP32 Device running with two nodes on same topics as subscriber and publisher ?
For embedded RTPS support, please visit: https://github.com/embedded-software-laboratory/embeddedRTPS
@pablogs9 Thank you so much for your reply.
For query 2 as you said Embedded RTPS may need some configuration but in the link you have provided i could not get much info on that.
Could you please elaborate on this or please give any reference to it ?
In my case it is not joining multicast group and publishing the data with this experimental Embedded RTPS
@pablogs9 Hi,
I'm reaching out to inquire about the latest developments concerning micro-ROS support for agentless communication, specifically through Micro XRCE-DDS (Micro XRCE-DDS documentation). Our team is keen on exploring the possibility of establishing wireless communication directly between ROS2 devices, ideally by serializing messages on one device and deserializing them on another, without the intermediary of an agent.
Considering the constraints of our hardware, particularly the limited memory capacity, utilizing full RTPS presents challenges for us. We believe that leveraging Micro XRCE-DDS could offer a more feasible solution by significantly reducing the footprint. Could you provide an update on:
- The current progress and support for Micro XRCE-DDS in enabling agentless communication within the micro-ROS ecosystem.
- Any advancements or plans to enhance this feature, especially considering that the branch related to brokerless communication has not seen updates for the past four years.
Our objective is to streamline communication while accommodating the memory limitations of our hardware. Any insights or updates on the development in this area would be greatly appreciated.
It would be much :top: appreciated if I could send you a private message describing the issue in details. Thanks Adam :D
Hello @adamkrawczyk,
As you mentioned, the broker-less operation of Micro XRCE-DDS was a PoC that we made some years ago. Finally, we decided that this was a dead end because of the limitations and the nature of the DDS-XRCE standard.
In any case, during the last years, we have been working on DDS/RTPS compatible solutions that have been designed with embedded devices in mind and we released Safe DDS that is a highly embedded and safety certified DDS compliant implementation. Just for reference, it can run even on bare metal MCUs scenarios with footprints of less than 32 kB depending on the application architecture. Also, it is compatible with ROS 2.
If you want to know more we can arrange a meeting, just write me at pablogarrido [at] eprosima.com.
@pablogs9 I've noticed that Zephyr currently lacks support from Safe DDS. We plan to explore this setup regardless, but if there are any existing solutions or approaches for integrating Zephyr, we would appreciate your insights.