Skip to content
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

Multiple concert_clients subscribing to the same topic, limitations? #350

Open
samiamlabs opened this issue Aug 4, 2018 · 2 comments
Open

Comments

@samiamlabs
Copy link

Hi,

Was making a simple RViz integration for moving multiple robots with navigations stacks from the "concert" side today.
image
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.

@stonier
Copy link
Member

stonier commented Aug 5, 2018

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?

@samiamlabs
Copy link
Author

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.

I am using the standard flipping rules in the clients.
https://github.com/samiamlabs/dyno/blob/master/dyno_bringup/launch/concert_client.launch
https://github.com/samiamlabs/dyno/blob/master/dyno_unity/launch/concert.launch
(not sure if the conductor is doing anything useful here...)
So the clients flip the move_base_multi subscribers to the concert. Should I be flipping the publisher on the concert instaid?

Client gateway_info

(with firewall to prevent re-flipping, which seems to work but looks messy)
image

Concert gateway_info

image

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.

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants