Empty /rrbot/position_trajectory_controller/command

[famora2]

Hi all,

using the provided example, I have typed:

roslaunch ros_control_boilerplate rrbot_simulation.launch 
roslaunch ros_control_boilerplate rrbot_visualize.launch 
roslaunch ros_control_boilerplate rrbot_test_trajectory.launch

Although the robot successfully follows the robot, I have one question:

Why is rostopic echo /rrbot/position_trajectory_controller/command empty all the time? Could you please explain what the intention of this topic is and how to use it properly?

$rostopic info /rrbot/position_trajectory_controller/command
Type: trajectory_msgs/JointTrajectory

Publishers: None

Subscribers: 
 * /rrbot/rrbot_hardware_interface (http://192.168.2.101:45451/)

[RobertWilbrandt]

Hey,

short answer: The rrbot_test_trajectory launch file uses the action-based interface of the joint_trajectory_controller to command the robot. The command topic is a different way to control the robot that is useful when you have to update the trajectory on the fly.

Longer explanation: In the ros_control framework, this package only provides the simulated hardware interface of the robot - this means that it only simulates how ros_controlcan interact with (simulated) joints, but doesn't implement the controllers that operate on it (in this case the position_trajectory_controller of type joint_trajectory_controller/JointTrajectoryController). This hardware interface is implemented in include/ros_control_boilerplate/sim_hw_interface.h and only provides very low-level access to each joint.

For documentation on the /rrbot/position_trajectory_controller/command topic, you have to look for the documentation of that specific controller - the joint_trajectory_controller. Section 2.1 describes the basic differences between the FollowJointTrajectoryAction-based interface used in this demo and the topic interface.

The most common use of this topic i see is the rqt_joint_trajectory_controller gui, which you can use to jog your robot manually. Another use case is periodic replanning of the robot trajectory, because you can just send a new trajectory once you have it planned and the joint_trajectory_controller will take care of the transition from the previous trajectory to your new one.

In most cases you should not have to care about this topic, as outlined in the documentation the action interface is much easier to use correctly and provides the semantics most commonly needed.

Did this answer your questions?

[Sofiap91]

Hey,

short answer: The rrbot_test_trajectory launch file uses the action-based interface of the joint_trajectory_controller to command the robot. The command topic is a different way to control the robot that is useful when you have to update the trajectory on the fly.

Longer explanation: In the ros_control framework, this package only provides the simulated hardware interface of the robot - this means that it only simulates how ros_controlcan interact with (simulated) joints, but doesn't implement the controllers that operate on it (in this case the position_trajectory_controller of type joint_trajectory_controller/JointTrajectoryController). This hardware interface is implemented in include/ros_control_boilerplate/sim_hw_interface.h and only provides very low-level access to each joint.

For documentation on the /rrbot/position_trajectory_controller/command topic, you have to look for the documentation of that specific controller - the joint_trajectory_controller. Section 2.1 describes the basic differences between the FollowJointTrajectoryAction-based interface used in this demo and the topic interface.

The most common use of this topic i see is the rqt_joint_trajectory_controller gui, which you can use to jog your robot manually. Another use case is periodic replanning of the robot trajectory, because you can just send a new trajectory once you have it planned and the joint_trajectory_controller will take care of the transition from the previous trajectory to your new one.

In most cases you should not have to care about this topic, as outlined in the documentation the action interface is much easier to use correctly and provides the semantics most commonly needed.

Did this answer your questions?

Hello, sorry to intrude in this question, but as mine is a little associated, I figure I could comment here. What would then be a proper way to implement a hardware interface using trajectories? In the test_trajectory.cpp an action client is implemented and a trajectory goal is sent to the server. I guess the HI should somehow get this goal and send it to the actuators, but how? I believe you meant it is done in the sim_hw_interface.h, but I do not understand where this is done in any of the codes.

In what I am doing, I have a moveit commander server planning and sending the goals to the action server. But the part that sends these goals to the actuators is the one I do not fully understand. I could subscribe to the goal topic, but is that the best way?

Thank you very much in advance!