Rosanswers logo


This questions can be split into two:

The first one. I am currently using in my URDF in Gazebo a ROS_control controller to control the platform wheels (velocity and position interface) and I am wondering if there is a way to plot the PID values in order to see the performance. Since I do not have any /command/data and /state/process_value topics I cannot plot the behavior of the PIDs.

The second one is related to the first question. Since I do not have those topics I want now to plot the changes on the jointStates. Robot_state_publisher and joint_state_publisher are launched properly but when you read the joint state topic there are certain messages which appear to be empty, this follows a pattern because this empty message happens every 4 messages, the 5th one is the empty one:

  seq: 74
    secs: 7
    nsecs: 400000000
  frame_id: ''
name: [front_right_wheel_steer_joint, front_right_wheel_joint, front_right_shock,
  front_left_wheel_steer_joint, front_left_wheel_joint, front_left_shock,
  back_right_wheel_steer_joint, back_right_wheel_joint, back_right_shock,
  back_left_wheel_steer_joint, back_left_wheel_joint, back_left_shock]
position: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
velocity: []
effort: []

Joint state publisher node is publishing at a rate of 50 and I thought that was the problem, but changes on that value will output the same behavior.

If someone can help me with this I will appreciate.

Thanks in advance.


Here is the launch file:

<?xml version="1.0"?>


  <!-- these are the arguments you can pass this launch file, for example paused:=true -->
  <arg name="gui" default="true"/>
  <arg name="use_joint_state_publisher" default="false"/>
  <arg name="setup" default="setup_4"/> <!-- Different setups for the sensors -->
  <arg name="ultrasonic_on" default="1"/> <!-- Different setups for the sensors -->
  <arg name="zed_on" default="1"/> <!-- Different setups for the sensors -->

  <group ns="ares">

    <!-- Load the URDF into the ROS Parameter Server -->
    <param name="robot_description"
    command="$(find xacro)/xacro --inorder '$(find ares_description)/urdf/bus/ares.xacro' setup:=$(arg setup) 
    ultrasonic_on:=$(arg ultrasonic_on) zed_on:=$(arg zed_on)" />
    <!-- send fake joint values -->
    <node if="$(arg use_joint_state_publisher)" name="joint_state_publisher" pkg="joint_state_publisher" type="joint_state_publisher" output="screen"/>

    <!-- Combine joint values -->
    <node name="robot_state_publisher" pkg="robot_state_publisher" type="robot_state_publisher" output="screen"/>

    <!-- Display with rviz -->
    <node name="rviz" pkg="rviz" type="rviz" respawn="false" output="screen"/>



If you change the parameter use_joint_state_publisher to true the model is well defined in tf and visualize in rviz.

Originally posted by Weasfas on ROS Answers with karma: 1695 on 2019-09-13

Post score: 1

Original comments

Comment by jdlangs on 2019-09-13:
Are you quite sure only a single node is publishing the joint states topic? Typically when I get occasional messages with completely different values it's because there are two nodes publishing on the same topic.

Comment by Weasfas on 2019-09-16:
Hello @jdlangs

In fact there are two Publishers: Gazebo and Joint_state_publisher, but I think that is the correct behavior.

Comment by ffusco on 2019-09-16:
I think what @jdlangs pointed out is most likely the problem. Usually, you would have either gazebo or the joint state publisher sending messages, but not both. The typical use case is: you build your URDF and use the joint state publisher to debug it. Then, as soon as your gazebo simulation is ready, gazebo publishes the actual message and you do not need the other anymore. There are cases in which you might still want the joint state publisher to run, but not in general. The reason is that the joint state publisher generally has an "internal fake state" that is updated via the gui, and thus it would differ from the actual state provided by a simulator. Also, it generally does not include velocity/effort info, making me think this is the problem. Are both gazebo and the joint state publisher sending messages on /joint_states? If so, give it a try without the joint state publisher, and if the problem is still there perhaps include a diagram of running nodes and topics, e.g., from rqt

Comment by Weasfas on 2019-09-16:
As @ffusco said I removed from my launch file the launch of the joint_state_publisher and now all the messages in the /joint_states topic are properly filled. However, now I have the problem of a broken tf tree because I am not able to see the model in rviz.

Comment by ffusco on 2019-09-16:
Is the robot state publisher printing and message on the console? (make sure to add the attribute output=screen in the launch file) In addition, is the RViz robot model display reporting any issue?

Comment by Weasfas on 2019-09-17:
The robot_state_publisher has the attribute output=screen and does not produce any warnings or errors. In Rviz the problem resides in the tf tree, since there are no transforms between the vehicle base and the wheels. Thus, Rviz shows the vehicle chassis but not the wheels.

Comment by gvdhoorn on 2019-09-17:
There is a good chance the node responsible for publishing JointStates is not publishing them for all joints defined in your urdf.

That would cause the RSP to not do FK, leading to missing transforms, causing the error you get in RViz.

Comment by Weasfas on 2019-09-17:
As far as I understood joint_state_publisher node is needed by robot_state_publisher to build the tf tree. The problem rises when Gazebo AND joint_state_publisher node publish on the same topic /joint_states with different messages. I have 12 joints for the wheels: 4 linear movement, 4 steering and 4 shock absorbers. To my knowledge, Gazebo is publishing on /joint_states empty messages with all 12 joints names, while joint_state_publisher node is publishing filled messages with only 8 joints, without the shock ones.

