About /joint_states publishers

[mcres]

trafficstars

Executing the launch file needed to control a robot, e.g.

ros2 launch xarm_moveit_config uf850_moveit_fake.launch.py

generates two Nodes that publish to the /joint_states topic:

1. /uf_robot_fake_hw, which is defined here.
2. /joint_state_publisher, which in the case of the previous launch file is defined here.

Click to see the full rosgraph

With the previous in mind, I'd like to clarify the following aspects:

1. Why is the uf_robot_hardware/UFRobotFakeSystemHardware ros2_control plugin used, instead of simply using mock_components/GenericSystem? Is there any substantial difference?
2. Why is the joint_state_publisher package used, instead of just spawning a joint_state_broadcaster ros2_controller? The fact of those controllers being defined — e.g. here, but not used stresses this question.

Apart from those questions, the motivation of this ticket comes from the fact that while integrating the Robotiq 2F-85 gripper, I had to replace the joint_state_publisher and spawn the joint_state_broadcaster instead. Otherwise, action requests to the robotiq_gripper_controller action server would lead to no change in the gripper's position or whatsoever. After performing that change, I am able to ros2_control both robot and the Robotiq gripper.

[vimior]

@mcres Sorry for causing you trouble.

The use of uf_robot_hardware/UFRobotFakeSystemHardware was decided because the early development function was not stable. Sorry, I did not follow up with ros2_control in time. We will use fake_components/GenericSystem or mock_components/GenericSystem for different branches in the next update.

Regarding joint_state_broadcaster, I am sorry that it is indeed defined but not used. Instead, joint_state_publisher is used. Thank you for your pointing out. We will use joint_state_broadcaster instead of joint_state_publisher in the next update.

Thank you for your support and suggestions.

[mcres]

@vimior thank you for promptly clarifying the details and addressing the feedback!