Revision history [back]

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 a JSP when someone else is publishing the correct joint values.

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.

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.

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

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.

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

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.

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.

EDIT

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 : yaml ):

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