abb_robot_driver
abb_robot_driver copied to clipboard
ros-industrial
ROS2 port
It would be great to port the packages in this repository to ROS2.
The packages have been developed with this in mind, and most of them should be straightforward to adapt to the ROS2 APIs.
The most tricky parts should be the ros_control-based components, however ros2_control might be a good way to go. Although, I haven't yet had time to try it out myself, so I don't know much about its current status.
Regardless, the components not based on ros_control could be ported first, and then the remaining packages could be done at a later time.
Related: https://github.com/ros-industrial/abb_robot_driver_interfaces/issues/4
I've understood an attendee of the ros2_control WG has worked on a ROS 2 driver based on abb_libegm and abb_librws.
Perhaps @bmagyar knows more?
That would of course not be a port of the packages in this repository, but perhaps it could serve as a starting point and/or inspiration.
Here's a driver that was shown to work with ABB Studio: https://github.com/dignakov/ros2_control_demo_drivers, there's also one for KUKA in there. These are PoC implementations but should provide with a good reference for you guys.
Hello, @jontje, @gavanderhoorn is there any progress in porting this driver to ROS2?
Hello, @jontje, @gavanderhoorn is there any progress in porting this driver to ROS2?
No progress from my side, I have only recently started working more consistently with ROS2, so it will be a while yet.
Hello, @jontje, @gavanderhoorn is there any progress in porting this driver to ROS2?
No progress from my side, I have only recently started working more consistently with ROS2, so it will be a while yet.
Well, I think I might help with this in my free time.
@jontje, @gavanderhoorn I am slowly starting to port this driver to ROS2. I think that ROS2 version should be written in the way like ur_ros2_driver https://github.com/UniversalRobots/Universal_Robots_ROS2_Driver. So, I suggest to merge https://github.com/ros-industrial/abb_robot_driver and https://github.com/ros-industrial/abb_robot_driver_interfaces in to one repo abb_ros2_driver. At the moment, I am developing this in the private repo.
I think that ROS2 version should be written in the way like ur_ros2_driver https://github.com/UniversalRobots/Universal_Robots_ROS2_Driver. So, I suggest to merge https://github.com/ros-industrial/abb_robot_driver and https://github.com/ros-industrial/abb_robot_driver_interfaces in to one repo abb_ros2_driver. At the moment, I am developing this in the private repo.
Please don't unnecessarily host packages in the same repository.
What advantage do you expect by copying the structure / repository layout of Universal_Robots_ROS2_Driver?
@gavanderhoorn I thought about some kind of concept unification. However, this is just a suggestion. I have already migrated interfaces to ROS2 https://github.com/Souphis/abb_robot_driver_interfaces/tree/ros2_devel. I can stick with the current concept of abb ros driver.
PickNik Robotics has a ROS2 project that will require an ABB driver soon. I'd just like to check if the maintainers here would be open to a PR for ROS2? Or is there a better place?
Is there any current work that we could start from? (@Souphis)
(We'll try to preserve whatever the structure currently is.)
@AndyZe due to lack of time (mostly because of my PhD) currently I rewrote abb interfaces https://github.com/Souphis/abb_robot_driver_interfaces/tree/ros2_devel and started analyzing how to rewrite the hardware interface. I would love to collaborate in porting this to ROS2.
There is an old attempt available at dignakov/abb_experimental (from https://github.com/ros-industrial/abb_robot_driver/issues/6#issuecomment-753303948).
It doesn't really port abb_robot_driver though. It's more a minimal ros2_control wrapper around abb_libegm.
Hi @gavanderhoorn, I'm new to ROS2 and GitHub. Have you tested the mentioned repo?
I was trying to launch it from ROS2 Foxy, but not succeeding. In the repo they're telling that only irb120 is enabled for now, but the package "abb_irb120_gazebo" contains a "COLCON_IGNORE" file. I've tried deleting , but it seems that the launch files haven't been migrated from ROS to ROS2.
Do you know if there are advances in this topic?
If you're just starting out, I would not recommend trying 'random' Github repositories.
Especially with ros2_control and robot drivers, getting some experience with other packages in ROS 2 first would be a good idea.
In the repo they're telling that only irb120 is enabled for now, but the package "abb_irb120_gazebo" contains a "COLCON_IGNORE" file
The _gazebo package is for use with Gazebo, the physics simulator. It's not intended to be used with real hw.
Sorry, I've forgot to mention. My objective is to simulate an ABB robot with ROS2-Gazebo.
What do you recommend me to do @gavanderhoorn?
My objective is to simulate an ABB robot with ROS2-Gazebo.
you don't need the packages in this repository in that case.
Gazebo does not use any real hardware, so there is nothing for the driver to communicate with.
What do you recommend me to do
You could port one of the packages in ros-industrial/abb_experimental.
None of the packages there are ROS 2 compatible, but at least the .xacros should be reusable.
Okay, I'll try it. Thanks and sorry if it wasn't the place for my question.
Please don't unnecessarily host packages in the same repository.
What advantage do you expect by copying the structure / repository layout of
Universal_Robots_ROS2_Driver?
What I like about putting the robot description and config package in the same driver pkg is, it's very easy for first-time users. There's only one Readme to find. There's only one repo to clone.
What I like about putting the robot description and config package in the same driver pkg is, it's very easy for first-time users. There's only one Readme to find. There's only one repo to clone.
while true, developing for "first-time users" is not really something I believe should be the goal.
Over the past 10 years, such decisions have made maintenance and development in ROS 1 quite a bit more difficult than it necessarily had/has to be.
Separation of concerns is a very worthwhile principle to apply, if only, in this case, to avoid duplication of effort/files/etc.
Edit: additionally, decisions made "now" are most often permanent. With that I mean: decisions of the form "let's do this like this for now" tend to introduce patterns which tend to not go away easily.
Not sure how relevant this is, but someone seems to have a working ROS2 ABB YuMi driver. https://github.com/matiov/disambiguate-BT-execution/tree/master/world_interface/abb_robot https://github.com/matiov/disambiguate-BT-execution#disclaimer
That's not really "someone", but @matiov, who works at ABB CR. Likely a colleague of @jontje.
Edit: or an intern/phd.
No need to apologise.
I just wanted to clarify why it would 'make sense' for that someone to have worked on a ROS 2 version.