-
Notifications
You must be signed in to change notification settings - Fork 387
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow compression for service calls/responses #338
Comments
Rosbridge has a websocket-level compression feature (pre-message deflate) which is more efficient than protocol-level compression, for browsers which implement the standard. Set the rosbridge_websocket.py param This will give you some fast compression, but still requires base64 packing the binary data into JSON. What you really want is the option to use CBOR encoding for service responses. CBOR is more efficient for binary data, but tends to be less efficient for small messages. On the rosbridge side, there is a TODO for service call compression. Topic subscriptions handle compression here. On the roslib side, you would probably add a compression option to the service call and be done. |
@mvollrath thanks! I've implemented the roslib side ( untested though :)) ) Basically I have very large images in arraybuffer (uint8) format. Easily goes up to 16MB and more. Right now I hope there is no need for tiling the images (alternative representations of the map than occupancy gridmaps) and occupancy grids itself. |
@mvollrath Pullrequest has been sent, I will have a look later on the rosbridge side but I do lack total knowledge of all internals. Some help here would be nice! thanks in advance edit: after looking at the bridge code, it seems doable, will work on this in a few hours |
Hi @ all,
currently I am implementing a service-like interface for a web-app with ROS and transporting large images (gridmaps and such) is one feature. While it is supported on topics it doesnt seem to be possible to pass compression flags via services. One of my colleagues told me that protocol itself does support this for services as well and as far as I can see in the code services are also just using the same websocket-adapter implementation underneath.
Is there any chance to get this support implemented quickly? or if I do it on my own, anything special to consider? Thanks!
The text was updated successfully, but these errors were encountered: