search

kth-ros-pkg / yumi

ROS packages pertaining to the ABB YuMi (IRB 14000) robot
BSD 2-Clause "Simplified" License
43 stars 37 forks source link

Different branches for different features/robots is a mess #22

Open diogoalmeida opened 6 years ago

diogoalmeida commented 6 years ago

We currently have a 'main' brainch, egm_modifications with code for our EGM-compatible yumis. Then we have branches like optodaq_sensors for the optoforce-equipped Yumi.

This does not make sense, as everytime we update egm_modifications, those changes should be made available to the optoforce Yumi. Furthermore, we might want to change other Yumis in the future. This repo should contain base code for all the Yumis, and we should have a way to keep the feature/Yumi-specific files away from this repo.

diogoalmeida commented 6 years ago

Proposed solution:

  1. This repo will provide only core yumi functionality, common to any yumi we might ever want to use with ros control
  2. For a specific yumi instance, the ideal workflow is to set up a separate package which will only contain launch files / xacro descriptions / parameters which are specific to the robot. All code that's not absolutely specific to a single yumi should be in this repo.
  3. Specific functionality that cannot be added just by modifying parameters/adding xacro files should be discussed and considered for this repo, to make it a configurable functionality in concrete implementations. Example: force-torque sensor support is currently available in optodaq_sensors through a hardware interface which can be configured by a user. I propose that the hardware interface support should be generic and on this repo, and a concrete yumi with force torque sensors would then instantiate a particular ft sensor by adding the required configuration/description files in a separate repository.
YoshuaNava commented 6 years ago

@rtkg, @diogoalmeida Thank you for your input. I think those are good directives, and we are set on the right path.

Later today I'll create the "core" branch. I propose the following order of things:

  1. Make yumi_description fully compliant with ROS industrial standards.
  2. Reduce the joint limits that we have in our URDFs, as pointed out in #10.
  3. Put most of the parametes of the launchfiles into yaml files.
  4. Add move group launch to the launchfiles that bring up JointTrajectoryController(s).
  5. Separate optoforce FT sensors branch. Put that in a separate package.
  6. Separate FACT branch. Put that in a separate package.
  7. Support the new version of libegm and librws released by ABB.
diogoalmeida commented 6 years ago

I'd name the branch "kinetic" to be coherent with the conventions used in ROS repos.

As for your points:

  1. Nice!
  2. Nice!
  3. Nice!
  4. Nice!
  5. I think that in this repo we should have support for generic FT sensors through the hardware interface, and optoforce support should be specific to a robot, in a different repo. If that's what you meant, nice!
  6. Nice!
  7. Nice!
YoshuaNava commented 6 years ago

@diogoalmeida thank you for the feedback.

Then for the new branch I'll focus on:

  1. Make yumi_description fully compliant with ROS industrial standards.
  2. Reduce the joint limits that we have in our URDFs, as pointed out in #10.
  3. Put most of the parametes of the launchfiles into yaml files.
  4. Add move group launch to the launchfiles that bring up JointTrajectoryController(s).
  5. Improve the code of yumi_cameras. (New addition)
  6. Separate yumi_optodaq branch. Put that in a separate package.
  7. Separate FACT branch. Put that in a separate package.
  8. Support the new version of libegm and librws released by ABB.
  9. Setup continuous integration. (New addition)
diogoalmeida commented 6 years ago

Sounds good! Can you make separate issues for those features and track them under the "Setup core yumi package" milestone? This will make it easier to track progress.

gavanderhoorn commented 6 years ago

@diogoalmeida @YoshuaNava: regarding point 1 it might be an idea to have a short chat / discussion? There have been some recent discussions about ros-i urdfs that might be good to take into account.

I also have some other things I'd like to discuss with you, so perhaps we could combine that with a short discussion about the robot support package.

diogoalmeida commented 6 years ago

@gavanderhoorn, that sounds great. I am out of office until Friday, and next week my availability starts on Wednesday. So, Friday at some point in time or later next week works for me!

YoshuaNava commented 6 years ago

@rtkg @diogoalmeida @gavanderhoorn: This week I'm very busy. Could it be next week after Wednesday?

On a different note, should we arrange the details of the meeting via mail?

gavanderhoorn commented 6 years ago

@YoshuaNava wrote:

should we arrange the details of the meeting via mail?

yes, let's do that.

Could you send me a message on my tu address? It's used in just about any commit on any of the repositories I've committed to.