How to Support ROS1 and ROS2 natively?

[Carter12s]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[ssnover]

Is that a template or do you want me to introduce myself?

Re: ROS1/ROS2 support. I don't know basically anything about ROS2 wire protocol other than that it's built on DDS. Given that things like were bridging between ROS1 and ROS2 were possible I suspect from a paradigm level it's not going to be incompatible with having a single RosClient trait. However, I also think we can take our time designing the trait and in parallel start to work out backend support and re-implementation of ROS1 ros_comm and the equivalent in ROS2.

For ROS1 at least I see the path being something like this:

• Add md5sum to the trait and generate them during codegen.
• Add a unstable_ros1 feature to put things behind which is exempt from normal semver rules.
• Get a client making the right xmlrpc calls to rosmaster to be able to subscribe and the right tcpros calls to subscribe (I think this is easier than publish)
• Get a client making the right calls to do publish
• Figure out any intra-process optimizations we want to do
• Service server implementation
• Service client implementation

It will be easier to find a common trait API that can work for both rosbridge and ros1 if we've got an implementation already in place that we're just trying to massage the compiler to accept.

[ssnover]

I've already done some initial research into what's required for enabling publish and subcribe and documented it here: https://shanesnover.com/2022/09/12/ros-comm.html

[ssnover]

It's also occurred to me that this will enable somebody (maybe us?) to reimplement rosbridge to support things like publishing cbor-raw packets.

[Carter12s]

1. Yes is a template Sorry.

For ros2, the https://github.com/ros2-rust/ros2_rust/ exists and seems to have a lot of info we could pull from. I've been poking around in their codebase today. Looks like they've done a non-async api, but that is kinda forced by wrapping the underlying C lib (as ROS2 reccomends). I think you are totally right that slowly evolving the central trait is a great path forward.

Building out the ros1 portions behind a feature flag and using that to as proving grounds for common interface makes a ton of sense to me.

I do think at some point we should really reach out to the authors of ros2_rust and rosrust and see if we can't get some kind of summit together on a shared future.

I'm still not sure if this crate support ros1 and ros2 native communications is actually the "right" thing or the best path forward.

An alternative to that could be. We build the best rosbridge crate, we work with the other folks to define a common "RosClient" trait, and then we impl that trait on all 3 crates. Move towards a shared rust eco system for ROS instead individual silos of implementations. All of this to kinda say I'm hesitant to start impl on any of this even if we have a technical path forward.

[Carter12s]

Sorta "zooming out" I'm potentially more interested in us supporting ros2 rosbridge as a next step over the native implementations. I really haven't done the research to see what that looks like yet.

[ssnover]

@Carter12s I'm reviving this thread to plan ROS1 native implementation.

I need a better understanding of what's been implemented already as it was a while ago and it was a large PR. What is possible with current main? Can I write a program which directly interacts with rosmaster via ROS XMLRPC in such a way that it thinks that the program is a ROS node? Can that program establish connections with other ROS nodes via ROS XMLRPC (once it receives a URI from the rosmaster for a published topic for example)?

