0
$\begingroup$

Rosanswers logo

I have a two robot system that is prefixed in separated namespaces so each robot can work independently, but they exist in a single workspace in a connected tf_tree. I'm working in Linux 18 with ROS Melodic, C++.

I run separate move groups for each robot in their own namespace and run C++ code in the same namespace for each robot. Every time a path is planned, I get this warning in the move_group.launch terminal for every frame of the robot.

[ WARN] [1629361686.174205495]: Unable to transform object from frame 'ur5/base_link' to planning frame 'base_link' ("base_link" passed to lookupTransform argument target_frame does not exist. )

Each robot is namespaced and prefixed at launch, so the name base_link only exists in the .srdf's for each robot, but when executing the command move_group.getPlanningFrame() it displays base_link so I'm assuming, inside the namespace, the frames aren't namespaced and for some reason it's searching for them?

UPDATE

When computing a Cartesian path, I get a similar error

[ERROR] [1629898925.139134667]: TF Problem: "base_link" passed to lookupTransform argument source_frame does not exist. [ERROR] [1629898925.139152001]: Error encountered transforming waypoints to frame 'base_link'

and that blocks code from being executed.

Are there any ways to prefix/namespace the planning frame, perhaps in code or any other ways to fix this?

UPDATE #2 tf_tree (the second robots tree is the same, but with a different namespace, both connected by the world frame) image description

rqt_graph for the same setup image description

Originally posted by sniegs on ROS Answers with karma: 65 on 2021-08-19

Post score: 1

Original comments

Comment by fvd on 2021-08-26:
What's the output of rosrun tf view_frames?

Comment by sniegs on 2021-08-26:
@fvd I don't think I can add the tf_tree image, but the tree is connected and sort of looks like this:

 world / \ ur5/base_link ur5e/base_link | | etc. etc.

the world frame is added by a static_transform_publisher at ...setup.launch to connect the two namespaced robot tf_trees. As far as I know the problem might be that move_group is searching for base_link as the planner_id, but it should be looking for ur5/base_link.

Comment by fvd on 2021-08-26:
I upvoted your question so you should have enough reputation to upload the image. The planning frame might be an issue, yes.

Comment by sniegs on 2021-08-26:
I added tf_tree and rqt_graph output

Comment by fvd on 2021-08-26:
The TF frames are not namespaced, so yes you should try setting your PlanningFrame to ur5/base_link

Comment by sniegs on 2021-08-26:
do you have any idea how to do that? As far as I know there is no setPlanningFrame in the c++ API and I can't find it in the launch files. But also, when I would launch the second robot, how would they connect if the TF frame were namespaced?

Comment by sniegs on 2021-09-13:
I went with a completely different solution for namespacing, where this question is no longer relevant, so I'm not sure if I should post it as an answer or not.

Comment by fvd on 2021-09-13:
Surely that would be better than leaving the question unanswered.

Sorry for not answering your comment, by the way. I did not have a good response ready, and then I lost sight of this.

Improve this question
$\endgroup$

1 Answer 1

Reset to default
0
$\begingroup$

Rosanswers logo

I ended up using a completely different solution for a multi-robot setup, so this error is no longer relevant, but I'll write it as an answer here!

Instead of using tf_prefix in it's existing form and robot_state_publisher for namespacing my robot frames, I set the prefix variable in my .xacro files for both robots. This raises a couple of issues, but they can be solved.

  1. You have to rename all the joints and frames in your package to match your prefixed .xacro (this also means renaming them in the .srdf, kinematics.yaml, joint_states.yaml etc.;
  2. I didn't want to edit the controller in the ur driver, so I had to copy it and rename the joints to the new, namespaced ones in it, then load it as a rosparam in the ur_controller.yaml
  3. ur_hardware_interface doesn't return these namespaced joints, so a publisher for renaming them had to be made and the joint_state_publisher remapped to the new publisher

After this is done, no problems arise with moving both of the robots simultaneously with move group.

Originally posted by sniegs with karma: 65 on 2021-09-13

This answer was ACCEPTED on the original site

Post score: 1

Original comments

Comment by raphael_leber_cpe on 2023-07-08:
Thank you very much for the feedbacks of your own investigation ! I would be very gratefull to have more precise context and steps. It seems you finally didn't use namespace but in your 2nd point you talked about namespace... could you tell me more about it ?

Comment by sniegs on 2023-07-11:
@raphael_leber_cpe How I got it working was, I went into the robots .urdf file, and there, by default, would be the link base_link. I renamed it to ns1/base_link and so on. Then you also need to set the prefix variable in your .xacro for each robot and also remember to refer to the namespaced links in the .xacro. Since the links are named differently now, you also need to add the namespace in the mentioned .srdf, kinematics.yaml, joint_states.yaml etc. Regarding the controller, it really depends if you want to change the one you have or add a copy just in case. And for the ur_hardware_interface, I made a simple python publisher, which renames the joint state names to the namespaced ones, so that it gets the correct ones, otherwise it won't connect to your robot. Hopefully, this brings some more detail and helps you!

Comment by raphael_leber_cpe on 2023-07-16:
Thank you very much for the precisions

Improve this answer
$\endgroup$

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.