Rosanswers logo

I currently have a node publishing /joint_states messages with a urdf loaded to the param server.

When running the robot_state_publisher, I get the following output: (snapshot of ~88 Hz published message)

transforms: []
      seq: 0
        secs: 1332281271
        nsecs: 616639689
      frame_id: /robot_j4
    child_frame_id: /robot_tool_plate
        x: -0.045
        y: -0.3
        z: 0.0
        x: 0.707106781185
        y: 0.0
        z: 0.0
        w: 0.707106781188

The published joint_states message is (snapshot of 100 Hz published message):

  seq: 19372
    secs: 1332281452
    nsecs: 512223606
  frame_id: ''
name: ['robot_j1', 'robot_j2', 'robot_j3', 'robot_j4', 'robot_j5', 'robot_j6', 'robot_j7']
position: [0.021256590917843883, -2.0106822865351295, -0.024265641198750076, 3.1044362300610073, 0.18289162692677774, -0.089429498510240221, 0.042228138233154626]
velocity: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.05145228488671999]
effort: [-7.8622921298201127e-17, 15.941268784846988, -0.24966792233529578, -4.0081856483693521, -0.043474127200907126, -0.20694576889532121, -0.00066716196395994474]

I have checked the correctness of the urdf with the parser, and can verify that the urdf is correctly loaded on the param server with name: robot_description. The transform that it is publishing (robot_j4 -> robot_tool_plate) is a fixed joint, aka robot_state_publisher is not publishing any moveable joints.

Also, the urdf that I have loaded is a configuration with only four joints (robot_j1, robot_j2, robot_j3, robot_j4). Does the urdf have to directly correlate the published joint_states?

The joint_state messages are being published at 100Hz, is this too fast for the robot_state_publisher?


Originally posted by kmaroney on ROS Answers with karma: 204 on 2012-03-20

Post score: 1


2 Answers 2


Rosanswers logo

The tutorial does state that "A source that publishes the joint positions" is required by robot_state_publisher. I've also gotten "missing moveable joints transforms" when I launched robot_state_publisher without launching joint_state_publisher.

I don't quite understand why you would not want urdf to correlate to published joint states. The urdf describes the robot. Wouldn't you want to describe the robot completely (with all joints and links)?

I think the publishing frequency is just limited by your computing speed. The robot_state_publisher would take the latest states available anyway. (I'm using 20Hz, and my simple 2 wheel robot runs fine)

Originally posted by weiin with karma: 2268 on 2012-03-20

This answer was ACCEPTED on the original site

Post score: 0

Original comments

Comment by kmaroney on 2012-03-20:
I am sure that my robot is publishing /joint_states (sensor_msgs/JointState). This covers the source of the joint position publishing. The reasoning for the urdf discrepancy is because my robot has multiple configurations, this configuration allows me to avoid redundant messages.

Comment by weiin on 2012-03-20:
I ran my code again, launching only robot_state_publisher and joint_state_publisher. It does seem that the moveable joints are not published all the time. But rosrun tf view_frames would show all joints being published.

Comment by weiin on 2012-03-20:
From the tutorial above, "The map with joints does not contain all the joints that exist in the kinematic model. Note that it is okay for the map to contain extra joints that are not part of the kinematic model." could explain this (urdf discrepancy should not be an issue then)

Comment by kmaroney on 2012-03-21:
I think we may be zeroing in on the issue.. When running rosrun tf view_frames, it does not show all of the joints, only the two previously published. I will keep looking into this and report back.

Comment by Wim on 2012-03-26:
It would be useful if you could attach the tree representation of your urdf description, and of your tf tree. You can use the commands "rosrun urdf_parser urdf_to_graphiz your_urdf.xml" and "rosrun tf view_frames" to generate pdf files that show the tree structure.

Comment by McMurdo on 2014-07-01:
Did you find the answer? I have the same issue!


Rosanswers logo

I had the same issue with my own URDF model and finally I could solve it. The robot_state_publisher needs basically only two information to run:

  1. A URDF model in XML format on the parameter server. The default parameter is: /robot_description
  2. A msg of the type sensor_msgs::JointState on the topic /joint_states

I found this information in the FAQ of tf

The important information I forgot first by sending out my /joint_state msg is the timestamp in the msg header! Without the time information the robot_state_publisher is not able to calculate the tf frames for the moving joints. Inside of the code this means the following for me:

// Setup the publisher for the /joint_states msg
ros::Publisher pub_js = nh.advertise<sensor_msgs::JointState>("/joint_states", 100);    
sensor_msgs::JointState msg;            // Create an object of the sensor_msgs::JointState

msg.name.push_back("My_Joint_Name");    // This must be the joint_name that is used inside of the URDF file
msg.position.push_back(0.0);            // Set a value for this joint

msg.header.stamp = ros::Time::now();    // Stamp this message with the actual time
pub_js.publish(msg);                    // Publish the message

I hope this will solve your problem as well!

Originally posted by iBot with karma: 11 on 2015-08-19

This answer was NOT ACCEPTED on the original site

Post score: 1

Original comments

Comment by rikkimelissa on 2015-10-13:
This comment solved my problem! Did not realize the JointState frame_ids needed to match. Thank you!!


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.