RosLibRust for production use?

[ablakey]

Hello!

I'm looking to get "temperature check" (if available!) on the status of the RosLibRust project. I appreciate that RosLibRust is a smaller project without a 1.0 build so I'm coming pre-loaded with reasonable expectations. In terms of "temperature check" I'm thinking on the rough spectrum of "You'll hit rough edges but it's an active project and we'd be excited to see it used for this!" to "There will be a lot of pain..."

We're looking to replace Rosbridge Websocket with a Rust-based purpose-built Websocket API used for Web UI monitoring tools for fleets of up to 1000 robots on a single ROS master. This would be a Rust runtime with a Websocket server on one side, in-memory state (users, auth, latest messages, etc.) in the middle, and ROS pub/sub on the other. It's very much like Rosbridge, except we own the shape of the API (serializers/deserializers/views/router, not just ROS to JSON passthrough).

I've been experimenting with RosLibRust and am struggling with getting rostopic echo and rostopic pub to work (might be a me problem with ROS_IP or whatnot...), but I don't want to start asking too many questions if the initial answer is something like "this is still a very alpha-stage project mostly aimed at a specific use case" or whatnot.

Thank you!
Andrew

[Carter12s]

Always tricky to give "real" answers to questions like this, but here is my best summary.

The company I work for does not officially sponsor this project, but I'm given some discretionary time to maintain it as we rely heavily on it.

The project is of various levels of quality at the moment depending on the specific backend in use.

• rosbridge: Only a limited API of everything rosbridge server supports is implemented, but the features that are there we heavily use in production.
• ROS1 native: We're actively migrating our ROS1 code base to Rust and relying on this as the back-end. Still finding bugs pretty regularly as we do this, but fixing them as we go.
• ROS2 stuff: Fully an experiment at the moment, waiting for ros-z to stabilize then we'll build on top of it.

From the support perspective, I'm basically solo maintaining at the moment, there are few folks who contribute here and there, but largely you're betting on my continuing to support it at the moment. So far I've been consistently developing on it for 3 years, am actively using it in production at my company, and want to continue working on it and seeing it grow. But I'm also just a dude, so if I get hit by a bus you'll likely be outta luck.

Frankly the biggest thing roslibrust is missing at the moment is a lot of users with real world use cases beyond mine. I'm fixing the majority of bugs that come in pretty quickly when they do, but also know that a lot of what is built has only seen limited battle testing, and there is only so much you can do in CI.

You're project sounds cool (especially if it is open source), and I'll volunteer sometime to test it out and fix some issues if you run into them. Myself and Ezra one of the maintainers of rosbridge server have been discussing potentials for "Rosbridge Server v3" where a substantial portion gets re-written in rust to optimize it. What you're talking about sounds pretty similar?

[ablakey]

Thanks for taking the time to reply! I know these are difficult and somewhat "loaded" questions but I got exactly the insight I was hoping for.

If we were to adopt RosLibRust, we'd be looking to contribute to the project by offering real-world exercise and the feedback/issues/PRs that come with it. Unfortunately it's a closed-source project so this would inevitably receive some level of abstraction (eg. me reproducing issues via example code). I also see an opportunity for my team to contribute to this project and help de-bus-factor you. But one step at a time...

We're still evaluating all the options and project variables so nothing's set on wanting to use Rust, but I'm pretty set on Python not being a great option and C++ being a bit unfriendly for our term's competencies and the problem space in general.

As for a Rosbridge Server v3: yes, it's somewhat similar. The main difference is that I'm perceiving this as purpose-designed to be a production-ready Websocket API. While Rosbridge does well at generically bridging WebSocket and ROS, we want additional features you'd find in a WebSocket API:

• A richer access control story (ie. is this user authed before they can access any resources? Do they have permissions to access those ROS resources?)
• serializers to restructure incoming/outgoing messages (a big problem we have is that the ideal shape of messages for Web/client uses is rarely the ideal shape of ROS messages. Rosbridge implicitly does some of this eg. uint8[] -> base64)
• An API versioning story (The WebSocket interface is often a very good place to handle versioning)
• Custom republish frequency (subscribe to a 10hz topic, republish 1-10hz depending on each WebSocket subscription's config)
• Handle backpressure (a big issue for us. Most of our data is useless if it's going to be 20 seconds old. gracefully degrade if client cannot keep up)
• Better logging linked to "users". We need exhaustive logs for user interactions. No more "we have 20 clients connected but know nothing about them or which one is being very mishbehaved"
• Better monitoring (knowing how many sessions each user has open, their subs, pubs, and bandwidth usage)
• JSON Schema support (validating incoming data before it gets to touch the ROS environment).
• per-user specified encoding (ie. do we return JSON? CBOR? BSON?)

Perhaps what my team ends up implementing can feed back into a FOSS project like Rosbridge v3, whether through code and/or real-world experience. We've currently got a real-time monitoring system used by hundreds of internal users to monitor and maintain tens of thousands of robots worldwide for almost a decade now, so I imagine some of the above bullets represent a few of the hard earned lessons that we might be able to share.

[Carter12s]

Fantastic!

Yeah I'd love to have you guys as users and contributors. Would seriously appreciate any and all bug reports and findings, and will commit to trying to fix whatever issues ya'll surface.

Product you are building does sound like something truly useful! It is a lot of what I dream rosbridge can be in the long run.