ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

robot_state_visualize - no transform rviz error

asked 2019-06-26 06:42:35 -0500

cpetersmeier gravatar image

updated 2022-01-22 16:09:59 -0500

Evgeny gravatar image

Hello everyone,

I have a question regarding the use of the robot_state_visualize launch file, provided by the ros industrial packages. Any help or and or feedback is greatly appreciated, thanks in advance!

My Setup:

I have a single Windows PC running Roboguide and a Linux Ubuntu VM. I am using the Fanuc M20IA35m Robot.

My Goal:

I want to use ROS to do trajectory planning around obstacles.

My Problem:

Since the M20IA35m Robot is not officially supported, I created my own moveit_configuration.

  1. Autogenerated demo.launch file - works
  2. Fanuc_driver in roboguide and connection to Linux system - works

The next step for me was to test the provided launch files from the fanuc repository on github. I adapted them to my robot by changing the names in the files according to my moveit config.

The interface_streaming.launch and the test.launch files work without issues. The robot_state_visualizer does not work. More concrete, Rviz does not have transforms for the joints. The model is not correctly loaded and every link appears in white and centers in the screen.

For every link I get:

No transform from [robot_base] to [link_1]

The solution from this and this threat (adding a joint state publisher) did not fix my problem. Also a point of confusion for me is that the joint state publisher is not a part of the interface streaming launch file, which works fine for me.

Here is the code of the robot_state_visualize launch file:

<arg name="robot_ip" doc="IP of controller" />
<arg name="J23_factor" default="1" doc="Compensation factor for joint 2-3 coupling (-1, 0 or 1)" />
<arg name="use_bswap" default="true" doc="If true, robot driver will byte-swap all incoming and outgoing data" />

<rosparam command="load" file="$(find fanuc_m20ia35m_moveit_config)/config/joint_names_m20ia35m.yaml" />

<include file="$(find fanuc_driver)/launch/robot_state.launch">
<arg name="robot_ip"   value="$(arg robot_ip)" />
<arg name="J23_factor" value="$(arg J23_factor)" />
<arg name="use_bswap"  value="$(arg use_bswap)" />

<node name="robot_state_publisher" pkg="robot_state_publisher" 
      type="robot_state_publisher" />

 <include file="$(find fanuc_m20ia35m_moveit_config)/launch/custom/load_m20ia.launch" />

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

Further questions:

-> Moved to a new threat.


For reference, here is my top level xacro file:

<?xml version="1.0" ?>         
<robot name="fanuc_m20ia35m" xmlns:xacro="">

<!-- include macros for M-20iA35m and the eef model -->
<xacro:include filename="./m20ia35m_macro.xacro"/>
<xacro:include filename="./eef_description_macro.xacro"/>

<!-- create the robot + eef combo itself as a macro -->
<xacro:macro name="fanuc_m20ia35m_with_eef" params="prefix">

<!-- instantiate M-20iA35m and eef model -->
<xacro:fanuc_m20ia35m prefix="${prefix}robot_" />
<xacro:eef_description prefix="${prefix}eef_" />

<!-- attach eef to M-20iA35m model -->
<!-- Note: this assumes that the 'my_eef' macro defines a 'base_link' link which is the start of it's kinematic chain (if any) -->
<joint name="${prefix}robot_flange-${prefix}eef_base_link_gripper" type="fixed">
<origin xyz="0 0 0 ...
edit retag flag offensive close merge delete


Seeing as you're German: are you using a German locale in your Ubuntu? What is the output of echo $LC_NUMERIC?

This could be #q272692.

As to your other questions: please don't include multiple questions in a single post. It doesn't work very well with Askbot (which is what the underlying software is of ROS Answers).

Also: how are you starting that launch file? Which arguments do you pass it?

gvdhoorn gravatar image gvdhoorn  ( 2019-06-26 06:47:51 -0500 )edit

The output of echo $LC_NUMERIC is empty.

cpetersmeier gravatar image cpetersmeier  ( 2019-06-26 06:52:38 -0500 )edit

I am starting the launch file this way:

roslaunch fanuc_m20ia35m_moveit_config robot_state_visualize_m20ia35m.launch robot_ip:= use_bswap:=false
cpetersmeier gravatar image cpetersmeier  ( 2019-06-26 06:53:17 -0500 )edit

The error you mention essentially means that robot_state_publisher is not publishing any TF frames. That typically happens if it doesn't receive any JointState messages.

