Melodic Migration

[nilsmelchert]

Hi,
we are currently trying to migrate the staubli and the staubli_experimental package to the new ros distro melodic and would love to create a meldic-devel branch for both repositories.

While compiling the staubli package, the following error occurs:

/home/USER/catkin_ws/src/staubli/staubli_rx160_moveit_plugins/rx160_kinematics/src/staubli_rx160_manipulator_ikfast_moveit_plugin.cpp:307:50: error: conversion from ‘urdf::JointSharedPtr {aka std::shared_ptr<urdf::Joint>}’ to non-scalar type ‘boost::shared_ptr<urdf::Joint>’ requested
     boost::shared_ptr<urdf::Joint> joint = link->parent_joint;
                                            ~~~~~~^~~~~~~~~~~~
/home/USER/catkin_ws/src/staubli/staubli_rx160_moveit_plugins/rx160_kinematics/src/staubli_rx160_manipulator_ikfast_moveit_plugin.cpp:352:28: error: no match for ‘operator=’ (operand types are ‘boost::shared_ptr<urdf::Link>’ and ‘urdf::LinkSharedPtr {aka std::shared_ptr<urdf::Link>}’)
     link = link->getParent();

Seems like that the old-style moveit packages are not compatible with melodic anymore. So the first step was to delete the moveit packages. Then the compiling of both packages worked just fine.
Then we tried to launch the test.launch file from the tx90 support package. In RVIZ, the URDF was loaded just fine as you can see in the image below.

The only thing, that seemed strange, was that the links of the robot were painted red, as if they were colliding.

Then we tested the gazebo packages of the tx90 series and got the error, that there was no P gain for the joint controllers set:

[ERROR] [1540197218.918118301, 0.159000000]: No p gain specified for pid.  Namespace: /gazebo_ros_control/pid_gains/joint_1
[ERROR] [1540197218.918612518, 0.159000000]: No p gain specified for pid.  Namespace: /gazebo_ros_control/pid_gains/joint_2
[ERROR] [1540197218.918939600, 0.159000000]: No p gain specified for pid.  Namespace: /gazebo_ros_control/pid_gains/joint_3
[ERROR] [1540197218.919370730, 0.159000000]: No p gain specified for pid.  Namespace: /gazebo_ros_control/pid_gains/joint_4
[ERROR] [1540197218.919850122, 0.159000000]: No p gain specified for pid.  Namespace: /gazebo_ros_control/pid_gains/joint_5
[ERROR] [1540197218.920259249, 0.159000000]: No p gain specified for pid.  Namespace: /gazebo_ros_control/pid_gains/joint_6

Still the joint positions were published just fine. But running rqt_tf_tree showed, that the gazebo package did not publish any tf information.

Then we tried to use an old moveit package, that we created with the moveit setup assistant and which worked perfectly fine using ros kinetic. The result can be seen below:

Seems like the urdf (or xacro) files couldnt be loaded properly.
We are aware of the official migration notes. But we dont see how any change affects this repository.
We would really appreciate some hints.

Thanks a lot.

[gavanderhoorn]

Seems like that the old-style moveit packages are not compatible with melodic anymore. So the first step was to delete the moveit packages.

This just looks like the expected std::shared_ptr vs boost::shared_ptr issue. Should not be too difficult to fix, but it's just the IK plugins, so easily circumvented by using a different plugin.

The only thing, that seemed strange, was that the links of the robot were painted red, as if they were colliding.

that is strange. Seeing as this is just showing RViz it doesn't know anything about being in collision or not.

Then we tested the gazebo packages of the tx90 series and got the error, that there was no P gain for the joint controllers set

Gazebo 9 changed some things around, especially with gazebo_ros_control. That is most likely the cause of this particular error message.

Seems like the urdf (or xacro) files couldnt be loaded properly.

If that was the case you wouldn't even see a robot in RViz, so I expect this to be an issue with TF.

[gavanderhoorn]

Everything being red could be related to ros-visualization/rviz#1298.

[VictorLamoine]

I confirm the bug @gavanderhoorn points out is the source of the robot being red.

[nilsmelchert]

Gazebo 9 changed some things around, especially with gazebo_ros_control. That is most likely the cause of this particular error message.

The gazebo package works fine with melodic now for the tx90 and tx60 series.

When I was trying to migrate the support packages of the robots for melodic, I had some Issues with RVIZ and the industrial_core package. Seems like they have now fully been migrated to ros medloic yet? Should I just wait a few more month and then start the melodic migration of this repository?

[nilsmelchert]

I am still having the same problem: The robot is still colored in red.

The Issue @gavanderhoorn and @VictorLamoine pointed out did apparently did not solve that problem.

[gavanderhoorn]

Afaik the fix that has gone into urdfdom_headers has still not been released as a Debian/Ubuntu package update, so unless you are building that from source or are using the work-around (LC_NUMERIC), nothing has changed.

[simonschmeisser]

Those packages are unfortunately not hosted by OSRF but are part of debian/ubuntu. If have filed a bug report asking for an update in Ubuntu Bionic but so far no reaction: https://bugs.launchpad.net/ubuntu/+source/urdfdom-headers/+bug/1817595

Please click: This bug affects me

Updated packages have been imported in Debian testing and made it into Ubuntu 19.04/Disco Dingo which is however not an LTS release!

[nilsmelchert]

Please click: This bug affects me

Done.

Thanks for the feed back.

[nilsmelchert]

Is there a way how to speed up the release?

[nilsmelchert]

The problem still exists. Am I the only one who is bothered by this?

It is really the biggest reason, why I haven't migrated my whole system to melodic yet.

[simonschmeisser]

ros/urdfdom#119 asks for a Dockerfile that proves the bug and the fix as the next step. You are very welcome to put that together.

[nilsmelchert]

Well I have never used Docker in combination with a graphical interface. Besides that, I don't see how a single Dockerfile is supposed to point out the bug and the fix.

If you could point out, what exactly the behaviour of the Dockerfile should be and what kind of base image I should use, I would try to put that together.

[simonschmeisser]

This should be fixed by now, can you confirm @nilsmelchert ?

[nilsmelchert]

@simonschmeisser Yes, the coloring looks good!
Thanks for your effort!

The only thing that remains with this issue is the error message regarding missing PID parameters in gazebo. But that is a whole different topic.

[gavanderhoorn]

Closing this then.