search

start-jsk / rtmros_common

OpenRTM - ROS interoperability packages
http://wiki.ros.org/rtmros_common
12 stars 52 forks source link

Remove dependency on pr2 related packages #412

Closed 130s closed 10 years ago

130s commented 10 years ago

Dependency onto pr2 related package in rtmros_common has been a pain in the neck for builders and releasers. Currently following classes hit in rtmros_common (see grep log[1]).

Here are a few reasons why I propose the change:

For these reasons I suggest we start a permanent solution for this soon, or even now.

I guess this could be worked around by keeping our own catkinized version of the classes. Something like http://wiki.ros.org/pr2_groovy_patches. Assuming all of the referenced classes are stably maintained without upcoming changes, it's good for our own purpose.

[1] Using 70973c6a21afe66a75c6af378a71743409ebdfae

$ grep -r pr2 rtmros_common
./hrpsys_ros_bridge/test/test-pa10.py:from pr2_controllers_msgs.msg import JointTrajectoryAction, JointTrajectoryGoal
./hrpsys_ros_bridge/test/test-samplerobot.py:from pr2_controllers_msgs.msg import JointTrajectoryAction, JointTrajectoryGoal
./hrpsys_ros_bridge/src/HrpsysJointTrajectoryBridge.cpp:    (new actionlib::SimpleActionServer<pr2_controllers_msgs::JointTrajectoryAction>
./hrpsys_ros_bridge/src/HrpsysJointTrajectoryBridge.cpp:    advertise<pr2_controllers_msgs::JointTrajectoryControllerState>(controller_name + "/state", 1);
./hrpsys_ros_bridge/src/HrpsysJointTrajectoryBridge.cpp:    pr2_controllers_msgs::JointTrajectoryResult result;
./hrpsys_ros_bridge/src/HrpsysJointTrajectoryBridge.cpp:  pr2_controllers_msgs::JointTrajectoryGoalConstPtr
./hrpsys_ros_bridge/src/HrpsysSeqStateROSBridge.h:#include "pr2_controllers_msgs/JointTrajectoryControllerState.h"
./hrpsys_ros_bridge/src/HrpsysSeqStateROSBridge.h:  actionlib::SimpleActionServer<pr2_controllers_msgs::JointTrajectoryAction> joint_trajectory_server;
k-okada commented 10 years ago

rtmros_common is designed to be compatible with pr2 robot controllers, so the point is to count up the number of packages that depends on pr2_controllers_msgs. From [1] , there are 64 packages that depends on pr2_controllers_msgs.

So possible solutions is 1) count up how many applications uses pr2_controllers_msgs 2-a) send pull request to switch from pr2_controllers_msgs to control_msgs, 2-b) if 2-a will not work, we have to fork and maintain the package.

If we can wait until groovy's end-of-life, most of apps depends on controllrs_msgs so it may much easyer , but most of pr2 is still running on groovy [2], thus in order to push pr2-hydro we may have to help catkinize pr2 related packages.

My decision at this moment is it is less painful to keep current setting (depends in pr2-related package) than take care of rtmros_common users or work on catkinizing pr2-apps. And wait for groovy's end-of-life.

[1] http://wiki.ros.org/pr2_controllers_msgs [2] http://lists.willowgarage.com/pipermail/pr2-users/2014-April/001865.html

On Sun, Apr 13, 2014 at 10:30 AM, Isaac Isao Saito <notifications@github.com

wrote:

Dependency onto pr2 related package in rtmros_common has been a pain in the neck for builders and releasers. Currently following classes hit in rtmros_common (see grep log[1]).

  • JointTrajectoryAction
  • JointTrajectoryGoal
  • JointTrajectoryAction
  • JointTrajectoryControllerState
  • JointTrajectoryResult
  • JointTrajectoryGoalConstPtr
  • JointTrajectoryControllerState

Here are a few reasons why I propose the change:

  • Currently on Groovy where pr2_controllers_msgs package is still dry, they are obtained by downloading source during build time.

    • Apparently the ROS core team discourages downloading in CMakeLists.txthttp://lists.ros.org/pipermail/ros-release/2014-April/004393.html(though I do not know why it's bad, if that's their rule we have to consider) and thus we only get limited assistance for the issues that arise from this setting. And we've spent non-trivial amount of time trying to work this around, and we would in the future too.

    While ROS hydro is fine since pr2_controllers_msgs is catkinized, for the future ROS distros I'm afraid we might keep facing same/similar problems; the support for PR2 packages have already been decently slower (for many reasons).

    • For example no one knows when PR2 packages will be released into Indigo. And one day its release might just stop, considering the lifespan of PR2.

For these reasons I suggest we start a permanent solution for this soon, or even now.

I guess this could be worked around by keeping our own catkinized version of the classes. Something like http://wiki.ros.org/pr2_groovy_patcheshttp://pr2_groovy_patches. Assuming all of the referenced classes are stably maintained without

upcoming changes, it's good for our own purpose.

[1] Using 70973c6https://github.com/start-jsk/rtmros_common/commit/70973c6a21afe66a75c6af378a71743409ebdfae

$ grep -r pr2 rtmros_common ./hrpsys_ros_bridge/test/test-pa10.py:from pr2_controllers_msgs.msg import JointTrajectoryAction, JointTrajectoryGoal ./hrpsys_ros_bridge/test/test-samplerobot.py:from pr2_controllers_msgs.msg import JointTrajectoryAction, JointTrajectoryGoal ./hrpsys_ros_bridge/src/HrpsysJointTrajectoryBridge.cpp: (new actionlib::SimpleActionServer ./hrpsys_ros_bridge/src/HrpsysJointTrajectoryBridge.cpp: advertise(controller_name + "/state", 1); ./hrpsys_ros_bridge/src/HrpsysJointTrajectoryBridge.cpp: pr2_controllers_msgs::JointTrajectoryResult result; ./hrpsys_ros_bridge/src/HrpsysJointTrajectoryBridge.cpp: pr2_controllers_msgs::JointTrajectoryGoalConstPtr ./hrpsys_ros_bridge/src/HrpsysSeqStateROSBridge.h:#include "pr2_controllers_msgs/JointTrajectoryControllerState.h" ./hrpsys_ros_bridge/src/HrpsysSeqStateROSBridge.h: actionlib::SimpleActionServer joint_trajectory_server;

— Reply to this email directly or view it on GitHubhttps://github.com/start-jsk/rtmros_common/issues/412 .

130s commented 10 years ago

I think I understand the situation (I wasn't aware that depending on pr2_controllers_msgs is common in Groovy, among dry packages though), and keeping the current design (continuing to depend on pr2_controllers_msgs in all distros) might be the best we could do for awhile. So closing this.

On related note regarding EOL of Groovy, I posted a question since it looks to me will live until 2017.

But even if my guess above was right, for the packages that we maintain we can deliberately set EOL or announce limited support for particular distros, or else.

Lastly regarding one of my points:

Apparently the ROS core team discourages downloading in CMakeLists.txt (though I do not know why it's bad, if that's their rule we have to consider) and thus we only get limited assistance for the issues that arise from this setting.

This needs serious consideration, although I just hope for this particular package that we might be able to keep the current setting without being pointed, assuming our Groovy support will be dropped someday soon.

k-okada commented 10 years ago

Apparently the ROS core team discourages downloading in CMakeLists.txt

yes, that's might be problem, but I think Groovy will end of its life during 2015. (Just a guess)

130s commented 10 years ago

Turned out Groovy will retire within 1 or 2 months in 2014.