rosbridge_suite: rosbridge_websocket fails to process incoming messages after the first time
The first run of node_simple.js works but if I run it again I see the following output from rosbridge_websocket.launch and the twist messages never send again until I restart the launch file.
[WARN] [WallTime: 1484339590.495914] Could not process inbound connection: [/rosbridge_websocket] is not a publisher of [/cmd_vel]. Topics are [[‘/rosout’, ‘rosgraph_msgs/Log’]]{‘message_definition’: ‘# This expresses velocity in free space broken into its linear and angular parts.\nVector3 linear\nVector3 angular\n\n================================================================================\nMSG: geometry_msgs/Vector3\n# This represents a vector in free space. \n# It is only meant to represent a direction. Therefore, it does not\n# make sense to apply a translation to it (e.g., when applying a \n# generic rigid transformation to a Vector3, tf2 will only apply the\n# rotation). If you want your data to be translatable too, use the\n# geometry_msgs/Point message instead.\n\nfloat64 x\nfloat64 y\nfloat64 z’, ‘callerid’: ‘/rostopic_6691_1484339001563’, ‘tcp_nodelay’: ‘0’, ‘md5sum’: ‘9f195f881246fdfa2798d1d3eebca84a’, ‘topic’: ‘/cmd_vel’, ‘type’: ‘geometry_msgs/Twist’}
This is on indigo, Ubuntu 14.04.
I am listening to the messages with rostopic echo /cmd_vel
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Comments: 34 (12 by maintainers)
Commits related to this issue
- applying the fix for rosbridge_suite issue 249 https://github.com/RobotWebTools/rosbridge_suite/issues/249 — committed to ozfaro/rosbridge_suite by frankfaro 6 years ago
- hack to avoid issue like in https://github.com/RobotWebTools/rosbridge_suite/issues/249 — committed to francescodelduchetto/rosbridge_suite by francescodelduchetto 6 years ago
- Workaround for RobotWebTools/rosbridge_suite#249. Don't unregister publishers. This breaks when reloading the page. Downside of this is that you will need to restart rosbridge if the topic type is c... — committed to oru-robotics-ipw/rosbridge_suite by VorpalBlade 5 years ago
- Workaround for RobotWebTools/rosbridge_suite#249. Don't unregister publishers. This breaks when reloading the page. Downside of this is that you will need to restart rosbridge if the topic type is c... — committed to oru-robotics-ipw/rosbridge_suite by VorpalBlade 5 years ago
- Attempting potential workaround documented as a fix https://github.com/RobotWebTools/rosbridge_suite/issues/249#issuecomment-513806687 — committed to chris-allnutt/rosbridge_suite by chris-allnutt 5 years ago
- Workaround for RobotWebTools#249. — committed to chia-labradorsystems/rosbridge_suite by chia-labradorsystems 4 years ago
- Changed based on discussion here: https://github.com/RobotWebTools/rosbridge_suite/issues/249#issuecomment-625031201 — committed to mjsobrep/rosbridge_suite by mjsobrep 4 years ago
- Implement unregister hack from https://github.com/RobotWebTools/rosbridge_suite/issues/249 — committed to Hippo-Harvest/rosbridge_suite by eitanme 2 years ago
@transis22 here is a full diff https://github.com/EndPointCorp/rosbridge_suite/commit/f3b4791e626a23d6ff2a38111e6783ba3c94ac59
I don’t believe so. I’ve tried playing around with what options there are, such as unadvertising topics before exit and nothing changes server behaviour.
Websocket servers need to be able to gracefully handle abrupt closures of connections. Particularly if you’re serving to browsers where you can’t guarantee any form of cleanup on application exit. I’ve got hundreds of users that will just close their phone or laptop and bam, interrupted connection and closed socket after a timeout.
Hey everyone,
We are also having this problem, unhacked melodic running on Ubuntu 18.04.
Thanks @mvollrath. Is this a problem that doesn’t cause problems for most people? Is there something that just a few of us are doing to cause it?
It looks like the fix for that was merged back in 2015. I rebuilt my systems a few times and tried in both Kinetic and Melodic, same problem. Could there be something keeping some of us on a very old version of rospy?
@ablakey yeah, those are the lines. It’s in a private repo so I can’t link you to it but here’s a screenshot of the diff.
I made this change on Nov 15, 2017 and have been working without any trouble since then. I also haven’t updated my branch since then so it’s possible that future changes relying on this behavior would be broken.
Anyone find a solution to this? The solution @subvertallchris proposes works so far, but it does feel brittle – and I wonder why this only seems to be an issue for a relative few of us. Usually that means we’re doing something wrong, but from what I can tell we’re all following along with the documentation. (I’m on Kinetic / Ubuntu 16.04 btw)
Of course, I wasn’t suggested that doing something other than closing the connection is what it should do, just trying to figure out what could account for some of us seeing this and not others.
With both Jade/Ubuntu 14.04 and Kinetic/16.04, we see this as soon as a JS client abruptly disconnects from the socket.
We were working from a fork of this repo for some time now and found that commenting out the following lines was an effective workaround:
https://github.com/RobotWebTools/rosbridge_suite/blob/develop/rosbridge_library/src/rosbridge_library/internal/publishers.py#L313 https://github.com/RobotWebTools/rosbridge_suite/blob/develop/rosbridge_library/src/rosbridge_library/internal/publishers.py#L322-L324
We’re naturally concerned about what unsafe things might be happening as a result, but our system stays online, so it’s hard to argue with those results.