QoS error when running costum node

[gmptrr98]

So I tried making my own custom node in python, subscribed to /dock and /ir_intensity nodes and publishing on /cmd_vel. The node worked perfectly in simulation but when trying to make it run on the real robot it can publish on /cmd_vel with no problem, making the robot move as intended, but can't read from the two topics due to a QoS error.

I tried running Coverage, from the examples, and it runs with no problem so I think it can't be a connection error. What am I doing wrong? What should I try to fix this?
Thank as always!

[alsora]

Hi @gmptrr98, this error indicates that there is a QoS mismatch between the subscriptions in your application and the publishers on the robot (and also there's probably a bug in the simulator since it should use the same QoS as the real robot).

The publishers on the robot use Best Effort reliability.
So, if your subscriptions use "Reliable" reliability, they will not be able to communicate.

To check the QoS for a robot entity, you can use for example: ros2 topic info --verbose /dock

I recommend to use the qos_profile_sensor_data QoS profile in your subscriptions.
For example in Python you can do:

from rclpy.qos import qos_profile_sensor_data
....
subscription = node.create_subscription(
    Dock,
    "dock",
    dock_callback,
    qos_profile_sensor_data)

For more details on ROS 2 QoS, have a look at https://docs.ros.org/en/rolling/Concepts/About-Quality-of-Service-Settings.html.
The long story short is that a publisher provides a maximum qos, a subscriber requests a minimum qos.
The publishers on the robot offer at maximum "best effort", but your subscribers are requesting at minimum "reliable"

[gmptrr98]

Is there something I could do for QoS also for publishing? While information I get from the subscribed node is node working perfectly sometimes the Robot stops moving, so it's probably due to some information lost during the communication. Right now to publish on /cmd_vel I'm doing the following:

self.publisher= self.create_publisher(Twist, 'cmd_vel', 10)

What should I replace 10 with?
Grazie come sempre Alberto, anche io sono italiano :)

[alsora]

The 10 is a short-hand notation for constructing a quality of service object with reliability "reliable" and history depth 10.
(note that history depth is not particularly useful for this publisher, as we don't want to re-send old velocity command messages).

I would be surprised if your issue is related to a QoS problem or to data-loss during the communication.
At what frequency are you publishing velocity commands? The robot usually keeps executing the last velocity command for a while, but it will stop if it doesn't receive any new command within 500 milliseconds.
I would expect a publish frequency of 20Hz to be sufficient to get good results.

Piacere di conoscerti! Spero ti stia divertendo con il Create 3!

[gmptrr98]

I was working exactly at 500ms, now I'm using 50ms and it's working perfectly.
Thank you for the explanation and for the help!