Different branches for different features/robots is a mess

[diogoalmeida]

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]

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]

@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 MoveIt! Reaches joint limits when comanding yumi. #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]

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]

@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 MoveIt! Reaches joint limits when comanding yumi. #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]

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]

@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]

@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]

@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]

@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.