Add cbor-raw compression

[janpaul123]

The CBOR compression is already a huge win over JSON or PNG encoding, but it’s still suboptimal in some situations. This PR adds support for getting messages in their raw binary (ROS-serialized) format. This has benefits in the following cases:

• Your application already knows how to parse messages in bag files (e.g. using rosbag.js), which means that now you can use consistent code paths for both bags and live messages.
• You want to parse messages as late as possible, or in parallel, e.g. only in the thread or WebWorker that cares about the message. Delaying the parsing of the message means that moving or copying the message to the thread is cheaper when its in binary form, since no serialization between threads is necessary.
• You only care about part of the message, and don't need to parse the rest of it.
• You really care about performance; no conversion between the ROS binary format and CBOR is done in the rosbridge_sever.

For Webviz we care about all of these cases, and so we’d really like to be able to use raw binary ROS messages.

This seemed easy to support by extending the current CBOR-format. We simply encode the outgoing_msg (which contains stuff like the operation and the topic name) with CBOR, just like with the existing CBOR encoding. The only difference is that in the current CBOR encoding, the “msg” field is itself a CBOR structure that encodes the message, where in our encoding it’s a CBOR object that contains a “bytes” field, which is just a bytearray with the raw binary message.

Besides the “bytes” fields we also added “secs” and “nsecs” fields with the current time, which is useful when using use_sim_time set to true. Webviz needs this to properly show the simulated received time of messages.

Now that we have the raw messages, we need to be able to parse them on the client. Bags contain the raw message definitions as stored on the ._full_text field on message instances, so we added a service call for accessing these raw message definitions for all topics in one call.

With both of these changes combined, you can now easily parse messages as late, parallel, partially, and fast as possible. In Webviz we intend to use this by either using rosbag.js or by parsing using the ROS deserializer compiled to WebAssembly, and by doing this in the WebWorker that actually controls the 3d canvas using the OffscreenCanvas API. This way we can have multiple rendering surfaces running from parallel threads. We already do this for some panels in Webviz, such as the Image panel, and we’ve seen substantial speedups with this method.

We also made a companion PR to roslibjs.

Documentation: we updated the ROSBRIDGE_PROTOCOL.md file with the new changes.

Test plan: we added a new test for the WebSocket server, modeled after the existing test. We also tested this end-to-end with our Webviz client, and it seems to work great.

Thanks to @vadimg for helping with this.

[mvollrath]

Looks great!

[janpaul123]

Awesome, thanks for reviewing! How does the release process usually work? Do you need another reviewer or can you merge this? And could you then cut a new version? Would that show up in apt-get and such? Sorry, I'm a bit of a noob when it comes to how ros/linux packages work. 😄

[mvollrath]

I can merge this soon.

The next release should be pretty soon. Since the last release we changed the default websocket server library, so we want to be confident that everything has shaken loose. I'll be following up on that.

Once we tag a new release we will release it to ROS via bloom. ROS will then sync it as part of their release cycle, it usually happens every two weeks. See their discourse (for melodic) for details. Then it will be the new apt default.

[janpaul123]

Awesome, that makes a lot of sense, thanks for explaining!

[janpaul123]

Hey @mvollrath, any idea when you might have time to do some thorough testing (because of the new websocket library) and release? 😄 That way I can schedule some time to make the necessary changes on the Webviz side for this.

[janpaul123]

Hey @mvollrath and @jihoonl — just another quick ping on if you think a release might happen soon, because then we can switch Webviz to use this new protocol which would be super useful for us!

[jihoonl]

on my way

[jihoonl]

ros/rosdistro#23821
ros/rosdistro#23822

[janpaul123]

@jihoonl Thanks a bunch!! I'll update Webviz soon.

[nilsbore]

@janpaul123 Thanks for an awesome job on this. It enabled me to use native ROS deserialization of the websocket messages in my ROS C++ client library for Emscripten. Are there any plans to extend cbor-raw compression to other transports (services, publish)?

[janpaul123]

Yay! I currently have no plans for those but feel free to add that yourself. Should be much easier now that we already use it for messages.

…

On Fri, May 29, 2020 at 12:19 Nils Bore ***@***.***> wrote: @janpaul123 <https://github.com/janpaul123> Thanks for an awesome job on this. It enabled me to use native ROS deserialization of the websocket messages in my ROS C++ client library for Emscripten <https://github.com/nilsbore/roswasm_suite>. Are there any plans to extend cbor-raw compression to other transports (services, publish)? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#452 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABLKNKC2KDVLJ7N5BLN753RUADE3ANCNFSM4KCTLUXQ> .

[mvollrath]

I think this would do it: #428