At PickNik we use both websockets and ROS networks. I’ve started to see many others doing the same and so I wrote a blog post about it here.
Let me know what you think.
Using websockets and rosbridge to communicate with the robot from the web directly has the downside that the web UI will be unavailable or broken when the robot is (intermittently) offline. Have you run into that problem?
Also, a small correction:
The problem is that as you scale this network up, the amount of traffic exponentially increases with the number of participants.
Fortunately its’ not exponential, just quadratic and even that only in worst case. Technically it is just p * s where p is the number of publishers and s is the number of subscribers, and in practice there often aren’t all that many publishes for the same topic (with some notable exceptions, like tf and rosout).
That said, I still 100% agree with your argumentation as to why ROS is not suitable for cross-Internet communication. The other reason is that it doesn’t deduplicate messages even when a node 100 times a second sends the same unchanged message. Unfortunately I don’t think rosbridge solves that problem either, which is why we created mqttsync as part of Transitive.
2 Likes
When I said the traffic exponentially increases, it was about discovery traffic, not messaging traffic. There are ways to mitigate the discovery traffic problem. You make a good point about how messaging traffic also scales.
Some features of the web UI do not work when the robot is not connected. The web-ui sometimes can queue up messages to send when it regains connectivity. I’m unsure how any UI that relies on cross-network messaging for some functionality would do better with any other transport layer, web or otherwise.
using header with time stamp can eliminate unchanged message problem
Christian Fritz via ROS Discourse <notifications@ros.discoursemail.com>, 20 Şub 2024 Sal, 04:00 tarihinde şunu yazdı:
This is a UX question more than a technical question. On the technical side you are right of course. But from a UX point of view it is better to serve the web UI from a stable location, say the cloud or an on-prem server, and just indicate that the data being shown is old, and it can say when the robot was last seen online. That way, you can always show the latest state of the robot, even when it is offline, and the user experience is not broken. Without it the user will literally see a browser error (server can’t be reached or similar). In this approach you can still edit the robots config or give it a new task, e.g., which will be picked up when the robot reconnects.
For our application, we serve the web app from the user’s computer so it stays up. Some functionality is degraded when they lose connection to the robot. We don’t serve the web-app from the robot for the reason you stated.
1 Like
In my experience, I can say mqtt protocol is more proper than websocket. There is different reasons about it, first recovery. When robot lose internet connection and after reconnect to internet again mqtt protocol is recovery faster than websocket. Second thing mqtt is supporting for IoT system and it is already using industrial areas. Third reason is VDA5050 interface. If you want to use VDA5050 you must use mqtt.
I second that, and would argue that the MqttSync protocol we built on top of mqtt is even better suited for robotics, because you don’t even need to operate on the level of messages, but can directly talk about shared data (like dropbox or google docs). By the way, on the front-end (the browser) mqtt still uses websockets to connect to the broker, so it’s really a layer on top of (web-)sockets not strictly an alternative.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.