Breaking changes in Melodic release

[gavanderhoorn]

This is a meta-issue / discussion issue for the first Melodic release, which is planned to include a number of breaking changes.

Summarising for now:

• universal_robot (metapackage) (removed in #499):
  • will be removed (universal_robots replaces it, universal_robot depends on universal_robots right now)
• ur_driver (#440, removed in #498)
  • will be removed: ur_modern_driver will become the standard driver for CB1 and CB2 controllers, ur_robot_driver will be the driver for CB3 and e-series controllers
• ur_bringup (#429, #440, removed in #498)
  • will be removed (instead: drivers should provide the necessary .launch files)
• MoveIt configuration packages:
  • updated to include latest MoveIt functionality (#430)
  • files and layout will follow ROS-I standards (moveit_planning_execution.launch, etc) (#431)
• ur_description:
  • support for calibration data imported from robot controller (#414, #357)
  • "joint limited" variants will be removed
  • migration to ROS-I standard structure with top-level and _macro.xacro and standard .launch files (started with #435, completed in #497)
  • heavy use of xacro yaml support (#371)
  • single pair of top-level and _macro.xacro which will be parameterised with .yaml settings files: one for each UR model (both e-series and regular robots) (#371 and #497)
  • removal of the world link (#284 and https://github.com/ros-industrial/universal_robot/pull/371#issuecomment-510568694)
  • removal of all Gazebo-specific infrastructure and settings (will be migrated to ur_gazebo)
• ur_e_description:
  • merged with ur_description
• ur_gazebo (mostly done in #518):
  • will use similar .yaml based approach as ur_description
  • will provide a _macro.xacro that adds Gazebo-specific elements and plugins (similar to (but not necessarily identical to) ros-industrial/abb_experimental/abb_irb120_gazebo)
  • will provide .launch files to load robot_description and other parameters (gazebo_ros_control configuration fi)
  • migration to ros_control effort controllers for all simulated robots (#521)
• ur_e_gazebo:
  • will be merged with ur_gazebo
• ur_msgs:
  • will be moved to a separate repository (#440, released into Melodic in: ros/rosdistro#25555)

[gavanderhoorn]

@ipa-nhg @ipa-led @miguelprada

[fmessmer]

If I understand this correctly, the plan is to collect all relevant changes in melodic-devel-staging branch and then - once everything is there - sync melodic-devel-staging into melodic-devel and release that version, correct?

(see also my https://github.com/UniversalRobots/Universal_Robots_ROS_Driver/issues/84#issuecomment-642193920)

[gavanderhoorn]

See my https://github.com/UniversalRobots/Universal_Robots_ROS_Driver/issues/84#issuecomment-642202800.

[fmauch]

As I couldn't find it anywhere: It might be worthwhile mentioning explicitly that with #371 the urX_e_moveit_config packages are broken, as they refer to ur_e_description and urdf/urX_e_robot.urdf.xacro.

I assume that this in scope of #431?

[gavanderhoorn]

They're broken in melodic-devel-staging, yes.

That is known and will be fixed.

I decided not to fix them by not including #467 in #501.

[fmauch]

I could maybe start hacking on this moveit stuff. I'm not very familiar with moveit, so it's probably going to take me a while... But I'd like pushing this forward :-)

[gavanderhoorn]

That would be appreciated.

I have some pretty specific ideas about those configuration pkgs though, so it may take a bit of back-and-forth.

The MSA v2 does some strange things I don't want to expose new users to, and we abstract away the differences between using MoveIt with a real controller and a Gazebo robot (the required remap fi will go away), so I don't like any mention of Gazebo in the packages. The new MSA adds some files for Gazebo support, so those would need to be removed.

[fmauch]

I'll try to get familiar with moveit first and then create a Draft-PR outlining the changes I would do. Then we can discuss that there before I dig down implementing too deep.

[fmessmer]

I guess this is still the best issue to ask for the progress of melodic-devel-staging I'm having a hard time to puzzle together compatible set of universal_robot, Universal_Robots_ROS_Driver and ur_msgs branches providing all the latest features - including support for the e-series

Any suggestions what the best combo should be? Any plans on finally getting things streamlined into each repositories' default branches again?

[gavanderhoorn]

I just followed the instructions in the readme of Universal_Robots_ROS_Driver in a clean Docker container (copy-pasting every line) which resulted in a successful build.

Does that not work for you?

[fmessmer]

well, the readme still revers to using fmach/universal_robot@calibration-devel which is not really up to date with ros-industrial/universal_robot@melodic-devel-staging I thought those two repos (universal_robot, Universal_Robots_ROS_Driver) go in sync...

[gavanderhoorn]

No, not necessarily.

@fmauch syncs them every now and then when it is necessary or makes sense to him, but there is no direct link.

[fmauch]

As long as the README of Universal_Robots_ROS_Driver suggests to use my fork, that's still the suggested way to go. The two do not get synced regularly, as the approaches for doing the calibration correction are a bit different. Due to that, the version on my fork isn't as "breaking" as this melodic-devel-staging and e.g. the existing moveit integrations can be used. From my point of view I would switch the suggestion once #538 is resolved.

[v4hn]

Ping. (@gavanderhoorn ?)

The discussion on breaking changes in the melodic release has been going on for almost two years, bigger groups migrate to noetic by now and this is still an issue:

❯ rosinstall_generator --rosdistro melodic ur_description
The following unreleased packages/stacks will be ignored: ur_description
No packages/stacks left after ignoring unreleased

We noticed in the moveit_tutorials because rosdep can't find the packages when they're not compiled in the same workspace. However, they are not actually build_depends, so it's not really justified to build them in CI unless a test would rely on them...

[fmauch]

Looks like everything here is done -> closing