ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A answers.ros.org

Best practice on maintaining a repository

Hi guys,

Just need some advice regarding my project https://linorobot.org . I’ve posted it here last month: Linorobot - 2WD, 4WD, Mecanum and Ackermann Steering ROS platforms .

Basically it supports 2WD, 4WD, Mecanum, and Ackermann steering. Currently, each base has its own repository which includes the microcontroller codes, Nav Stack launch and param files. Since the kinematics of each robot is almost similar and can be written in one unified code, shall I just store it one repository or retain all the repos and keep them independent?

2 Likes

Keeping it separate will be much appreciated since others can test each package individually and add support for new hardware. I am now planning to incorporate your robot platform for education research. I will start by building the 2wd robot during the new year break. Your project is a great initiative for those of us who are not so much familiar with the hardware part and can learn immensely by learning to make the robots and using ROS. I strongly suggest you to make a google group for the linorobot so that people interested in the project can have open discussion. Just my suggestion.

1 Like

First of all I wanted to mention, that your project really looks fantastic and your attention to detail when it comes to documentation is very impressive. Big Thanks, I would have really loved to have those resources when I was in school learning how to build a robot.

But to answer your question: Neither way is perfect. As mentioned in the previous comment having all parts separated makes it easier to swap out a component. But in my experience it can be quite painful to maintain a bunch of repositories, that are dependant on each other.

This is mainly due to the fact, that you need to track, which versions of one repository will work with another repositories version. In the past I relied mostly on syncing them by time and making sure, that the current master branches will work together. As ROS currently does not have a method for resolving versions (e.g. with semantic versioning) other then the main distributions (indigo, jade, etc.) it can be very difficult to deal with the introduction of a breaking change in one of your repositories.

If you put your project in one repository you can make sure, that every commit on master is in a consistent state, where all components work well together. There are other solutions for that, like for example git subrepos, but they are often more complicated. Also code sharing between different platforms is way easier when they are in the same repository.

Also if somebody wants to add a new platform/hardware they can fork your repository and maybe even merge it back, which would allow you to see, whether a new feature breaks a different platform (I would only do that, if the new platform would be adopted by several people, otherwise just forking would definitely suffice, adding the benefit that your changes wouldn’t necessarily break other platforms, as somebody could choose whether to upgrade).

So in conclusion: If you want to share code between the platforms, or there are currently dependencies between repositories it would make sense to switch to a monorepo. If the code in each repository is completely independent of each other it makes sense to put them in different repositories.

6 Likes

Thank you so much for your advice. I’m currently refactoring all the platforms to support a much higher motor driver, hence bigger robots and for more modularity. I’ll consider these advices once I have all the versions stable. Hope you can join our discussions. Just created a google groups here: https://groups.google.com/forum/#!forum/linorobot

Thanks for the suggestion. I just created a Google group. Feel free to post if you have any question or want to share any latest robot you’ve built. Here’s the group: https://groups.google.com/forum/#!forum/linorobot . See ya! :slight_smile:

Can’t agree more with @dreuter’s post (that already got 3 likes btw). Adding some comments:

  • I can’t help but to stress out that reducing maintenance cost for mid/longer term is worth being considered even at the earlier active development phase. So many packages in ROS are abandoned unfortunately (I assume it could be an inevitable nature of software life-cycle though). Reducing the maintenance cost is not the one-stop solution for that issue but can help both the maintainers to keep the maintenance work and finding new active maintainers.

  • For consolidating packages/repositories,

    • FYI MoveIt! projects recently consolidated several repositores of various modules into one larger repo. You can see the discussion back then.
    • Separating packages just to allow end-users to easily swap one-by-one sounds like to me adding technical debt with very few advantages. I believe there are number of driver packages that handle multiple particular devices under the same product family.
5 Likes

Thanks for the great advice guys. As what you have advised, I did release a beta v1.0 of this project. There was a major revamp to support more motor drivers, IMUs and LIDARs in the future.

Due to maintainability issues I’ve also merged all the supported bases (2WD, 4WD, Mecanum drive, and Ackermann steering) into one repo .

You can check out the release notes here: https://github.com/linorobot/linorobot/releases/tag/v1.0-beta
and the new wiki here: https://github.com/linorobot/linorobot/wiki

Do join our small forum if you need help :stuck_out_tongue: https://groups.google.com/forum/#!forum/linorobot

Cheers!

1 Like