-
Notifications
You must be signed in to change notification settings - Fork 107
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
Topics Crosslinked When 2 Similar Robots Viewing Each Other's /tf #178
Comments
I further did an interesting test. Hope this helps: Scenario 3 (work at step 1. not work at step 2):
|
It looks strange, but the problem can be avoided by just making the source relay topic name unique. E.g.
This trick doesnt work if the intermediate topics Is there any hope to allow topics of already different names to have the same source topic names? |
Hi, can you use |
You are right. That also works!
So the cases that I have tested:
Btw is there any method to specifically sync only the wanted topics and services and ignore the rest by default, without having to supply a list of |
I have made 2 similar robots connected to each other using multimaster. I used
topic_tools
relay
to copy the required topics (e.g./tf
,/tf_static
) to another topics (e.g./robot1/tf
,/robot2/tf
). To sync these topics, I usedmaster_sync
'ssync_nodes
to sync therelay
nodes.Also to display the robot model, I created a service to let other robot getting the robot description so that it can set it to rosparam.
A sample launch file of the robot:
Then I use RViz to view the robot:
rviz /tf:=/robot2/tf /tf_static:=/robot2/tf_static /robot_description:=/robot2/robot_description
Scenario 1 (work):
get_robot_description.py
to obtain robot2's robot description. Then use the above RViz command to view robot2's state (correct and I can see robot2's movement)Scenario 2 (not work):
get_robot_description.py
to obtain both robot's robot description. Then use the above RViz command to view robot2's state (I see robot1's/tf
is used instead, and robot2'srobot_description
is used, so that the visual model is wrong and robot1's movement is shown instead). Use another terminal and RViz command to view robot1's state (I see robot2's/tf
is used instead, and robot1'srobot_description
is used, so that the visual model is wrong and robot2's movement is shown instead)So it seems the sync topics are kind of crosslinked, while services are ok.
I also tried
master_sync
'signore_nodes
to ignore all the robot core's nodes but no difference. Is there something that I have missed?The text was updated successfully, but these errors were encountered: