Announcing RosLibRust: Rust client library for interacting with rosbridge_server

Repo: GitHub - Carter12s/roslibrust: A rust client for working with ROS's rosbridge.
Documentation: roslibrust - Rust

A little bit of YARC syndrome (Yet Another Rust Client). But nobody had made one for rosbridge yet, and we needed to reach a fleet of deployed robots easily.

We’re happily using it in production now with no issues and I think the Rust API is rather slick. Hope people are willing to give it a try.

4 Likes

All the cool kids are building Rust clients these days.

I’m curious about your experience using the rosbridge protocol to connect to deployed robots. How bandwidth-efficient is that? Doesn’t rosbridge just, well, bridge all ROS messages, meaning that if your robots were to publish the same value at 100Hz on a topic you subscribed to remotely, you’d be pushing 100 identical messages a second over your remote connection? I’m assuming you are not using this for heavy payloads like video or 3d point clouds, are you?

For a bandwidth-limited remote connection I believe a proper data-synchronization protocol is more appropriate, i.e., one that only sends diffs (and maybe keyframes from time to time) rather than every message. That’s how we implemented the data protocol in GitHub - transitiverobotics/transitive: An open-source framework for full-stack robotics, based on MQTT.

Great questions, and nice plug!

  1. rosbridge only bridges topics that you subscribe to remotely so zero overhead for unused topics
  2. rosbridge does implement throttling and different forms of compression on topics. Not perfectly efficient but gives us more than enough control
  3. We’re not incredibly bandwidth limited in our application, our systems have relatively fat pipes and we prioritized developer velocity over efficiency.
  4. You’re right we’re not using this for very heavy data topics. This is much more used for general monitoring and “fleet administration”.
1 Like