How do you structure your projects and workspaces?

Hello all,

I am the author of the HAROS analysis framework for ROS1, and I am now in the process of redesigning it, with the main goal being ROS2 support. Since I am making considerable changes to the tool, I figured I would take this opportunity to try to make its workflow more suitable to what people might expect from it.

Thus, I am asking for your feedback. How do you structure your projects and workspaces?

  1. Do you distinguish the two concepts, or is project and workspace a 1:1 relation?
  2. Do you have projects using more than one workspace?
  3. Conversely, do you have code belonging to different projects sitting within the same workspace?
  4. When running tests and verification tools, would you rather run a command at the root of a workspace (à la build) and have workspace-level settings (à la git) and analysis reports, or would you rather have some sort of finer-grained control?

Any and all feedback is welcome!
Thanks in advance!

3 Likes

Hi! I usually have only one or two workspaces in my system. No more. The trick I do when I dont want to recompile basic dependencies each time I make some changes in a new project is to save the source code outside the workspace and make a symbolin link to them. In this way, I can add or delete the symbolic link when I want to compile them or not.

On the other hand, for aeach ROS/ROS2 package I usually have the following structure:
‘src’ folder → source code implementations is located here
‘include’ folder → headers are located here
‘launch’ folder → launchers files are located here. In ROS case, ‘.launch’ files; in ROS2 case ‘.py’ files
‘CMakeLists.txt’ and ‘package.xml’ files

1 Like

I would put my two cents here:

  1. For me, they are different. A workspace can contain multiple projects inside. For example, workspace can be a collection of all the packages that form a software stack on a robot(perception, navigation etc.), but this every single package can be a separate project with different language, testing paradigms and even teams working on it.
  2. Yes, I find it useful to separate and overlay workspaces in for example the following case. Suppose I have some packages that are used as a 3rd party dependency, and most of the time I don’t change anything in them. I would put them in a separate workspace and later overlay that ws in my actively developing workspace. This way I can still get back to 3rd party packages and make some minor changes to the code, but I do it very rarely.
  3. I think it’s answered in 1.
  4. I would have both. For individual developer it’s really useful to run that on package level, but to control the overall development of workspace can be handy to have that on the root(e.g. colcon test).

But also I think it’s useful to define, how do you define a project? For me, it’s project==package. But also project can be for example “to develop a perception pipeline” and this will consist of multiple packages and even can grow into whole separate workspace.

Thanks for sharing the HAROS framework! Have never seen and definitely will look into exploring it!

1 Like

Interesting, I wouldn’t have thought of using links. But isn’t that harder to manage than using multiple workspaces and overlays?

1 Like

That’s more or less how I have been treating projects so far. They are user-defined, because it depends on the situation. It could be just one package, or multiple. And each project might have different requirements/settings, in terms of testing and analysis.

This is why I asked users to write a small project file in the current version of HAROS - so they can tell me which packages they want to analyse.
Now that I am moving to ROS2, I was thinking that maybe people associated projects to workspaces, since workspaces work differently from ROS1.

1 Like

I only use other workspace if I need to do something very specific. For example, I remember once I had to use a different python version to be able to run one package. I did it in a different workspace for not crash the other one.
About the symbolic links, if you put all that packages in a single folder, you only will have to remove or add one symbolic link.
However, in all my PC’s I have installed ROS and ROS2 environments and each one with one or two workspaces (it could be more). With some carefully it should not give problems

1 Like

For context we work on internal packages and customer machines. Deployments are managed via docker images.

Packages represent logical work structures. One package would be the nodes that represent all control and feedback for a widget. Interfaces for a package are build and organized separately to ease sharing (and following ROS general practices).

Workspaces are a bit more developer specific. Typically I use workspaces to switch between projects. Each customer would have a workspace volumed into a respective latest release docker container. So if I had widget control v1 and widget interface v2 built into the docker image, my workspsace would contain my working widget control v2 code.

When deploying on the field, workspaces are only used for field testing changes (or even worse, field changes) when things break. The code is then taken back through our vcs/ci/docker process for re-deployment on machines.

3 Likes

My preference is to use a workspace per project. If there are multiple packages I am working on, I would keep them in the same workspace, but only the packages I am actually developing. Stock packages, I install using apt under system installation and I try to stick to the released versions, not the rolling versions from upstream git.

The time when I would overlay another workspace for the same project is if I need to do some temporary modifications on a package that I am normally using as stock or if I have a fix that hasn’t yet been merged upstream, but I need it for my work. If that temporary fork-work spawns into more elaborate development, I would move it to my primary workspace. If it gets subsumed (e.g. fix gets merged), I would stop using the additional workspace.

3 Likes

Nice to hear. This is more in line with what I was expecting.

1 Like

The nature of my work means that I typically have several projects, and often several different features for a single project, in flight at the same time.

My basic assumption is that I treat a workspace like a Python virtual environment. Each workspace is created, used for its purpose, then thrown away (i.e. deleted).

Each workspace contains the source code I am working on, checked out to the branch for the feature I am working on. This means that some projects only have one workspace, but I might have several workspaces containing the same project but checked out to different branches if I’m working on several features for a project at once.

I don’t do multiple-project development in a single workspace. I find it easier to have separate workspaces because then it’s clear what I’m working on and that workspace can contain just the dependencies necessary for the specific feature under development in it.

I do have a few long-lived workspaces that are exceptions to the above.

  • Due to the size of the source code, I have one workspace per distribution of ROS 2. When I do work on, for example, rosbag2 or rclcpp, I use one of these because colcon is not good at overlaying projects that exist in the underlay as well.
  • One project I am currently working on requires using Drake, which has relatively complex needs to be compiled. For this reason I only have one workspace and switch the checked out branch when changing which feature I’m working on.

There are trade-offs in my approach. I currently have 24 workspaces in my workspace folder, which is a lot. The folder size is 23 gigabytes, which is large. And there is a lot to compile if I stand up a new workspace with a lot of source in it. I work around these trade-offs by having a large disc, lots of RAM, and a fast CPU (I can compile all of ROS 2 in about 10 minutes).

When running test and verification tools, I would prefer:

  • To be able to control how the tool is run on a package-by-package basis. The linters are a good example of this. You can specify the linting rules for an individual package quite easily (if no package-specific rules are provided, system-wide defaults are used). This is important because each package has its own needs from code quality support tools.
  • To be able to run the tool at the workspace level, selecting either to run it on every package in the workspace (e.g. how colcon test works) or run it on a subset of packages (e.g. colcon test --packages-select foo bar).
3 Likes

Thank you for this detailed answer!

This is more or less what I expected and wanted to hear; that users create a workspace for a specific project (whatever that concept may be), set some things up specifically for it, and then move on.

Of course, the general answer is always “there’s exceptions, it’s complicated”. But, as long as this process is more or less the norm, I am happy with it.

Using only one workspace is fine. But I sometimes put unchecked third-party packages in other workspaces as well. Using containers to isolate different projects should be a better way. Here is our template for Jetson.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.