Switch to use sensor_data qos setting for short queue sizes.

[tfoote]

@chapulina I think that this is the best default profile to use. It's not exactly the 1 queue size but it's close at 5.

[chapulina]

Thanks for the PR, @tfoote ! Do you have an idea why the test now fails on this line? It looks like the odom message is never received. I'm debugging a bit here.

[chapulina]

Humm yeah it's not immediately clear to me why the QoS settings break the test. I checked that the plugin receives the command and is publishing odom messages, but the callback on the test is never called. Maybe you have an idea? Otherwise I can try to poke deeper.

[chapulina]

As discussed offline, the test was changed to use the same QoS settings as the plugin and now it passes: 315bfde. I'll add a note to the migration page.

I'll merge this if CI comes back clean.

[dhood]

Changing to the sensor data profile changes the depth but also the reliability (which I think you've spoken about offline). This PR has the following side-effects wrt reliability that we may want to reconsider:

• makes the odom messages only subscribable by best effort subscriptions (which is why the test needed to be updated). I would recommend just lowering the depth and leaving reliable reliability offered, so that the subscriber can choose if they want reliable or best effort.
• makes the cmd_vel subscription best effort (if it's published at low frequency, missing a message once will mean it's missed forever). Best effort might be appropriate here if we expect it the messages to always come at high frequency and we don't want to bother processing old dropped messages, but reliable seems safer if that isn't always going to be the case (though that would limit it to only reliable publishers, unless the qos is modified externally).

[chapulina]

Thanks for taking a look at this, @dhood . I don't understand much about QoS settings yet, but all your comments sound reasonable. Would you be up for making a quick PR with the suggestions?