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 |
I wrote the answer to #q264600, but I don't believe things have changed with ROS 2.
it looks like the foxy build/install in ~/ros2_foxy would be our workspace.
this sounds like you are planning to build Foxy itself from source, as well as your own packages.
Is it typical to consider a robots custom packages/applications etc as an overlay?
Technically, all workspaces are overlays, unless they contain the "base ROS packages" I would say.
Eg. would/should we track our overlay in git?
You'd track individual packages (or coherent sets of those), never entire workspaces/overlays.
| | 2 | No.2 Revision |
I wrote the answer to #q264600, but I don't believe things have changed with ROS 2.
it looks like the foxy build/install in ~/ros2_foxy would be our workspace.
this sounds like you are planning to build Foxy itself from source, as well as your own packages.
Is it typical to consider a robots custom packages/applications etc as an overlay?
Technically, all workspaces are overlays, unless they contain the "base ROS packages" I would say.say (ie: form the base layer).
Eg. would/should we track our overlay in git?
You'd track individual packages (or coherent sets of those), never entire workspaces/overlays.
| | 3 | No.3 Revision |
I wrote the answer to #q264600, but I don't believe things have changed with ROS 2.
it looks like the foxy build/install in ~/ros2_foxy would be our workspace.
this sounds like you are planning to build Foxy itself from source, as well as your own packages.
Is it typical to consider a robots custom packages/applications etc as an overlay?
Technically, all workspaces are overlays, unless they contain the "base ROS packages" I would say (ie: form the base layer).layer) and bootstrap your ROS install.
Eg. would/should we track our overlay in git?
You'd track individual packages (or coherent sets of those), never entire workspaces/overlays.
| | 4 | No.4 Revision |
I wrote the answer to #q264600, but I don't believe things have changed with ROS 2.
it looks like the foxy build/install in ~/ros2_foxy would be our workspace.
this sounds like you are planning to build Foxy itself from source, as well as your own packages.
Is it typical to consider a robots custom packages/applications etc as an overlay?
Technically, all workspaces are overlays, unless they contain the "base ROS packages" I would say (ie: form the base layer) and bootstrap your ROS install.
Eg. would/should we track our overlay in git?
You'd track individual packages (or coherent sets of those), never entire workspaces/overlays.
Edit:
What would we track in git in that case?
As always: packages. You always only place packages in a VCS. And with packages I mean: the source code. So not the binary artefacts (ie: no .zips, nor .debs or other form of packages which are the result of a build process).
Or sets of packages for which it makes sense to version them together in a single repository.
A .repo file like the ros2.repo but with our packages and put all of that inside of a directory as recommended for an overlay?
This sounds like a different issue: whether you store source artefacts in a VCS and how, does not immediately affect how you would then use that VCS to seed your workspace.
A .repos file is only really just input to a tool like vcs which you use to help you seed your workspace. It does not immediately have any implications on how you then store your packages in a VCS.
I'm new to Ros to apologizes for lack of proper terminology
The terminology is fine. In the end there is nothing really ROS-specific here I believe.
How do you normally version your C++ libraries or applications or Python packages or applications? To me, it makes a lot of sense to not lump everything together in a single, big repository, but to separate libraries from applications (fi) and to not put things together when they don't need to be stored together.
It's exactly the same here. It's just that we call things ROS packages. But in the end it's all just a bunch of files that happen to "belong with each other" for whatever reason.
An example on github would be great but I'm not sure what to look for even or if those would match what you as experts would recommend.
Well, could you clarify what you exactly would like to see an example of? I'd say any of the repositories in the github/ros2 organisation would be examples. They are laid out in exactly the way I described above:
.repos files which are consumed by tools like vcs and used to seed workspaces whenever there is a need to build (a set of) packages from source.zips or tarbals or .debs) for consumption by platform package managers are not hosted in/by the VCSThis has been the way it was (and still is) done for ROS 1, and how it is done for ROS 2.
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.