You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I noticed some seeming limitations in subscribing nodes on different masters during this. I published robot poses (with master name/URI and current pose) to /applications/robot_pose on all clients. One node on the concert side listened to the same topic from all clients. That worked fine so i tried a similar thing the other way around for navigation goals.
I published a single topic /concert/move_base_multi (name and pose) and had one node per client listen to this topic. It appeared like only one node at a time could receive on the topic and which node that was changed over time. I solved the problem by publishing on different topics for each client (/concert/master_name/move_base_multi).
Was just wondering if this is a known limitation of the current rocon_multimaster implementation or if something is wrong on my end.
The text was updated successfully, but these errors were encountered:
It should work, unless #127 is getting in the way somehow.
How are you making the connections? i.e. are you flipping the concert aggregated /concert/move_base_multi publisher to each client or flipping a subscriber from each client to the concert, or doing some form of advertising?
Hmm, I don't have any problems with subscribing to multiple masters. Only publishing to multiple subscribers. But I it is possible #127 could still be relevant.
(with firewall to prevent re-flipping, which seems to work but looks messy)
Concert gateway_info
Have tested up to 4 simulated clients, and it works fine if I use separate topics to send the move base (PoseStamped) messages. If I use a shared topic it only works sometimes. If I keep re-sending messages to the shared topic, all robots they eventually receive them and start moving, but it is very unreliable.
Hi,
Was making a simple RViz integration for moving multiple robots with navigations stacks from the "concert" side today.
https://www.youtube.com/watch?v=6HC5ZyNKX0Q
I noticed some seeming limitations in subscribing nodes on different masters during this. I published robot poses (with master name/URI and current pose) to /applications/robot_pose on all clients. One node on the concert side listened to the same topic from all clients. That worked fine so i tried a similar thing the other way around for navigation goals.
I published a single topic /concert/move_base_multi (name and pose) and had one node per client listen to this topic. It appeared like only one node at a time could receive on the topic and which node that was changed over time. I solved the problem by publishing on different topics for each client (/concert/master_name/move_base_multi).
Was just wondering if this is a known limitation of the current rocon_multimaster implementation or if something is wrong on my end.
The text was updated successfully, but these errors were encountered: