ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | Q&A answers.ros.org
Ask Your Question
2

Node publishes only half of expected frequency

asked 2022-02-15 03:40:31 -0600

Gintecc gravatar image

I'm writing a ROS2 C++ node for a camera. In the code we create a callback from the camera driver which then publishes the image. When we measure the topic frequency we only get half the actual callback frequency. If we set the camera to 10fps we get around 5fps in ROS and when we double the camera rate to 20fps we get around 10fps in ROS. This leads us to believe that we are not limited in processing. The topic frequency is measured with ros2 topic hz and for the callback measuring we use this:

void BufferReceived(void *callBackOwner, BGAPI2::Buffer *pBufferFilled)

{
    count++;
    // Pack the OpenCV image into the ROS image.
    sensor_msgs::msg::Image::UniquePtr msg(new sensor_msgs::msg::Image());
    // Read from buffer and convert to ros msg
    pub_->publish(std::move(msg));

    if (count == 60){
        count = 0;
        auto duration = std::chrono::system_clock::now() - start_time;

        auto fps = 60.0 / (duration.count());
        std::cout << "fps: " << fps * 1000000000 << std::endl;
        start_time = std::chrono::system_clock::now();
    }
}

We have written something similar in Python and there we had no problems for it to publish at the correct frequency. We work in ROS galactic with the Fast DDS middleware. I don't really have an idea about how I should start to debug this, because everything is working as expected with the exception of losing some frames.

This is how we create the publisher:

pub_ = this->create_publisher<sensor_msgs::msg::Image>("/output", rclcpp::SystemDefaultsQoS());

Whereby we modified the default QOS via the XML to be reliable and to have sufficiently big buffers.

<?xml version="1.0" encoding="UTF-8" ?>
<profiles xmlns="http://www.eprosima.com/XMLSchemas/fastRTPS_Profiles">
<transport_descriptors>
    <!-- Create a descriptor for the new transport -->
    <transport_descriptor>
        <transport_id>shm_transport</transport_id>
        <type>SHM</type>
        <!-- <sendBufferSize>100000000</sendBufferSize>
        <receiveBufferSize>100000000</receiveBufferSize> -->
        <segment_size>1000000000</segment_size>
        <maxMessageSize>10000000</maxMessageSize>
    </transport_descriptor>
</transport_descriptors>

<participant profile_name="SHMParticipant" is_default_profile="true">
    <rtps>
        <!-- Link the Transport Layer to the Participant -->
        <userTransports>
            <transport_id>shm_transport</transport_id>
        </userTransports>
    </rtps>
</participant>

<data_writer profile_name="default publisher profile" is_default_profile="true">
    <qos>
        <publishMode>
            <kind>SYNCHRONOUS</kind>
        </publishMode>
        <durability>
            <kind>VOLATILE</kind>
        </durability>
        <reliability>
            <kind>RELIABLE</kind>
        </reliability>
    </qos>
    <topic>
        <historyQos>
            <kind>KEEP_LAST</kind>
            <depth>20</depth>
        </historyQos>
    </topic>
    <historyMemoryPolicy>DYNAMIC</historyMemoryPolicy>
</data_writer>

<data_reader profile_name="default subscriber profile" is_default_profile="true">
    <qos>
        <durability>
            <kind>VOLATILE</kind>
        </durability>
        <reliability>
            <kind>RELIABLE</kind>
        </reliability>
    </qos>
    <historyMemoryPolicy>DYNAMIC</historyMemoryPolicy>
    <topic>
        <historyQos>
            <kind>KEEP_LAST</kind>
            <depth>20</depth>
        </historyQos>
    </topic>

</data_reader>

</profiles>

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
0

answered 2022-02-15 07:20:15 -0600

Gintecc gravatar image

Apparently ros2 topic hz is super unreliable, if I write a simple python script to record the frequency I get the expected result.

edit flag offensive delete link more

Comments

2

If there isn't already an issue open, it would be good to report this, as the sole purpose of ros2 topic hz is to give an accurate estimate of the rate of messages published on a specific topic.

If that doesn't work, or the reported number isn't reliable, it would seem ros2 topic hz does not function according to specifications.

Please consider taking the time to report it and describe your experiences. Unknown problems cannot be fixed.

gvdhoorn gravatar image gvdhoorn  ( 2022-02-15 07:38:24 -0600 )edit

The fact that ROS2 is slow to deserialize messages, and that for this reason "ros2 topic hz" can give gross underestimates of the actual frequency is apparently well known but not well documented and not fixed, and for this reason re-learned by every single ROS2 user who for the first time uses "ros2 topic hz" on hardware that is too slow to deserialize (I believe in Python!!!) the message. Example here.

Bernd Pfrommer gravatar image Bernd Pfrommer  ( 2022-08-11 13:10:21 -0600 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

2 followers

Stats

Asked: 2022-02-15 03:40:31 -0600

Seen: 143 times

Last updated: Feb 15