If the above is not possible, I think it makes sense to create a long-lived feature branch with the goal of developing that functionality (and putting it behind an experimental feature flag for merge to main. Then build up suitable abstractions around Publisher, Subscriber, ServiceClient, ServiceServer, etc and finally make those implement the accompanying traits implemented by the rosbridge-based code and add a convenient method for specifying the backend (and making it easy to switch).

[ssnover]

Crucially, I'd like to avoid large PRs just for my own sanity. I think we can come up with a checklist of relatively small items and then I won't procrastinate so much 😄

[Carter12s]

Hell yeah... Good call, and frankly it has also been long enough for me that I had to go double check the current state.

1. Can I write a program that directly interacts with rosmaster via ROS XMLRPC in such a way that it thinks the program is a ROS node?

Yes, too a point. I'd recommend looking at (and running) src/ros1/master_client/test which has good coverage of the currently implemented features. We're able to call a variety of xmlrpc endpoints on the rosmaster and parse the results. We're able to register and unregister services, subscribers, and publisher as have rosmaster report our node as a known entity for each of them.

There is a second half of this, is that to be compliant with ROS API our node must also host an XMLRPC server and provide a series of endpoints itself. These are found in src/ros1/node_server with decent tests. Several of these are unimplemented or partially implemented and need to be finished for full compliance.

2. Can that program establish connections with other ROS nodes via XMLRPC

No, but we're getting very close. I wanted to get our node publishing and regular ros node subscribing as the first case to test. We're up to the point of the subscriber node calling "requestTopic" on our nodes' xmlrpc server, but we are not yet validly replying to that message. Doing so requires us opening a TCPROS socket and giving the socket URI back to the subscriber. I would say we are fully through the "xmlrpc negotiation" phase of the communication, and next step is really standing up TCPROS if we want to get "light through the system".

3. I think it makes sense to create a long-lived feature branch with the goal of ...

My response to this is multi-faceted:

• I've already been using the "ros1" feature flag to hide all of this, I don't think we need an additional flag past that. I think simply documented "ros1" support is extremely experimental is good enough for now.
• I'd rather not make a long lived feature branch, and I'd rather we just merge to master with everything behind the feature flag. I'm not worried about people ignoring our documentation about an experimental feature and enabling it against our recommendation and then later being mad that we changed shit.
• Building up "substantial abstractions" around Publisher, Subscriber etc. is one way that we could do this, but I'm not actually sure it is the best order to do things in. I think there is going to be some pretty complicated internal structure to support the various TCPROS and XMLRPC interactions correctly inside the node which means that Publisher and Subscriber may be extremely different in their internal implementations between rosbridge and ros1. I've setup the TopicProvider trait to be very generic with different associated types for Publisher and Subscriber which means that the ros1 vs rosbridge backed could be completely independent implementations. All of this to say, my intent was to get the ros1 implementation a little farther along on actually mechanically working before digging in on the abstract layer as I'm afraid of not designing that abstract layer correctly without understanding exactly how the backend is going to be built. This has turned into a long ramble, but tl;dr we could start on this now, I would probably do it a little later.

---

Next Goals:

• Get a working ros1 native publish (I'd suggest publishing to /rosout so we can have a logger)

Upcoming Tasks to Achieve this Goal:

1. Begin building out a TCPROS management layer within ros1/node
   a. We have to open a new TCP socket for each "requestTopic" call
   i. This has to be piped back to the response of "requestTopic"
   ii. We have to clean-up this socket when it times out. Heartbeat?
   iii. We have to clean-up this socket when all Publishers are dropped on our end.
   iv. We have to clean-up this socket when the other end closes it.
   b. Eventually we'll tackle creating socket client handles, for the subscriber side but let's finish publishing first
2. Begin building out TCPROS serialization
   a. md5sum for messages, is this already done?
   b. Actual serializer, can we re-use what rosrust has?
   c. Get it working on a least a couple basic messages
3. Build a basic publisher interface for ros1/node, just enough so that we can test a normal ass publish
4. Build out a gnarly suite of unit tests that involve hammering the publisher, killing the subscriber and restarting it, all kinds of dropping and re-creating. See how stable we really all.
   a. I think we test everything short of bringing the master down.

I'd be really happy if we just got native publishing dialed, I think once we have this done, subscribtions, and services will come super fast.

[Carter12s]

@ssnover

[ssnover]

Alright, my next PR will try to achieve:

• Calling registerPublisher RPC method on rosmaster.
• Creating an actor listening on the URI provided on the previous RPC call.
• Maintain the connections from subscribers.
• Send publish calls to each of these subscribers.

Example message from subscriber to publisher node:

E¥lH@@ξ$[d
«éJ©fT<?xml version='1.0'?>
<methodCall>
<methodName>requestTopic</methodName>
<params>
<param>
<value><string>/listener</string></value>
</param>
<param>
<value><string>/chatter</string></value>
</param>
<param>
<value><array><data>
<value><array><data>
<value><string>TCPROS</string></value>
</data></array></value>
</data></array></value>
</param>
</params>
</methodCall>

Response from publisher

E4Ém@@pT¾$[f
)
©fU«éJHTTP/1.1 200 OK
Server: BaseHTTP/0.6 Python/3.8.10
Date: Sun, 13 Aug 2023 18:59:14 GMT
Content-type: text/xml
Content-length: 375

<?xml version='1.0'?>
<methodResponse>
<params>
<param>
<value><array><data>
<value><int>1</int></value>
<value><string>ready on pop-os:33121</string></value>
<value><array><data>
<value><string>TCPROS</string></value>
<value><string>pop-os</string></value>
<value><int>33121</int></value>
</data></array></value>
</data></array></value>
</param>
</params>
</methodResponse>

Connection Header from subscriber to publisher

Eת§@@wÂPa±ÎM&vÆCÿË
«éJ©fVcallerid=/listener'md5sum=992ce8a1687cec8c8bd883ec73ca41d1message_definition=string data

tcp_nodelay=0topic=/chattertype=std_msgs/String

(as hex)

0000   00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00
0010   00 d7 aa a7 40 00 40 06 90 77 7f 00 00 01 7f 00
0020   01 01 c2 50 81 61 b1 ce 4d 1b 26 76 c6 43 80 18
0030   02 00 ff cb 00 00 01 01 08 0a ab e9 4a 16 8a a9
0040   66 56 9f 00 00 00 12 00 00 00 63 61 6c 6c 65 72
0050   69 64 3d 2f 6c 69 73 74 65 6e 65 72 27 00 00 00
0060   6d 64 35 73 75 6d 3d 39 39 32 63 65 38 61 31 36
0070   38 37 63 65 63 38 63 38 62 64 38 38 33 65 63 37
0080   33 63 61 34 31 64 31 1f 00 00 00 6d 65 73 73 61
0090   67 65 5f 64 65 66 69 6e 69 74 69 6f 6e 3d 73 74
00a0   72 69 6e 67 20 64 61 74 61 0a 0d 00 00 00 74 63
00b0   70 5f 6e 6f 64 65 6c 61 79 3d 30 0e 00 00 00 74
00c0   6f 70 69 63 3d 2f 63 68 61 74 74 65 72 14 00 00
00d0   00 74 79 70 65 3d 73 74 64 5f 6d 73 67 73 2f 53
00e0   74 72 69 6e 67

Response to connection header (publisher to subscriber)

EÒi`@@ÑÃaÂP&vÆC±ÎM¾ÿÆ
©fW«éJcallerid=/talker
latching=0'md5sum=992ce8a1687cec8c8bd883ec73ca41d1message_definition=string data
topic=/chattertype=std_msgs/String

(as hex)

0000   00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00
0010   00 d2 69 60 40 00 40 06 d1 c3 7f 00 01 01 7f 00
0020   00 01 81 61 c2 50 26 76 c6 43 b1 ce 4d be 80 18
0030   02 00 ff c6 00 00 01 01 08 0a 8a a9 66 57 ab e9
0040   4a 16 9a 00 00 00 10 00 00 00 63 61 6c 6c 65 72
0050   69 64 3d 2f 74 61 6c 6b 65 72 0a 00 00 00 6c 61
0060   74 63 68 69 6e 67 3d 30 27 00 00 00 6d 64 35 73
0070   75 6d 3d 39 39 32 63 65 38 61 31 36 38 37 63 65
0080   63 38 63 38 62 64 38 38 33 65 63 37 33 63 61 34
0090   31 64 31 1f 00 00 00 6d 65 73 73 61 67 65 5f 64
00a0   65 66 69 6e 69 74 69 6f 6e 3d 73 74 72 69 6e 67
00b0   20 64 61 74 61 0a 0e 00 00 00 74 6f 70 69 63 3d
00c0   2f 63 68 61 74 74 65 72 14 00 00 00 74 79 70 65
00d0   3d 73 74 64 5f 6d 73 67 73 2f 53 74 72 69 6e 67

There's also a publisherUpdate call between two processes (which ones they are I'm not sure about yet, I'll push these to another PR).

[ssnover]

Oh and here's an actual publish:

EYia@@Ò;aÂP&vÆá±ÎM¾ÿM
©f¸«éJ!hello world 1691953155.041078

(as hex)

0000   00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00
0010   00 59 69 61 40 00 40 06 d2 3b 7f 00 01 01 7f 00
0020   00 01 81 61 c2 50 26 76 c6 e1 b1 ce 4d be 80 18
0030   02 00 ff 4d 00 00 01 01 08 0a 8a a9 66 b8 ab e9
0040   4a 17 21 00 00 00 1d 00 00 00 68 65 6c 6c 6f 20
0050   77 6f 72 6c 64 20 31 36 39 31 39 35 33 31 35 35
0060   2e 30 34 31 30 37 38

[ssnover]

What are your thoughts re: rewriting handy tooling like rostopic and rosnode. I think one of the big advantages of this library is the ease of building and installing it in different environments and it may be compelling to maintain rewrites in this repository to facilitate that.