0
$\begingroup$

Rosanswers logo

Hello. I have a problem I can’t solve by myself. I have 2 nodes inheriting from the main Node class, one of them receives data from an IMU and sends it to the other. In the other one frequency of received messages is being calculated.

When I run both nodes separately I get results close to expected ones, so eg for 50Hz publishing I receive messages with ~50Hz frequency, for 25Hz it’s also ~25Hz and so on. The issue starts when I try to start both nodes from an executor. In that case when publishing with 50Hz I receive messages with about 37-38 Hz, for 25Hz - ~18-19Hz and so on. Generally for every frequency above 1 Hz I receive messages with about 2/3-3/4 of the publishing frequency. I tried both single-threaded and multi-threaded executor but it doesn’t seem to change anything, nor does toggling the intra-process communication in nodes’ constructors. I’ve also tried modifying QoS options of this particular connection on both ends but with no effect. The publishing node has been confirmed to publish data with configured frequency.

I'm working on BeagleBone Green Wireless board with 4.4.113-ti-r149 linux kernel. I'm using ros2 ardent latest version (I updated this month but I am not aware if the issue was present before or not).

Publisher Node: https://github.com/GroupOfRobots/RysROS2/blob/master/src/rys_base/sensor_imu/src/IMUNode.cpp

Subscriber Node: https://github.com/GroupOfRobots/RysROS2/blob/master/src/rys_base/motors_controller/src/MotorsControllerNode.cpp

Launching with executors: https://github.com/GroupOfRobots/RysROS2/tree/master/src/rys_base/launch/src


Originally posted by Dangield on ROS Answers with karma: 16 on 2018-04-20

Post score: 0


Original comments

Comment by gvdhoorn on 2018-04-24:
Thanks for reporting back how you solved it.

Could you please post that as an answer yourself, and then accept your own answer?

We don't normally close questions here on ROS Answers if they have an actual answer.

Comment by gvdhoorn on 2018-04-24:
Just accepted it for you.

Thanks for posting the answer.

Comment by Dangield on 2018-04-24:
Of course. Sorry for inconvenience.

Comment by William on 2018-04-26:
@Dangield I'm glad you figured it out, sorry I didn't have time to dig into it myself.

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

I found the solution. It seems that it was caused by a rclcpp::sleep_for() found in a different node ran from this executor.


Originally posted by Dangield with karma: 16 on 2018-04-24

This answer was ACCEPTED on the original site

Post score: 0


Original comments

Comment by William on 2018-04-26:
Is it possible you could link to the line (permalink, not a branch in case you change it) which was using the sleep_for()? I'm curious where the sleep_for() was and as to why it was blocking all your multi-threaded executor threads.

Comment by Dangield on 2018-05-15:
Sorry, didn't see your comment earlier. It's here. There is a for loop with sleep_for() in it, that seemed to be the problem.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.