Controller files not compatible when prefix used with gen3_macro.xacro

[aamirhatim]

My scenario:
I'm calling gen3_macro.xacro within another xacro file I am making, following a similar setup described in kortex_description/robots/*. The only difference is that I am adding a value for prefix instead of passing an empty string. The model will load fine in Gazebo, but I get errors from the controller(s) launched from <arm>/<dof>/config/joint_position_controllers.yaml saying that joint_{x} does not exist (since the prefix I added in the xacro changed all joint names but the controller is looking for joints without the prefix).

Current workaround:
I've edited joint_position_controllers.yaml file by adding my prefix to the beginning of each joint name listed in the controller params. With this change, everything looks to be working as expected.

Potential fix:
Was this functionality intentional? Is it up to the developer to make their own controller file if a prefix is used? A possible fix could be to add $(arg prefix) before all the joint names and load the yaml file with the subst_value='true' arg set when loading the params to the parameter server.

[alexvannobel]

Hi @aamirhatim ,

Sorry for the delay.
Glad you found a workaround. The prefix logic was implemented for the real arm, but not for simulation. I'll be working on refactoring a bit how simulation works in ros_kortex in the next few weeks so I'll slip this bugfix in my work.

I'll let you know when the correct behaviour will be merged to the repo.
Thanks for the feedback,
Alex

[aamirhatim]

Awesome. As part of the sim refactoring, incorporating a camera into the bracelet would be great as well.

[alexvannobel]

Hi @aamirhatim ,

I just made the release for the simulation improvements in kinetic-devel. You can read the release notes here.

The prefix option now correctly prefixes MoveIt configuration files as well as xacro files, so you can use prefix and robot_name to create multiple instances of robots on the same ROS network without them interacting together.

I'll close the issue, but don't hesitate to reopen it or create a new one if you encounter a problem.

As for the camera simulation in Gazebo, it was not included in the scope of this work and not planned for the short term. You can open an issue that we'll keep in mind for the next release if you wish, or add it yourself. Intel has a repo for the Realsense simulation, but I don't know if it's up-to-date

Best,
Alex