What is the output of rostopic echo -n1 /joint_states after you've started the launch file?

LC_NUMERIC being empty is unexpected. What is your systems locale configured as? German or English?

Additionally: those .launch files are supposed to be hosted by robot support packages (ie: fanuc_m20ia_support) not the MoveIt configuration packages.

gvdhoorn gravatar image gvdhoorn  ( 2019-06-26 06:58:44 -0500 )edit

Further questions:

-> Moved to a new threat.

no need to get all hostile ;)

gvdhoorn gravatar image gvdhoorn  ( 2019-06-26 07:04:20 -0500 )edit

The output of rostopic echo -n1 /joint_states is:

  seq: 1874
    secs: 1561557936
    nsecs: 470417936
  frame_id: ''
name: [joint_1, joint_2, joint_3, joint_4, joint_5, joint_6]
position: [-1.7469513416290283, 0.655272364616394, 0.09550565481185913, -1.110461711883545, 
-1.4808560609817505, -2.563765525817871]
velocity: []
effort: []

When I run $ locale I get this output:

cpetersmeier gravatar image cpetersmeier  ( 2019-06-26 07:08:09 -0500 )edit

I'm slightly confused:

The output of echo $LC_NUMERIC is empty.


When I run $ locale I get this output:


that doesn't add up.

In any case, this does not appear to be a problem with a German locale.

So joint states are being published.

What is the currently configured Fixed Frame in RViz? Is that the root of your robot's model?

gvdhoorn gravatar image gvdhoorn  ( 2019-06-26 07:10:27 -0500 )edit

no need to get all hostile ;)

Wasnt meant hostile! I am sorry if that came across this way. I thought I might just follow the guidelines and reedit my post. I very much appreciate the help :)

cpetersmeier gravatar image cpetersmeier  ( 2019-06-26 07:11:04 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2019-06-27 10:09:58 -0500

gvdhoorn gravatar image

updated 2019-06-27 10:25:44 -0500

After taking a look at your files I believe the problem is the names you've chosen for the joints in the m20ia35m_macro.xacro file:

<joint name="${prefix}joint_1__base_link_link_1" type="revolute">

joint_1__base_link_link_1 is a valid joint name, but if you use non-standard joint names, you'll have to make sure you list those same names in the joint_names_m20ia35m.yaml. Otherwise the robot_state_publisher can't match the incoming JointState messages with the joints in your urdf.

I would strongly suggest to use the standard joint names joint_N where N <- [1, ..] (ie: just number them in natural order: joint_1, joint_2, etc). Unless you have very strong reasons not to do so, in that case you'd have to change the names in joint_names_m20ia35m.yaml.

Edit: some general other comments:

  • just place your m20ia35m_macro.xacro and m20ia35m.xacro in the fanuc_m20ia_support package. I'm not sure why you're using a separate package to host it
  • don't place files that are shared among other instances of M-20iA/35m in the MoveIt package. Specifically: place the joint names .yaml file in the support package
  • use different meshes for visual and collision geometry: at the very least, subsample your current visual geometry so it gets less detailed. Collision checkers work much better with less detailed files
  • the base_link mesh has a strange origin right now (both link and joint), I'd suggest to fix that
  • I would also suggest to use better naming for your tool frames. Refer to Coordinate Frames for Serial Industrial Manipulators - Application-Specific Tool Frames for some thoughts on that
  • use standard names for everything: manipulator for the group in your .srdf, the packages and the files. It will help you significantly, both for contributing and for integrating with code and examples already 'out there'
  • use the trac_ik IK solver instead of KDL
edit flag offensive delete link more


Thank you for the fix. Unfortunately this did not fix the error, but since my goal is trajectory planning I am now working with the trajectory_execution.launch file, which works just fine.

I will also take a look at your general other comments section. I appreciate the help!

cpetersmeier gravatar image cpetersmeier  ( 2019-07-03 02:26:01 -0500 )edit

If this launch file doesn't work, I'd question the correctness of your setup.

re: trajectory_execution.launch: that is an internal MoveIt file, you cannot "work" with that directly.

gvdhoorn gravatar image gvdhoorn  ( 2019-07-03 08:19:33 -0500 )edit

Question Tools

1 follower


Asked: 2019-06-26 06:42:35 -0500

Seen: 2,522 times

Last updated: Jun 27 '19