Fetch robot, joint_state topic sometimes contains all joints, sometimes doesn't
I am programming with the Fetch robot (the physical one, not Gazebo simulation).
I use my laptop with the following settings:
- Macbook Pro Late 2013 edition
- Ubuntu 14.04 installed as sole operating system
- ROS Indigo
- Plus the Fetch ROS from here.
Also the ROS variables:
<fetch>~/FETCH_CORE/fetch_core$ env | grep ROS
ROS_ROOT=/opt/ros/indigo/share/ros
ROS_PACKAGE_PATH=/opt/ros/indigo/share:/opt/ros/indigo/stacks
ROS_MASTER_URI=http://fetch59.local:11311
ROSLISP_PACKAGE_DIRECTORIES=
ROS_DISTRO=indigo
ROS_IP=10.0.0.121
ROS_HOME=/home/daniel/.ros
ROS_ETC_DIR=/opt/ros/indigo/etc/ros
I have the following ROS topics:
<fetch>~/FETCH_CORE/fetch_core$ rostopic list
/arm_controller/cartesian_twist/command
/arm_controller/follow_joint_trajectory/cancel
/arm_controller/follow_joint_trajectory/feedback
/arm_controller/follow_joint_trajectory/goal
/arm_controller/follow_joint_trajectory/result
/arm_controller/follow_joint_trajectory/status
/arm_with_torso_controller/follow_joint_trajectory/cancel
/arm_with_torso_controller/follow_joint_trajectory/feedback
/arm_with_torso_controller/follow_joint_trajectory/goal
/arm_with_torso_controller/follow_joint_trajectory/result
/arm_with_torso_controller/follow_joint_trajectory/status
/base_controller/command
/base_scan
/base_scan_no_self_filter
/base_scan_raw
/base_scan_tagged
/battery_state
/charge_lockout/cancel
/charge_lockout/feedback
/charge_lockout/goal
/charge_lockout/result
/charge_lockout/status
/cmd_vel
/cmd_vel_mux/selected
/diagnostics
/diagnostics_agg
/diagnostics_toplevel_state
/dock/result
/enable_software_runstop
/graft/state
/gripper/gyro_offset
/gripper/imu
/gripper/imu_raw
/gripper_controller/gripper_action/cancel
/gripper_controller/gripper_action/feedback
/gripper_controller/gripper_action/goal
/gripper_controller/gripper_action/result
/gripper_controller/gripper_action/status
/gripper_controller/led_action/cancel
/gripper_controller/led_action/feedback
/gripper_controller/led_action/goal
/gripper_controller/led_action/result
/gripper_controller/led_action/status
/gripper_state
/head_camera/crop_decimate/parameter_descriptions
/head_camera/crop_decimate/parameter_updates
/head_camera/depth/camera_info
/head_camera/depth/image
/head_camera/depth/image_raw
/head_camera/depth/image_rect
/head_camera/depth/image_rect_raw
/head_camera/depth/points
/head_camera/depth_downsample/camera_info
/head_camera/depth_downsample/image_raw
/head_camera/depth_downsample/points
/head_camera/depth_rectify_depth/parameter_descriptions
/head_camera/depth_rectify_depth/parameter_updates
/head_camera/depth_registered/camera_info
/head_camera/depth_registered/hw_registered/image_rect
/head_camera/depth_registered/hw_registered/image_rect_raw
/head_camera/depth_registered/image
/head_camera/depth_registered/image_raw
/head_camera/depth_registered/points
/head_camera/depth_registered_rectify_depth/parameter_descriptions
/head_camera/depth_registered_rectify_depth/parameter_updates
/head_camera/driver/parameter_descriptions
/head_camera/driver/parameter_updates
/head_camera/head_camera_nodelet_manager/bond
/head_camera/ir/camera_info
/head_camera/ir/image
/head_camera/projector/camera_info
/head_camera/rgb/camera_info
/head_camera/rgb/image_raw
/head_camera/rgb/image_rect_color
/head_camera/rgb_rectify_color/parameter_descriptions
/head_camera/rgb_rectify_color/parameter_updates
/head_controller/follow_joint_trajectory/cancel
/head_controller/follow_joint_trajectory/feedback
/head_controller/follow_joint_trajectory/goal
/head_controller/follow_joint_trajectory/result
/head_controller/follow_joint_trajectory/status
/head_controller/point_head/cancel
/head_controller/point_head/feedback
/head_controller/point_head/goal
/head_controller/point_head/result
/head_controller/point_head/status
/imu
/imu1/gyro_offset
/imu1/imu
/imu1/imu_raw
/imu2/gyro_offset
/imu2/imu
/imu2/imu_raw
/joint_states
/joy
/laser_self_filter/cancel
/laser_self_filter/feedback
/laser_self_filter/goal
/laser_self_filter/result
/laser_self_filter/status
/odom
/odom_combined
/query_controller_states/cancel
/query_controller_states/feedback
/query_controller_states/goal
/query_controller_states/result
/query_controller_states/status
/robot_state
/robotsound
/rosout
/rosout_agg
/sick_tim551_2050001/parameter_descriptions
/sick_tim551_2050001/parameter_updates
/software_runstop_enabled
/sound_play/cancel
/sound_play/feedback
/sound_play/goal
/sound_play/result
/sound_play/status
/teleop/cmd_vel
/tf
/tf_static
/torso_controller/follow_joint_trajectory/cancel
/torso_controller/follow_joint_trajectory/feedback
/torso_controller/follow_joint_trajectory/goal
/torso_controller/follow_joint_trajectory/result
/torso_controller/follow_joint_trajectory/status
So far so good. Now I want to check the joint angles. What I often do here is echo the corresponding ROS topic. Here I call rostopic echo -n 1 /joint_states repeatedly. I press ENTER on my keyboard, then I count 4-5 seconds in my head, then press ENTER again, then count 4-5 seconds, press ENTER again, and so forth. Check out the output after running this several times:
<fetch>~/FETCH_CORE/fetch_core$ rostopic echo -n 1 /joint_states
header:
seq: 63846
stamp:
secs: 1526495986
nsecs: 155393416
frame_id: ''
name: ['l_gripper_finger_joint', 'r_gripper_finger_joint']
position: [0.004585660994052887, 0.004585660994052887]
velocity: [-4.410743713378906e-06 ...
No, they're not. Either the gripper joints are there, or the others.
I don't have a Fetch, but the gripper probably uses a separate
JointStatepublisher, which only publishes for the gripper. The other joints .... are published by another
JointStatepublisher.That is all perfectly valid and supported. What I don't understand though is why Fetch would configure their robot that way. Typically different publishers would be placed in separate namespaces and
joint_state_publisherwould be configured .... with the
source_listparameter to subscribe to all topics, coalesce the msgs into a singleJointStatemsg and publish that on/joint_states.You'd have to check the documentation and / or ask Fetch as to why that is not the case here.
Sorry, you are are right, I did not read carefully. Yeah it's either the gripper or the joints. Yeah let me look over at the Fetch github repository for ROS (their actual docs don't explain this topic)
I found an explanation somewhat https://github.com/cse481wi18/cse481w... embarrassed that I didn't see this earlier. The wiki says that each message may only contain a subset of the joints. I see.
I would be very surprised if there was no documentation at all about this topic. I'd really recommend you ask them. If you have one of their robots, you should be entitled to some support, no?
Yes, all customers are entitled to support, and we're usually busy with the commercial side of things so ROS answers aren't the best way to get help.
I know this is documented somewhere more officially - I'll try to get a link.