Ask Your Question

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

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

DanielSeita gravatar image

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

I have the following ROS topics:

<fetch>~/FETCH_CORE/fetch_core$ rostopic list

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
  seq: 63846
    secs: 1526495986
    nsecs: 155393416
  frame_id: ''
name: ['l_gripper_finger_joint', 'r_gripper_finger_joint']
position: [0.004585660994052887, 0.004585660994052887]
velocity: [-4.410743713378906e-06 ...
edit retag flag offensive close merge delete


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 gravatar imagegvdhoorn ( 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 gravatar imagegvdhoorn ( 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 gravatar imagegvdhoorn ( 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 gravatar imageDanielSeita ( 2018-05-16 14:37:33 -0600 )edit

I found an explanation somewhat 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 gravatar imageDanielSeita ( 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 gravatar imagegvdhoorn ( 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 gravatar imageMoriarty ( 2019-08-14 02:15:39 -0600 )edit

1 Answer

Sort by ยป oldest newest most voted

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

DanielSeita gravatar image

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 more


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 gravatar imagegvdhoorn ( 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 gravatar imagegvdhoorn ( 2018-05-17 02:17:59 -0600 )edit

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

DanielSeita gravatar imageDanielSeita ( 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 gravatar imagegvdhoorn ( 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 gravatar imageMoriarty ( 2019-08-14 02:28:11 -0600 )edit

Thanks @Moriarty!

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

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools



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

Seen: 291 times

Last updated: May 16 '18