You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The performance of the default Python executors in ROS2 is quite bad when is comes to throughput, latency and system load compared to e.g. ROS1 (see e.g. this). Common high frequency subscriptions like /tf easily overwhelm it or at least result in significant CPU load, that can not fully be explained by the slower nature of Python itself.
Due to the significant improvements brought by the events executor for cpp in terms of system utilization, the question arises if the same is possible for the python executor design.
Are there any plans from your side for an events based python executor design? And this this is not the case, what are your tips if somebody would want to implement it? Are there any pitfalls that come to your mind.
The text was updated successfully, but these errors were encountered:
This isn't currently on our roadmap.
We think that there's still some work to do on the rclcpp side.
The events-executor has just been merged to rclcpp and it will be part of the upcoming ROS 2 Iron release.
The next objective is to make it the default executor.
However, there shouldn't be technical blockers to do a rclpy version.
The events-executor relies on some hooks to register callbacks when data is available that are implemented in rcl/rmw, so they can be exposed and used also in the python client libraries
The performance of the default Python executors in ROS2 is quite bad when is comes to throughput, latency and system load compared to e.g. ROS1 (see e.g. this). Common high frequency subscriptions like
/tf
easily overwhelm it or at least result in significant CPU load, that can not fully be explained by the slower nature of Python itself.Due to the significant improvements brought by the events executor for cpp in terms of system utilization, the question arises if the same is possible for the python executor design.
Are there any plans from your side for an events based python executor design? And this this is not the case, what are your tips if somebody would want to implement it? Are there any pitfalls that come to your mind.
The text was updated successfully, but these errors were encountered: