Fetch robot, joint_state topic sometimes contains all joints, sometimes doesn't

asked 2018-05-16 13:52:37 -0600

DanielSeita
46 ●2 ●3 ●8

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 ...

(more)

edit retag flag offensive close merge delete

Comments

Notice that in two of the above cases, all the links of the Fetch are present.

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 JointState publisher, which only publishes for the gripper. The other joints ..

gvdhoorn ( 2018-05-16 14:18:38 -0600 )edit

.. are published by another JointState publisher.

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_publisher would be configured ..

gvdhoorn ( 2018-05-16 14:21:09 -0600 )edit

.. with the source_list parameter to subscribe to all topics, coalesce the msgs into a single JointState msg 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.

gvdhoorn ( 2018-05-16 14:22:08 -0600 )edit

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)

DanielSeita ( 2018-05-16 14:37:33 -0600 )edit

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.

DanielSeita ( 2018-05-16 14:38:56 -0600 )edit

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?

gvdhoorn ( 2018-05-16 14:40:27 -0600 )edit

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.

Moriarty ( 2019-08-14 02:15:39 -0600 )edit

add a comment

answered 2018-05-16 17:24:08 -0600

DanielSeita
46 ●2 ●3 ●8

As gvdhoorn mentioned, I made a mistake here, either the gripper joints are there, or the other joints are there.

This is expected behavior. See this Wiki for the reference.

Luckily for us, the robot continuously publishes the current joint angles to the /joint_states topic. However, each message might only contain a subset of the joints. This works because multiple nodes can publish the state of the subset of joints they are responsible for. This is how /joint_states works on the real robot. However, in simulation, all of the joint states are published by Gazebo.

Because no single message on the /joint_states topic will necessarily tell us about all the joints of the robot, we must listen to multiple messages over time and accumulate the full state of the robot. In practice, the joint states are published very quickly, so we will not have to wait long.

edit flag offensive delete link

Comments

Note that the wiki you link to is not in any way 'official'. It's just a page on a wiki for a course. I would still recommend to ask Fetch about this.

we must listen to multiple messages over time and accumulate the full state of the robot

as I wrote, there are standard tools that can do ..

gvdhoorn ( 2018-05-17 02:17:22 -0600 )edit

.. this for you, no need to implement it in all consumers. But to be able to use those tools, things have to be configured in a certain way. That is where Fetch comes in, as they must have had a reason to configure your robot the way it is.

gvdhoorn ( 2018-05-17 02:17:59 -0600 )edit

I have contacted Fetch support directly. Thank you for the suggestion.

DanielSeita ( 2018-05-17 12:27:28 -0600 )edit

If/when you get a response, it would be great if you could update your answer.

gvdhoorn ( 2018-05-17 12:28:23 -0600 )edit

I believe the reason the gripper state publishes separately from the rest of the robots states is because the gripper is modular. Other grippers can be purchased from Schunk, Shadow, Robotiq and used on the Fetch, it has the same gripper mount as other commercially available robots.

I agree this needs to be documented somewhere more clearly.

Moriarty ( 2019-08-14 02:28:11 -0600 )edit

Thanks @Moriarty!

DanielSeita ( 2019-08-14 14:16:01 -0600 )edit

add a comment

Fetch robot, joint_state topic sometimes contains all joints, sometimes doesn't

Comments

1 Answer

Comments

Question Tools

Stats

Related questions

Fetch robot, joint_state topic sometimes contains all joints, sometimes doesn't edit

Comments

1 Answer

Comments

Question Tools

Stats

Related questions

Fetch robot, joint_state topic sometimes contains all joints, sometimes doesn't