ros1 native publisher doesn't work with rospy.AnyMsg subscriber, including rostopic hz

[lucasw]

I have a node here https://github.com/lucasw/ros_one2z/blob/main/ros1_rlr/src/main.rs based on ros1_talker, when it publishes rostopic echo and other subscribers work fine, but not a rospy.AnyMsg subscriber which includes rostopic Hz (https://github.com/ros/ros_comm/blob/noetic-devel/tools/rostopic/src/rostopic/__init__.py#L315).

(I'd test with ros1_talker but it isn't actually built?)

I see this comment about rostopic hz https://github.com/Carter12s/roslibrust/blob/master/roslibrust/src/ros1/publisher.rs#L97

#!/usr/bin/env python

import rospy
from geometry_msgs.msg import PointStamped

rospy.init_node("sub")

def callback(msg: PointStamped):
    print(dir(msg))

# sub = rospy.Subscriber("point", PointStamped, callback, queue_size=2)
sub = rospy.Subscriber("point", rospy.AnyMsg, callback, queue_size=2)
rospy.spin()

[Carter12s]

Hey Lucas, thanks for flagging.

Can you confirm if you are using the version of roslibrust from the master branch of this repo (where the issue should be fixed) or if you are using v0.9.0 which doesn't have the fix yet?

[lucasw]

Ok I was using 0.9.0, but now updated to 883057f8d159b0298c243744d65971e746ec5dbc and now rostopic hz works.

(but i have to unwrap the received subscriber messages a second time? )

roslibrust = { git = "https://github.com/Carter12s/roslibrust.git", rev = "883057f8d159b0298c243744d65971e746ec5dbc", features = ["ros1"] }
roslibrust_codegen = { git = "https://github.com/Carter12s/roslibrust.git", rev = "883057f8d159b0298c243744d65971e746ec5dbc" }
roslibrust_codegen_macro = { git = "https://github.com/Carter12s/roslibrust.git", rev = "883057f8d159b0298c243744d65971e746ec5dbc" }

https://github.com/lucasw/ros_one2z/blob/8858b27817dc56ea00fc73fd79e85296e7c2b0ef/ros1_rlr/Cargo.toml#L14-L16

rosbag record was also not working in 0.9.0, but in that newer version it is, probably it was using the C++ equivalent of AnyMsg.

I also tried the latest version and spot checked a few earlier ones, but it looks like publishes weren't working at all, nothing out of rostopic echo, but I didn't do much else before jumping backwards to the merging of the rostopic hz debug commit since the service stuff looks like work-in-progress.

[Carter12s]

Hrmm... yeah work in progress is right.

I just confirmed the fact that ros1 publishes are broken on master (seriously thank you for the good QC on all of this).

Error from the publisher is an md5sum issue:

INFO [roslibrust::ros1::publisher] Received connection from subscriber at 127.0.0.1:58282 for topic /chatter
WARN [roslibrust::ros1::tcpros] Encountered unhandled field in connection header: $callerid=/rostopic_568_1719680619999'md5sum=992ce8a1687cec8c8bd883ec73ca41d1message_definition=string data
tcp_nodelay=0topic=/chattertype=std_msgs/String
DEBUG [roslibrust::ros1::publisher] Received subscribe request for None with md5sum 
WARN [roslibrust::ros1::publisher] Got subscribe request for /chatter, but md5sums do not match. Expected 992ce8a1687cec8c8bd883ec73ca41d1, received

I'll fix that today.

[Carter12s]

Okay (minor rant)...

ROS documentation here pretty clearly states that subscribers are required to provide md5sum in the connection header, but a trivial packet capture of the behavior of rostopic echo shows that it doesn't provide this field.

This is an easy fix, just constantly slightly annoyed at out poorly documented TCPROS is (I get it, cause they didn't really want people tapping in at this level, but still...)

[Carter12s]

Fix: https://github.com/Carter12s/roslibrust/pull/167

[lucasw]

ROS documentation here pretty clearly states that subscribers are required to provide md5sum in the connection header, but a trivial packet capture of the behavior of rostopic echo shows that it doesn't provide this field.

I don't know if you're interested in Zenoh at all but a few months ago I tried hacking rospy and roscpp to use zenoh instead of tcpros only for topics, everything else was unchanged, and it seemed to work fine after minimal testing. roscore is still needed (though unrelated to any of this I think they have a re-implementation of roscore, in rust?), and different computers with their own roscores could publish to and subscribe from each other over zenoh without additional configuration beyond what is needed for zenoh without ros. I might get back into that later but having some basic functionality in rust nodes with regular old tcpros comes first.