Ask Your Question
0

Guide for managing ros2 project in git

asked 2020-03-24 14:34:13 -0500

cmorgan gravatar image

updated 2020-03-24 15:46:30 -0500

This question from 2017 asks the same question, https://answers.ros.org/question/2646..., but I thought things may have changed since then.

Our use case is likely typical:

  • Using git (through self hosted bitbucket)
  • Ros2 (foxy), on 20.04 (project is a few years in duration so we are ok with being slightly unstable right now)
  • We'll have a number of packages providing publishing for sensors and robot logic

From the documentation on setting up a workspace (https://index.ros.org/doc/ros2/Tutori...) it looks like the foxy build/install in ~/ros2_foxy would be our workspace.

Is it typical to consider a robots custom packages/applications etc as an overlay? Eg. would/should we track our overlay in git?

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
2

answered 2020-03-24 14:46:23 -0500

gvdhoorn gravatar image

updated 2020-03-25 05:11:31 -0500

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:

  • only contain source artefacts
  • (try to) only put packages together which belong together
  • applications are typically separate from libraries
  • some repositories contain only .repos files which are consumed by tools like vcs and used to seed workspaces ...
(more)
edit flag offensive delete link more

Comments

Hi! What would we track in git in that case? 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? (I'm new to Ros to apologizes for lack of proper terminology). 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.

cmorgan gravatar image cmorgan  ( 2020-03-24 15:12:18 -0500 )edit
1

@cmorgan to be able to receive a specific recommendation you need to edit your question to include more details about what you want to do. There are many possible workflows for projects and no one recommendation that will fit all projects. As there's no significant workflow difference from ROS 1 to ROS 2 please indicate which of the linked answers in (#q264600) you've tried or considered and why they do or do not meet your requirements.

tfoote gravatar image tfoote  ( 2020-03-24 15:27:24 -0500 )edit

Hi @tfoote. I'll have to try out the overlay option I guess to learn more about what it means to build a package for ros. It may be that we can put our overlay into git with a submodule per package but I'm just poking in the dark here. I'm hoping using it will help make it more obvious how it works.

cmorgan gravatar image cmorgan  ( 2020-03-24 15:48:44 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2020-03-24 14:34:13 -0500

Seen: 48 times

Last updated: Mar 25