Rosanswers logo


I'm trying to create a new robot model that implements a LIDAR and a camera, all of that using rtabmap_ros.

In order to do that, I created the following basic URDF:

<?xml version="1.0"?>

<robot name="erl_ugv">
  <link name="base_footprint"/>
  <link name="base_link"/>
  <link name="laser_link"/>

  <joint name="base_link_joint" type="fixed">
    <parent link="base_footprint"/>
    <child link="base_link"/>
    <origin xyz="0 0 0.025" rpy="0 0 0"/>

  <joint name="laser_link_joint" type="fixed">
    <parent link="base_link"/>
    <child link="laser_link"/>
    <origin xyz="0.08 0.006 0.44" rpy="0 0 0"/>

(it's the fixed structure of the robot). I also created the parser.cpp file as explained on this tutorial

I tried to make all of this work thanks to the following launch file:

  <arg name="model"/>
  <param name="robot_description" textfile="$(find erl_ugv_description)/urdf/erl_ugv.urdf"/>
  <param name="use_gui" value="true"/>
  <param name="use_sim_time" value="false"/>

  <node name="joint_state_publisher" pkg="joint_state_publisher" type="joint_state_publisher" respawn="false"/>
  <node name="robot_state_publisher" pkg="robot_state_publisher" type="state_publisher"/>

  <node name="rviz" pkg="rviz" type="rviz" args="-d $(find erl_ugv_description)/urdf.rviz" required="true" />

  <node pkg="tf" type="static_transform_publisher" name="base_laser_link" args="0.08 0.006 0.44 0 0 0 /base_link /base_laser_link 100" />
  <node pkg="tf" type="static_transform_publisher" name="laser" args="0.08 0.006 0.44 0 0 0 /base_link /laser 100" />
  <node pkg="tf" type="static_transform_publisher" name="camera_link" args="0.095 0 0.225 0 0 0 /base_link /camera_link 100" />

with erl_ugv_description being the name of the dedicated package created in my catkin_ws

The thing is, when I roslaunch the previous file, I get the expected tf and axes in rviz. But also an error that says

[joint_state_publisher-2] process has died

I'm wondering whether the non completion of this tutorial on creating a state_publisher node with a C++ code is responsible for my failure. I'm asking this here because I don't understand how I could adapt the C++ code to my situation (a fixed structure, so what about the odom_trans, hinc, etc ? ...).

Thanks !


Here is the log of the roslaunch with the launch file pasted at the beginning of this post.

 turtlebot@turtlebot-14:~/erl/logs_new$ roslaunch erl_ugv_description beta.launch... logging to /home/turtlebot/.ros/log/072eb570-7041-11e7-93b9-605718b05f9f/roslaunch-turtlebot-14-4597.log
Checking log directory for disk usage. This may take awhile.
Press Ctrl-C to interrupt
Done checking log file disk usage. Usage is <1GB.

started roslaunch server


 * /robot_description: <?xml version="1....
 * /rosdistro: indigo
 * /rosversion: 1.11.21
 * /use_gui: True
 * /use_sim_time: False

    base_laser_link (tf/static_transform_publisher)
    camera_link (tf/static_transform_publisher)
    joint_state_publisher (joint_state_publisher/joint_state_publisher)
    laser (tf/static_transform_publisher)
    robot_state_publisher (robot_state_publisher/state_publisher)
    rviz (rviz/rviz)


core service [/rosout] found
process[joint_state_publisher-1]: started with pid [4615]
process[robot_state_publisher-2]: started with pid [4616]
process[rviz-3]: started with pid [4619]
process[base_laser_link-4]: started with pid [4620]
process[laser-5]: started with pid [4621]
process[camera_link-6]: started with pid [4626]
Traceback (most recent call last):
  File "/opt/ros/indigo/lib/joint_state_publisher/joint_state_publisher", line 347, in <module>
    jsp = JointStatePublisher()
  File "/opt/ros/indigo/lib/joint_state_publisher/joint_state_publisher", line 108, in __init__
    self.gui = JointStatePublisherGui("Joint State Publisher", self)
  File "/opt/ros/indigo/lib/joint_state_publisher/joint_state_publisher", line 287, in __init__
UnboundLocalError: local variable 'slider' referenced before assignment
[joint_state_publisher-1] process has died [pid 4615, exit code 1, cmd /opt/ros/indigo/lib/joint_state_publisher/joint_state_publisher __name:=joint_state_publisher __log:=/home/turtlebot/.ros/log/072eb570-7041-11e7-93b9-605718b05f9f/joint_state_publisher-1.log].
log file: /home/turtlebot/.ros/log/072eb570-7041-11e7-93b9-605718b05f9f/joint_state_publisher-1*.log

I then choose to kill RVIZ, which me and my colleague thought could handle what the C++ code would be supposed to do (but it doesn't).

================================================================================REQUIRED process [rviz-3] has died!
    process has finished cleanly
    log file: /home/turtlebot/.ros/log/072eb570-7041-11e7-93b9-605718b05f9f/rviz-3*.log
    Initiating shutdown!

Furthermore, when I read this C++ code, it talks about odometry and movement, but my structure (urdf) is fixed !


As said in this old post,

It reads the position of the encoders in all joints and constructs a sensor_msgs/JointState message that is then published on the /joint_states topic.

If you are running on a real robot, you need to implement such a node.

So, I have to write a node that publishes sensors_msgs/JointState, but what to I put inside my node if my urdf is only about fixed joints ?

Originally posted by Blupon on ROS Answers with karma: 127 on 2017-07-21

Post score: 1

Original comments

Comment by jayess on 2017-07-21:
It's not really possible to figure out why the node died without seeing your code. I know that you followed the tutorial, but there could be errors in your code. Also, is that all that ROS is telling you?

Comment by Blupon on 2017-07-24:
that's the thing, I didn't follow the last tutorial with the C++ code (thus, nothing is compiled/executed), because I don't understand the use of this code & a colleague seems to make all of this work without the C++ script.

Comment by Blupon on 2017-07-24:
see my Edit in the question for what ROS is telling me when I roslaunch my custom .launch. See EDIT 2 for question clarification.

Comment by jayess on 2017-07-24:
Did you look into the part of the traceback that says UnboundLocalError: local variable 'slider' referenced before assignment?

Comment by jayess on 2017-07-24:
Also, what were you and your colleague expecting RViz to do? It visualizes topics and information.

Comment by Blupon on 2017-07-24:
Solve (magically ? ... :P) the joint_state_publisher error ... UnboundLocalError: local variable 'slider' referenced before assignment isn't coming from my code. Could it be a ROS code bug ?


1 Answer 1


Rosanswers logo

I believe that the referenced post is in regards to moving joints as encoders for the joints are mentioned. As far as I know if you don't care about publishing moving joints then you should be able to publish the transforms using the urdf file. You will need to give the transformation between base_footprint and odom frames, however.

You'll need a way to publish odometry. Take a look at this navigation tutorial that goes over how to publish the odometry (as an example and for learning purposes). Of course, you can also use a localization package such as rtabmap_ros, as you mentioned in your question. Check out the rtabmap_ros tutorial on navigation and mapping for help with that.


I would say that the joint_state_publisher is unnecessary (and is definitely crashing as you've said). Try running your launch file with out that node running as it isn't necessary. From the joint_state_publisher wiki, the joint_state_publisher

finds all of the non-fixed joints and publishes a JointState message with all those joints defined.

so you shouldn't need it because you only have fixed joints.

For the transforms, you want map -> odom -> base_link -> other_frames (not base_link -> odom). From the hector_mapping wiki, it provides the map -> odom transformations. Now, you just need odom -> base_link.

Yes, rtabmap_ros can provide this transformation! Just look at the section titled 4.3.6 Provided Transforms under the Visual Odometry section and you'll see that it does indeed provide that transform.

Originally posted by jayess with karma: 6155 on 2017-07-24

This answer was ACCEPTED on the original site

Post score: 3

Original comments

Comment by Blupon on 2017-07-24:
the publishing of the transforms does work & they appear in rivz, the aim of my question is to know whether the error logs quoted originate from the lack of a state_publisher node, and how to write such a node if needed. How do I link base_footprint and odom frames, if no odometry is published ?

Comment by Blupon on 2017-07-24:
it doesn't make sense to publish odometry out of nowhere: I want this urdf to describe the robot with which I'm going to use hector_mapping and rtabmap_ros, where hector_mapping will publish odometry thanks to a UTM-30LX lidar, and rtabmap_ros will build an occupancy_grid

Comment by jayess on 2017-07-24:
Updated the answer to (hopefully) clarify things.

Comment by Blupon on 2017-07-25:
You link the turtlebot rtabmap tutorial,which doesn't apply-creating my own robot with dedicated URDF (hence my problems !). I'm using the Kinect + 2D laser tutorial. Indeed, neither hector_mapping nor rtabmap provide TF(base_... -> odom)

Comment by Blupon on 2017-07-25:
Which leads me to 2 questions: 1) is this joint_state_publisher really a problem 2) how to solve it if it's the case ( 3) find that missing TF, but different matter I guess)

Comment by Blupon on 2017-07-25:
Yes ! But the frustrating thing is that robot_state_publisher apparently still needs joint_state_publisher to work & it is responsible for the publication of the fixed joints as well (see wiki)

Comment by jayess on 2017-07-25:
It doesn't need it. I was using it today without the the joint publisher and it worked. From the link in the answer, it says that it can be used with the state publisher.

Comment by Blupon on 2017-07-25:
ok, I wasn't sure of it, but I guess that's possible since I still get the tf defined by the fixed joints in rviz anyway. Thanks ! About rtabmap_ros, I'll look into it, ans ask elsewhere if needed since it's a different matter.


Your Answer

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