Reorganize & update

[resizoltan]

All ROS2 packages and other code (e.g. Sunrise Project) should be located in the same repository. For a reference, see the motoman driver. Inside the repository, the ros2_ prefixes could be then also removed.

Proposed structure:

• kroshu/ros2_kuka_sunrise (repo)
  • kuka_sunrise (ROS2 metapackage)
  • kuka_sunrise_driver (ROS2 package)
  • kuka_sunrise_interfaces (ROS2 interface package)
  • kuka_sunrise_ros2_robot_application (Sunrise Project)
  • This could actually be 'shipped' independently from ROS2 and be a generic state-machine based Robot Application for external control through FRI, like the abb driver, but since this is not really required, imo we should just keep specific to ROS2 and deploy alongside the ROS2 driver
    • abb_robot_driver ROS1 driver, which connects to:
    • abb_libegm generic external control lib for abb robots
  • kuka_sunrise_hardware_interface (for ros2_control support in the future)

[resizoltan]

I believe we should first update the code to the most recent version if it is still missing from GitHub. @kovacsge11, @Svastits can you take care of this? I am not sure whether anything has changed on the ROS2 side recently, but the Sunrise Project is missing altogether.

After you uploaded the directories kuka_sunrise_driver, kuka_sunrise_interfaces and kuka_sunrise_ros2_robot_application (what should we call it? this is not very compact) I can create the kuka_sunrise metapackage or you can also go ahead with that. As for the kuka_sunrise_hardware_interface, we can skip it for now.

[kovacsge11]

@resizoltan, as @Svastits suggested, I'll include the robot_control package in the repo, too. I'll place it in the hardware interface folder.

[resizoltan]

Sure, for now it is certainly a good idea. However, I think we will need to talk about the scope of the driver sometime in the future. I hope that we can decouple the hardware interface (the driver as it is now) from the controllers, like ros_control does. In this case the controllers would belong to the control stack, and not our specific robot driver. But this is quite a stretch for now, so including it in the driver's repo should mean easier maintenance. As for the name of the folder: I suggest we reserve the hardware_interface name for code related to ros2_control, because that is the context it is usually associated with in the ecosystem of ROS, and having other stuff in there would be potentially misleading to users.

[kovacsge11]

I've done an initial restructuring on the prepare-for-open-collab branch.

[Groebehavn]

Shall we create a new issue for the cut-out of the controllers? We could still do a partial reorganization, aside of the controller-cut-out, and assign the stretch work for a new colleague... :)

[resizoltan]

Well, if there is a chance that someone will work on this in the next months then we could make an issue for it to describe what is to be done next in this regard. For now I would focus on creating experimental controllers that work with our driver safely and reliably, but wouldn't go into much detail on a comprehensive control stack

[kovacsge11]

I agree, after finishing the restructure and all other issues with the current setup of controllers, we can go on and further discuss this topic.