pablogs9
commented
2 years ago Provide steps for replicating this issue. Try to avoid extra configuration (FreeRTOS). We would like to replicate this slow behavior of the micro-ROS API.
If this behavior is not replicable without FreeRTOS, it might be related to your task's configuration. Remember that micro-ROS is not thread-safe and you need to enable a flag in the middleware: https://github.com/eProsima/Micro-XRCE-DDS-Client/blob/fda7242ed93a81915a75157a56be11fcbd025a98/CMakeLists.txt#L67
MiguelMartinez-HAW
I am trying to use the FreeRTOS scheduler to run microROS on a RPi Pico.
Steps to reproduce the issue
I followed the tutorial mentioned above. Then I expanded the basic example to have two publishers and two subscribers. From ROS2, I have two publishers; then, the two subscribers in the Pico would read the data being published, modify it and publish it, which I could monitor from the terminal using the echo command. That worked well.
On the other hand, I followed this tutorial to make use of the FreeRTOS and turn on some LEDs. That also worked well.
Finally, I combined both programs, so I basically put what's on the main loop of the microROS program inside a function called run_uros and created a task with FreeRTOS to run it as:
Expected behavior
I am not sure if this is the right approach to use FreeRTOS together with microROS, but given that it runs only one task, I would expect it to run the same. The idea is that later I could implement other tasks, such as reading sensors and controlling actuators.
Actual behavior
The behavior is almost as expected. The only problem that I'm having is that I am receiving data from the publishers in the MCU very slowly. I publish data through ROS2 and I have to wait about 15 seconds to see it published by the Pico. Am I wrong for using this approach? Is there a better approach? Should I put the microROS callbacks in FreeRTOS tasks? Any guidance would be appreciated.