Connect rerun

[esteve]

Connect rclrs to Rerun.

Converters (copied from #4)

From std_msgs:

• Int8 -> Scalar
• Int16 -> Scalar
• Int32 -> Scalar
• Int64 -> Scalar
• UInt8 -> Scalar
• UInt16 -> Scalar
• UInt32 -> Scalar
• UInt64 -> Scalar
• Float32 -> Scalar
• Float64 -> Scalar
• String -> Text

From geometry_msgs:

• Point -> Points3D (mono)
• Pose -> Transform3D
• Transform -> Transform3D
• Quaternion -> Transform3D (only quaternion field used)
• Polygon -> SeriesLine

From sensor_msgs:

• PointCloud/PointCloud2 -> Points3D
• CompressedImage -> EncodedImage
• Image -> Image
• CameraInfo -> Pinhole
• Imu -> Multiple Scalars

From visualization_msgs:

• Marker. This is a super flexible type that needs to be translated into one of the appropriate (Arrow, Box, Sphere, Line, Points, Mesh) primitive.

• Depends on Added configuration file parsing #11

• Closes Translate basic ROS types to Rerun #4

[jleibs]

All of these should use the entity_path from the Conversion as the log destination.

[esteve]

@jleibs can you have another look at this? I've added the logic for dispatching different converters based on the (topic, frame_id) tuple. frame_id is optional in the configuration and by default conversions will just take the topic to create subscriptions. Thanks.

[esteve]

@jleibs I've added a pseudo-converter for TransformStamped, which has a header (with a frame_id). The converter doesn't do anything on the frame_id, but I added some example code that shows how to process the field_id that comes from the CDR blob, see https://github.com/rerun-io/rerun-ros/pull/12/files#diff-e728a4b4964ced4a55d869ea1fd0b415c7821e12c3846b044377b8f8a7ae6578R113-R119

[jleibs]

Makes sense.

Definitely not for this PR, but in the future it would be nice to be able to do that logic, generically, for any Stamped variant of a message, but I recognize there is some complexity in doing that since not all messages have headers.

Does CDR let you generically pull out a header (if you know it's there?)

Alternatively maybe this is something we handle via the trait.

If the converter looked like:

    fn convert(
        &self,
        topic: &str,
        frame_id: &Option<String>,
        entity_path: &str,
        message: &mut Cursor<Vec<u8>>,
    ) -> Result<(Option<Header>, Box<dyn Loggable>), Error>;

Then we could actually move the logging code out out of the convert and up into process. This would keep the converter from needing to know anything about the log stream or entity_paths.

Approximately something like:

let (header, loggable) = converter.convert(rec, topic, frame_id, message)?;

// Find mapping from (topic, frame_id) -> entity_path
let entity_path = lookup_path_routing(topic, header);

// Use the timestamp from the header if there is one
if let Some(header) = head {
  rec.set_time_seconds("ros_time", header.timestamp);
} else {
  rec.set_time_seconds("ros_time", receive_time);
}

rec.log(entity_path, loggable);

[esteve]

Definitely not for this PR, but in the future it would be nice to be able to do that logic, generically, for any Stamped variant of a message, but I recognize there is some complexity in doing that since not all messages have headers.

Does CDR let you generically pull out a header (if you know it's there?)

Alternatively maybe this is something we handle via the trait.

We could try two things:

• Attempt to read the header anyway and if it fails, process the message as usual, I have to check if the cdr will fail or will just deserialize whatever it's fed.
• Use the message spec representation we already have to check if there's a header field. This requires the files for the message definitions to be available in the workspace.

I think either are valid approaches, I can work on it when I come back.