-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
define initial ROS 2 variants #1
Conversation
If there is no strong reason to do so I would lean to keep the names the same as in ROS 1.
I would lean to |
LGTM - I haven't checked the exact lists of dependencies though. the highlevel grouping should be documented somewhere (if not in an REP as in ROS 1 then somewhere else). |
+1 to documenting it somewhere, but I'm not sure where. I suppose a new REP in the 2xxx range is the most proper, but I'd also be ok with somewhere else that's less tedious for now. |
Yeah I was about to provide the breakdown ros_core packages:
diff ros_core ros_base:
```
$ diff ros_core.packages ros_base.packages
0a1
> actionlib_msgs
1a3
> ament_cmake_auto
28a31
> ament_index_cpp
36a40,42
> class_loader
> common_interfaces
> composition
37a44,60
> console_bridge_vendor
> demo_nodes_cpp
> demo_nodes_cpp_native
> demo_nodes_py
> diagnostic_msgs
> example_interfaces
> examples_rclcpp_minimal_client
> examples_rclcpp_minimal_composition
> examples_rclcpp_minimal_publisher
> examples_rclcpp_minimal_service
> examples_rclcpp_minimal_subscriber
> examples_rclcpp_minimal_timer
> examples_rclpy_executors
> examples_rclpy_minimal_client
> examples_rclpy_minimal_publisher
> examples_rclpy_minimal_service
> examples_rclpy_minimal_subscriber
40a64
> geometry_msgs
46a71
> lifecycle
47a73,74
> logging_demo
> nav_msgs
48a76
> orocos_kdl
50a79
> pluginlib
54a84
> rcl_lifecycle
56a87
> rclcpp_lifecycle
65a97,108
> ros2cli
> ros2launch
> ros2lifecycle
> ros2msg
> ros2node
> ros2param
> ros2pkg
> ros2run
> ros2service
> ros2srv
> ros2topic
> ros_base
85a129,131
> sensor_msgs
> shape_msgs
> sros2
86a133,134
> std_srvs
> stereo_msgs
87a136,145
> tf2
> tf2_eigen
> tf2_geometry_msgs
> tf2_msgs
> tf2_ros
> tinyxml2_vendor
> tlsf
> tlsf_cpp
> topic_monitor
> trajectory_msgs
88a147
> visualization_msgs
```
diff ros_base desktop
diff ALL desktop:
I'll open a draft REP later today. |
Please break down the list by repositories rather than by packages. |
Is the goal to not have packages from the same repository in different variants ? |
Both, and this is how it is in the ROS 1 REP. |
The list needs to be changes then. |
Looking more into this. The requirement of not having any overlap on the repos seems unfeasible for the Bouncy patch release (as it will require splitting multiple repositories or a very big set of packages in ros_core).
As all bouncy packages have been released already, (and that I don't see why we would release the variants one by one anyway) I'm going to update this to reduce the amount of overlap when trivial but not push much more things in the core and not split repositories for the patch release. If we want to respect that requirement for Crystal, we will need to audit all repository dependencies and split them as needed. Then refedine the variants accordingly |
The
In ROS 1 the goal of core and base is to be commonly installed on a robot where as desktop is meant to be for the developer machine. Having the demos in desktop doesn't seem like a bad choice? |
Pushed a new version with a split closer to ROS 1. I am not planning on iterating more on it: ros_core:
ros_base
ros_desktop
none of the variants:
|
planning on merging this shortly and to make a bouncy branch right away as this set of variants is specific to bouncy. The variants will need to me modified as master moves forward. Last commits remove cartographer, astra driver and navigation packages from desktop as they're not in desktop in ROS 1. Feel free to comment post-merge / open follow-up PRs |
2 outstanding questions still:
ros_
prefix for the variants?rcl(cpp)_lifecycle
live incore
orbase
? (currently inbase
vialifecycle
demo but I;d like them to be explicitly listed in a package.xml)