In truth I only want this data to debug what is happening in the wheels... I decided to record a rosbag and filter the empty messages. But I do not really able to understand and find why this empty messages are produced.

I am going to update the question with my launch file.

Comment by gvdhoorn on 2019-09-17:\

As far as I understood joint_state_publisher node is needed by robot_state_publisher to build the tf tree.

No, it's not. JointState messages are consumed by RSP. So something that publishes those is needed. JSP is only one possible 'something'. But Gazebo, with the right plugins, can also publish JointState messages. Having them both -- for the complete URDF (ie: all joints) -- is going to lead to conflicts.

re: gazebo vs other publishers: think of Gazebo as a stand-in for the hardware (or really: just the dynamic behaviour of your hw). Think of Gazebo plugins as drivers.

Would you run an instance of JSP next to your hw drivers? Would that lead to conflicting messages? If you wouldn't run it, then don't run it when you use Gazebo.

If you need to run JSP, because of missing joints in the msgs from Gazebo, then you might want to update your Gazebo model to include the missing joints.


1 Answer 1


Rosanswers logo

I will gather what we said in a short answer.

First of all, you should not have multiple nodes publishing on the same /joint_states topic, since this will likely lead to weird behaviors, like the one you were getting. In general, you firstly want to have a joint_state_publisher (JSP) running so that you can debug your URDF. When you are ok with that, you can then switch to simulating the robot in Gazebo. Since you use ROS control, I assume that a JointStateController or similar will be publishing the wheel angles on the /joint_states topic. From that point on, you want in general not to run the JSP node as well. This is because it will provide values which do not match with the simulation: the JSP node keeps an internal fake state and since it is not updated elsewhere, Gazebo will say, e.g., that the joint front_right_wheel_steer_joint has an angle of 1.4 radians while JSP might publish for the same joint the value -5.8. This can lead to different issues later on. Long story short, again: do not use a JSP when someone else is publishing the correct joint values, in general.

Time to address specifically the issue with the "incomplete" TF. The issue comes from the fact that Gazebo publishes only 4 wheels angles, despite your robot having more moving joints. In the future, you should try to give more information about your robot, e.g., by sharing the URDF or simply more info about it. By doing this, you will make us "guess less" and give you better answers ;)

The point is this: the robot_state_publisher (RSP) node expects to receive full information about the current configuration. This means that sooner or later, you have to provide all joint coordinates into the /joint_states topic. In your setup, Gazebo will only publish 4 values, and therefore this is not enough to evaluate all transforms. If you add the JSP as you did, every so and then the published state will mismatch the one obtained in the simulation. The workaround that I can propose is rather simple, but it is, in my opinion, sub-optimal. What you can do is to actually use both Gazebo and the JSP but in a different way. In its documentation, it is written that JSP allows to "listen" to various sources, listed in the parameter source_list. In addition, unless the parameter publish_default_positions is set to False, JSP will always publish all joint values, either using "known values" or their defaults. You can thus make the Gazebo controller publish in a topic named, e.g., wheels_states. Then, start the JSP, listening to such topic, i.e., with source_list=[wheels_states]. In this way, JSP will start by publishing all joints set to zero, and as soon as Gazebo is able to provide the actual value of the wheels, fake values will be replaced with actual ones. This way, the RSP will finally be able to publish all transforms you need.

The reason why I define this solution "sub-optimal" is that all other joints are all supposed to be zero, which might be not exactly what you need. A better solution would be to have other plugins publishing the state of the missing joints, and to "merge" all values using the JSP.


As remarked in the comments, it is also possible to achieve a similar solution directly using the JointStateController, removing the need for the intermediate JSP. It should be possible to do that from the configuration of the controller (code taken from here ):

  type: joint_state_controller/JointStateController
  publish_rate: 50
  - name: 'extra1'
    position: 10.0
    velocity: 20.0
    effort: 30.0
  - name: 'extra2'
    position: -10.0
  - name: 'extra3'

Originally posted by ffusco with karma: 271 on 2019-09-17

This answer was ACCEPTED on the original site

Post score: 3

Original comments

Comment by gvdhoorn on 2019-09-17:
Good answer.

Just to add: joint_state_controller can be configured to publish values for "extra joints" (ie: those it is not configured for). I haven't seen it documented anywhere but here (in the header file of the class).

it's static values only, but it would avoid having to run a JSP just for the joints the Gazebo sim is not publishing and would avoid having to use a source_list JSP.

Comment by Weasfas on 2019-09-18:
Ok. In the future I will take into account the suggestions @ffusco provide.

Actually, I will mark your answers as correct because I was able to fix all the TF tree and problems regarding the controller with this lines:

  # Publish all joint states -----------------------------------
    type: joint_state_controller/JointStateController
    publish_rate: 50
     - name: front_left_shock
       position: 0.01
       velocity: 0.0
       effort: 0.0

     - name: front_right_shock
       position: 0.01
       velocity: 0.0
       effort: 0.0

     - name: back_left_shock
       position: 0.01
       velocity: 0.0
       effort: 0.0

     - name: back_right_shock
       position: 0.01
       velocity: 0.0
       effort: 0.0

It turned out to be that the controller interface was not fully completed with all URDF joints.

Comment by ffusco on 2019-09-19:
Glad we helped! :)


Your Answer

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