Add support for `on sample lost` event

[ivanpauno]

Feature request

Feature description

Similar to previously added events like ros2/ros2#822 or on liveliness lost, it would be good to add support to on sample lost events (which might be really helpful when debugging communication issues).

For ROS, on message lost might be a more appropriate name.

For DDS based rmw implementations, implementing this should be pretty straightforward:

• Connext: sample lost status, data reader listener callbacks.
• FastRTPS: AFAIS, it's not supported yet: https://github.com/eProsima/Fast-RTPS/blob/8842bdd35bac66b731fe3f2f5e79fe7417355c4b/include/fastdds/rtps/reader/ReaderListener.h#L41.
• CycloneDDS: https://github.com/eclipse-cyclonedds/cyclonedds/blob/623b35d83b9d061187c816f37f4a92798f3b35d1/src/core/ddsc/include/dds/ddsc/dds_public_listener.h#L37.

Detailed list of tasks: #226 (comment)

Implementation considerations

For rmw implementations that don't support the feature, they can return RMW_RET_UNSUPPORTED, as for example fastrtps already does when the creation of an ON_*_INCOMPATIBLE_QOS event is requested.

DDS also support a status callback called on sample rejected. The difference with the previous one, is that this one reflects a reader not having resources to receive the sample and not a communication problem. I think it would be interesting to add support to that one too, maybe both can be wrapped in the same event?

[ivanpauno]

maybe both can be wrapped in the same event?

That sound like possible, the status definition could be:

typedef struct RMW_PUBLIC_TYPE rmw_message_lost_status_t
{
  size_t total_count; // total number of messages lost
  size_t total_count_change; // number of messages lost since last callback
  char * reason; // reason why the message was lost/rejected
} rmw_liveliness_changed_status_t;

Based on both DDS status definitions (1, 2), we can use that to wrap both on sample lost and on sample rejected.

[ivanpauno]

@jacobperron @clalancette @wjwwood for feedback (no urgency right now, as an implementation wouldn't start until Foxy gets released).

[fujitatomoya]

This is really helpful for our use case. we can expect and accept message drops sometimes with wireless network for edge devices, but what's better is user application is likely to be notified if message drops.

[fujitatomoya]

different topic, but we'd also really like to see this in statistics for actual use case.

[ivanpauno]

Tasks:

• rmw
• rmw_connext
• rmw_cyclonedds
• rcl
• rclcpp
• rclpy
• demo using rclcpp
• Open ticket in rmw_fastrtps to track adding the feature in the future.
• Create rclpy demo (Add rclpy message lost status event demo demos#457)
• Add option in ros2 topic echo to report lost messages (Add option to ros2 topic echo to report lost messages ros2cli#542).
• Write tutorial for https://index.ros.org/doc/ros2/Tutorials/#tutorials (probably, update one of the existing tutorials)

[jacobperron]

I'm not convinced that we want to combine "sample lost" and "sample rejected" based on the discussion in ros2/rmw_cyclonedds#192 (comment). It'd be nice to have more DDS-inclined folks chime in.

[ivanpauno]

I'm not convinced that we want to combine "sample lost" and "sample rejected" based on the discussion in ros2/rmw_cyclonedds#192 (comment). It'd be nice to have more DDS-inclined folks chime in.

Yes, I agree.
I will address that comment soon.