Slow publishing rate since update about micro_ros_espidf_component HOT 11 CLOSED

Which was your previous commit and the current one? I need this to check the changes.

Also, can you share your code so we can check how you are creating the entities?

from micro_ros_espidf_component.

We also just tried increasing the frequency of the int32_publisher_custom_transport example and it seems to be capped at 10hz.
Have you been able to increase that?

Our previous commit was the following:
commit 97aba34f40354ed97abd575c9433a336c4ec61db (HEAD -> foxy, origin/foxy, origin/HEAD) Author: donRaphaco <[email protected]> Date: Fri Apr 9 13:36:52 2021 +0200

from micro_ros_espidf_component.

We are also a bit confused on the micro_ros source/build process, it seems that even if we check out the earlier commit, we are still obtaining a new version when building.
For example, the old <rmw_uros/options.h> is not available even after checkout. It seems as tho micro_ros_component will always pull the latest repos it needs to compile?

from micro_ros_espidf_component.

I have been able to replicate the problem, working on that.

from micro_ros_espidf_component.

okay great, thanks
btw we also noticed that when using a similar paradigm to your multithread example we then get a split of 5hz per publisher. Might help you narrow down the issue.

from micro_ros_espidf_component.

This should solve your issue: #91. Pull the repo and rebuild the whole library when merged.

It is related with the heartbeat process in reliable communications. In fact with your current setup, if you make a best effort publisher (which is recommended for those rates), it will be faster than 10 Hz. With the patch that I'm applying the reliable publisher should reach at least 60 Hz.

from micro_ros_espidf_component.

Okay thanks
So if I'm understanding you correctly, using the best effort publisher we will be able to reach the 150hz we were able to achieve previously?

from micro_ros_espidf_component.

Awesome, this fixed our problem.
We have a quick follow-up question tho, is there any documentation on these flags?
We were not aware of "-DUCLIENT_MIN_HEARTBEAT_TIME_INTERVAL=1" and are also wondering what "-DUCLIENT_PROFILE_MULTITHREAD=ON" does exactly?
We do have a mutlithreaded node with two publishers running and would like to make it as stable as possible.
Thanks

from micro_ros_espidf_component.

UCLIENT_MIN_HEARTBEAT_TIME_INTERVAL is documented here: https://micro-xrce-dds.docs.eprosima.com/en/latest/client.html?highlight=UCLIENT_MIN_HEARTBEAT_TIME_INTERVAL#configurations

DUCLIENT_PROFILE_MULTITHREAD allows to use an XRCE-DDS session (the micro-ROS middleware) from different threads or tasks using internal mutexes. By default the middleware is not locked and access from multiple threads will cause probrems.

Regarding best-effort vs reliable in the XRCE-DDS protocol, you can check here: https://micro-xrce-dds.docs.eprosima.com/en/latest/client.html?highlight=reliable#streams

from micro_ros_espidf_component.

I'm closing, do not hesitate to reopen if you have more problems.

from micro_ros_espidf_component.

Thanks for the info and your help! All good for now 👍

from micro_ros_espidf_component.