The site is read-only. Please transition to use Robotics Stack Exchange
| ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
 | 1 | initial version |
No, I would not layout things as you have. Particularly src should be reserved for source code only (ie: Python, C++, etc).
No configuration files, no URDF nor Xacro, etc.
There are various Q&As on ROS Answers about recommended package layout.
The ROS wiki also has a few pages which go into this, most notable wiki/Packages. It doesn't prescribe a particular layout, but does give some examples of common folders and where they are expected to be relative to a package's root.
An often referenced 3rd party resource on the topic of best practices is leggedrobotics/ros_best_practices. The section File/Folder Structure for Packages shows an often used example.
One thing to keep in mind: this structure is mostly for humans, as roslaunch and rosrun fi don't care where you've placed your binaries / executable scripts. They'll crawl the complete package and its sub directories. There are certainly things which must be in a certain location (such as the manifest and build script), but the rest is not important.
And an observation:
catkin_ws/src/my_package
│
...
├── venv
...
Personally I would not place a Python venv inside the src space of a Catkin workspace, but you may have good reason to do so. You may want to look at tools such as catkin_virtualenv to manage this instead.
| | 2 | No.2 Revision |
No, I would not layout things as you have. Particularly src should be reserved for source code only (ie: Python, C++, etc).
No configuration files, no URDF nor Xacro, no Gazebo worlds, etc.
As a high-level comment: try to separate things a bit. You seem to treat my_package as a mini workspace almost. Why not create a my_package_gui, my_package_gazebo and my_package_description package? That would be following best-practices.
There are various Q&As on ROS Answers about recommended package layout.
The ROS wiki also has a few pages which go into this, most notable wiki/Packages. It doesn't prescribe a particular layout, but does give some examples of common folders and where they are expected to be relative to a package's root.
An often referenced 3rd party resource on the topic of best practices is leggedrobotics/ros_best_practices. The section File/Folder Structure for Packages shows an often used example.
One thing to keep in mind: this structure is mostly for humans, as roslaunch and rosrun fi don't care where you've placed your binaries / executable scripts. They'll crawl the complete package and its sub directories. There are certainly things which must be in a certain location (such as the manifest and build script), but the rest is not important.
And an observation:
catkin_ws/src/my_package
│
...
├── venv
...
Personally I would not place a Python venv inside the src space of a Catkin workspace, but you may have good reason to do so. You may want to look at tools such as catkin_virtualenv to manage this instead.
Edit: and I just noticed this:
catkin_ws/src/my_package │ ├── cmake-build-debug ..
What is cmake-build-debug? Are you doing in-source builds with cmake directly?
I would expect build artefacts to only exist in the build space of your Catkin workspace.
| | 3 | No.3 Revision |
No, I would not layout things as you have. Particularly src should be reserved for source code only (ie: Python, C++, etc).
No configuration files, no URDF nor Xacro, no Gazebo worlds, etc.
As a high-level comment: try to separate things a bit. You seem to treat my_package as a mini workspace almost. Why not create a my_package_gui, my_package_gazebo and my_package_description package? That would be following best-practices.Packages are almost free, so separate things as much as possible.
There are various Q&As on ROS Answers about recommended package layout.
The ROS wiki also has a few pages which go into this, most notable wiki/Packages. It doesn't prescribe a particular layout, but does give some examples of common folders and where they are expected to be relative to a package's root.
An often referenced 3rd party resource on the topic of best practices is leggedrobotics/ros_best_practices. The section File/Folder Structure for Packages shows an often used example.
One thing to keep in mind: this structure is mostly for humans, as roslaunch and rosrun fi don't care where you've placed your binaries / executable scripts. They'll crawl the complete package and its sub directories. There are certainly things which must be in a certain location (such as the manifest and build script), but the rest is not important.
And an observation:
catkin_ws/src/my_package │ ... ├── venv ...
Personally I would not place a Python venv inside the src space of a Catkin workspace, but you may have good reason to do so. You may want to look at tools such as catkin_virtualenv to manage this instead.
Edit: and I just noticed this:
catkin_ws/src/my_package │ ├── cmake-build-debug ..
What is cmake-build-debug? Are you doing in-source builds with cmake directly?
I would expect build artefacts to only exist in the build space of your Catkin workspace.
| | 4 | No.4 Revision |
No, I would not layout things as you have. Particularly src should be reserved for source code only (ie: Python, C++, etc).
No configuration files, no URDF nor Xacro, no Gazebo worlds, etc.
My ROS package is beginning to get complicated with multiple folders for various aspects of functionality.
As a high-level comment: try to separate things a bit. You seem to treat my_package as a mini workspace almost. They're not.
Why not create a my_package_gui, my_package_gazebo and my_package_description package? Packages are almost free, so separate things as much as possible.
There are various Q&As on ROS Answers about recommended package layout.
The ROS wiki also has a few pages which go into this, most notable wiki/Packages. It doesn't prescribe a particular layout, but does give some examples of common folders and where they are expected to be relative to a package's root.
An often referenced 3rd party resource on the topic of best practices is leggedrobotics/ros_best_practices. The section File/Folder Structure for Packages shows an often used example.
One thing to keep in mind: this structure is mostly for humans, as roslaunch and rosrun fi don't care where you've placed your binaries / executable scripts. They'll crawl the complete package and its sub directories. There are certainly things which must be in a certain location (such as the manifest and build script), but the rest is not important.
And an observation:
catkin_ws/src/my_package │ ... ├── venv ...
Personally I would not place a Python venv inside the src space of a Catkin workspace, but you may have good reason to do so. You may want to look at tools such as catkin_virtualenv to manage this instead.
Edit: and I just noticed this:
catkin_ws/src/my_package │ ├── cmake-build-debug ..
What is cmake-build-debug? Are you doing in-source builds with cmake directly?
I would expect build artefacts to only exist in the build space of your Catkin workspace.
| | 5 | No.5 Revision |
No, I would not layout things as you have. Particularly src should be reserved for source code only (ie: Python, C++, etc).
No configuration files, no URDF nor Xacro, no Gazebo worlds, etc.
My ROS package is beginning to get complicated with multiple folders for various aspects of functionality.
As a high-level comment: try to separate things a bit. You seem to treat my_package as a mini workspace almost. They're not.
Why not create a my_package_gui, my_package_gazebo and my_package_description package? Packages are almost free, so separate things as much as possible.possible. Decrease coupling, separate concerns and delegate responsibilities.
There are various Q&As on ROS Answers about recommended package layout.
The ROS wiki also has a few pages which go into this, most notable wiki/Packages. It doesn't prescribe a particular layout, but does give some examples of common folders and where they are expected to be relative to a package's root.
An often referenced 3rd party resource on the topic of best practices is leggedrobotics/ros_best_practices. The section File/Folder Structure for Packages shows an often used example.
One thing to keep in mind: this structure is mostly for humans, as roslaunch and rosrun fi don't care where you've placed your binaries / executable scripts. They'll crawl the complete package and its sub directories. There are certainly things which must be in a certain location (such as the manifest and build script), but the rest is not important.
And an observation:
catkin_ws/src/my_package │ ... ├── venv ...
Personally I would not place a Python venv inside the src space of a Catkin workspace, but you may have good reason to do so. You may want to look at tools such as catkin_virtualenv to manage this instead.
Edit: and I just noticed this:
catkin_ws/src/my_package │ ├── cmake-build-debug ..
What is cmake-build-debug? Are you doing in-source builds with cmake directly?
I would expect build artefacts to only exist in the build space of your Catkin workspace.
| | 6 | No.6 Revision |
No, I would not layout things as you have. Particularly src should be reserved for source code only (ie: Python, C++, etc).
No configuration files, no URDF nor Xacro, no Gazebo worlds, etc.
My ROS package is beginning to get complicated with multiple folders for various aspects of functionality.
As a high-level comment: try to separate things a bit. You seem to treat my_package as a mini workspace almost. They're It's not.
Why not create a my_package_gui, my_package_gazebo and my_package_description package? Packages are almost free, so separate things as much as possible. Decrease coupling, separate concerns and delegate responsibilities.
There are various Q&As on ROS Answers about recommended package layout.
The ROS wiki also has a few pages which go into this, most notable wiki/Packages. It doesn't prescribe a particular layout, but does give some examples of common folders and where they are expected to be relative to a package's root.
An often referenced 3rd party resource on the topic of best practices is leggedrobotics/ros_best_practices. The section File/Folder Structure for Packages shows an often used example.
One thing to keep in mind: this structure is mostly for humans, as roslaunch and rosrun fi don't care where you've placed your binaries / executable scripts. They'll crawl the complete package and its sub directories. There are certainly things which must be in a certain location (such as the manifest and build script), but the rest is not important.
And an observation:
catkin_ws/src/my_package │ ... ├── venv ...
Personally I would not place a Python venv inside the src space of a Catkin workspace, but you may have good reason to do so. You may want to look at tools such as catkin_virtualenv to manage this instead.
Edit: and I just noticed this:
catkin_ws/src/my_package │ ├── cmake-build-debug ..
What is cmake-build-debug? Are you doing in-source builds with cmake directly?
I would expect build artefacts to only exist in the build space of your Catkin workspace.
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.