Split repository

[ugocupcic]

Keeping only the core stacks in that one as discussed multiple times internally and with @guihomework

[guihomework]

I will closely follow that topic (see email)

[ugocupcic]

Here's what I could think of - based on @guihomework suggestions:

• sr_common
  • sr_description
  • sr_robot_msgs
  • sr_common (meta package for all those packages)
• sr_core
  • sr_hand
  • sr_gazebo_sim
  • sr_tactile_sensors
  • sr_mechanism_controllers
  • sr_hardware_interface
  • sr_mechanism_model
  • sr_utilities
  • sr_core (meta package for all those packages)
• sr_high_level_interface (find a better name?)
  • sr_robot_commander
  • sr_example
  • sr_multi_moveit
  • sr_multi_description
  • sr_robot_launch
  • sr_grasp
  • sr_high_level_interface (meta package for all those packages)
• sr-ros-interface keeping it for historical reasons - same point of entrance as always Contains meta packages for installing shadow-robot (basically the 3 meta packages above). Edit README to point to the new repositories.
• sr_tools (find a better name? or should we simply move this to sr-contrib?)
  • sr_movements
  • sr_self_test
• sr_standalone (kind of a side project)
  • sr_standalone
  • sr_standalone_example

[ugocupcic]

@guihomework I addressed @toliver comment (directly edited my comment with the list above). We discussed it internally and the proposal above makes sense to us. I'll probably start on this in the next few days, once you tell me your feeling about this.

Cheers

[guihomework]

This split suggestion looks quite nice to me but could have small adjustments :

• The robot_commander is a tool to better access the hand isn't it ? it could fit in sr_tools. I must say I did not use this interface yet so might be off topic.
• I already told you my concern of having some moveit dependencies in sr_robot_msgs. Would be nice if in the future, those specific messages belong to a higher level repository in a new package.
• Regarding renaming sr_high_level_interface, at some point, shadow had sr_manipulation for all the arm_navigation stuff. I think most of the high level stuff will be manipulation (arm+hand manip or in-hand manip like sr_grasp). Would it make sense to rename sr_manipulation ( to keep if for history) to sr_manipulation_legacy and reuse sr_manipulation ? Otherwise, why not call directly sr_high_level_interface sr_interface ? Because it is too close to sr-ros-interace ? sr-ros-interface was always the package repository, never the metapackage installation name called shadow_robot. So sr_interface sounds a good candidate to me and is shorter, Then maybe the robot_commander is an interface and should stay there. You know better.
• Remember sr_self_tests is needed for the real hand driver, the simulation and the GUI. And sr_movements is needed for the GUI only. sr_self_tests is a candidate to move to the core then isn't it ?
• I like sr_tools that could contain some tools that are not necessarily needed (if you don't tune the hand you don't need sr_movements). We could put there some stuff like the "protection" algorithm that we run "above" the sr_mechanism_controllers that monitor the hand for long pulling on the tendon and so on. Not needed but interesting to have in some situations. To me they are at the same level as sr_high_level_interface, and hence should not be a dependency of sr_high_level_interface. But the limit is rather small between same level or just below sr_high_level_interface. In fact hand_kinematics are needed for moveit hand planning, and they live in sr_contrib right now. So maybe tools is sr_contrib. sr_contrib always looked as an outsider, or a sand_box. I am not even sure it compiles nicely right now (some package did not migrate to catkin and are just ignored), some have been updated (hand_kinematics definitely). One could go for sr_tools as the repository for "accepted" packages tested first in sr_contrib ? Then sr_movements has its place in sr_tools as well as hand_kinematics, and maybe the future sr_moveit_hand_kinematics to build full srdf for any hand ?

cheers

[ugocupcic]

Hi @guihomework,

Thanks for the great input. I just wanted to clarify something regarding sr_high_level_interface (I rather like sr_interface, will probably update the name). We are aiming for this to be the new recommended way of interacting with the hand (for those who aren't power users). That's why the commander is in there. sr_interface is basically the minimum amount of stuff you need to get the commander (+ examples etc...).

The scenario we want is for "normal" users to install everything up to sr_interface. They could also look into sr_tools if needed (as you said sr-contrib is there for legacy reasons, the good stuff from contrib will be migrated to sr_tools). Then power users could get away with installing common and core - if they don't care about moveit / easier to use interface. Finally someone that just wants to interact with a hand from another computer simply needs to install common.

Good point for sr_self_test (it's not needed for gazebo anymore since we got rid of the gazebo plugin, did you see @AndriyPt's pull request?). I'll migrate it to sr_core.

Regarding your generic hand moveit config, the goal is to get it into sr_core once we have a proper way of merging the configs. I might put it in sr_tools for now. Hand_kinematics needs to go in sr_interface since it's needed for moveit / commander.

Regarding sr_robot_msgs, I'm not convinced that having a dependency on moveit_msgs (you don't need the whole of moveit for that, but you do need a bunch of msg packages which are quite small) is more problematic than creating another package somewhere else. In the scenarios I listed above, if you want to install with our hand from a remote computer, the only thing you need to install is the common meta package. That wouldn't be true anymore if we moved those out.

I'll add the updated list in a separate comment right after this.

Cheers,

[ugocupcic]

Updating the splitted packages based on the discussion:

• sr_common
  • sr_description
  • sr_robot_msgs
  • sr_common (meta package for all those packages)
• sr_core
  • sr_hand
  • sr_gazebo_sim
  • sr_tactile_sensors
  • sr_mechanism_controllers
  • sr_hardware_interface
  • sr_mechanism_model
  • sr_self_test
  • sr_utilities
  • sr_core (meta package for all those packages)
• sr_interface
  • hand_kinematics
  • sr_robot_commander
  • sr_example
  • sr_multi_moveit
  • sr_multi_description
  • sr_robot_launch
  • sr_grasp
  • sr_high_level_interface (meta package for all those packages)
• sr-ros-interface keeping it for historical reasons - same point of entrance as always Contains meta packages for installing shadow-robot (basically the 3 meta packages above). Edit README to point to the new repositories.
• sr_tools
  • sr_movements
• sr_standalone (kind of a side project)
  • sr_standalone
  • sr_standalone_example

[guihomework]

Hi, This restructuring + explanation are fine.

Regarding sr_gazebo, I had seen that, but no change to test it yet. We diverged from sr-ros-interface. I wanted to merge all your changes back and I hoped the UR dependencies would go away to not need that.

With this split this goes in the direction we need since only sr_common and sr_core will be required.

The question, is : Should I merge sr-ros-interface with our ubi-agni repository first and then merge the split, or try to cherry pick our changes to put them separately on the new repositories (our changes are mainly on the sr_core in sr_description) ? I feel both will be complex anyway. Any suggestion ?

[ugocupcic]

As you said both will be complex. What seems like the easiest solution would be (if you don't mind loosing the history) to do it package per package once the split has been done? (a brutal diff on the folders if you see what I mean)

[guihomework]

Oh, you mean you are not splitting your repositories, just creating new ones with an initial commit at the time of the split ?

[ugocupcic]

No no we are splitting the repositories etc... I meant that it might be easier for you to do it that way?

[guihomework]

Ok, then I think I will rebase my changes on the few packages after the split, helping the rebase by pointing the correct commit (in case the history is kept but history is rewritten).

[ugocupcic]

Started to work on this in this branch