Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Breaking changes in Melodic release #448

Closed
gavanderhoorn opened this issue Jul 13, 2019 · 15 comments
Closed

Breaking changes in Melodic release #448

gavanderhoorn opened this issue Jul 13, 2019 · 15 comments

Comments

@gavanderhoorn
Copy link
Member

gavanderhoorn commented Jul 13, 2019

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:

@gavanderhoorn
Copy link
Member Author

@ipa-nhg @ipa-led @miguelprada

gavanderhoorn added a commit to gavanderhoorn/universal_robot that referenced this issue Jun 6, 2020
It has been deprecated for years and should not be used any longer.

Replaced by:

 - ur_modern_driver (CB1, CB2)
 - ur_robot_driver (CB3 and newer)
gavanderhoorn added a commit to gavanderhoorn/universal_robot that referenced this issue Jun 6, 2020
gavanderhoorn added a commit to gavanderhoorn/universal_robot that referenced this issue Jun 8, 2020
Company is called Universal Robots (plural).
gavanderhoorn added a commit to gavanderhoorn/universal_robot that referenced this issue Jun 9, 2020
It has been deprecated for years and should not be used any longer.

Replaced by:

 - ur_modern_driver (CB1, CB2)
 - ur_robot_driver (CB3 and newer)
gavanderhoorn added a commit to gavanderhoorn/universal_robot that referenced this issue Jun 9, 2020
gavanderhoorn added a commit to gavanderhoorn/universal_robot that referenced this issue Jun 9, 2020
Company is called Universal Robots (plural).
gavanderhoorn added a commit that referenced this issue Jun 9, 2020
Company is called Universal Robots (plural).
@fmessmer
Copy link
Contributor

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 UniversalRobots/Universal_Robots_ROS_Driver#84 (comment))

@gavanderhoorn
Copy link
Member Author

@fmauch
Copy link
Contributor

fmauch commented Jun 15, 2020

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
Copy link
Member Author

gavanderhoorn commented Jun 15, 2020

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
Copy link
Contributor

fmauch commented Jun 16, 2020

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
Copy link
Member Author

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
Copy link
Contributor

fmauch commented Jun 16, 2020

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
Copy link
Contributor

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
Copy link
Member Author

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
Copy link
Contributor

fmessmer commented Nov 24, 2020

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
Copy link
Member Author

gavanderhoorn commented Nov 24, 2020

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
Copy link
Contributor

fmauch commented Nov 24, 2020

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
Copy link

v4hn commented May 4, 2021

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
Copy link
Contributor

fmauch commented Nov 10, 2022

Looks like everything here is done -> closing

@fmauch fmauch closed this as completed Nov 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants