ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
2

How to maintain several versions of a ros based robot?

asked 2021-02-23 05:03:34 -0600

felixN gravatar image

updated 2021-03-01 02:45:41 -0600

Hi,

I'm working in a startup building robots, where I'm doing the software part. Until recently, things were easy, we had a single prototype to work on. Now, we start to deliver the first prototypes to clients, with some differences in hardware (we still improve things, but we can't backfit it if the robot is already at the client's place), and some small differences in features.

Until now, I'm simply using git (with a single master branch, and sometimes small branches to try some new features) to maintain the code. That worked well as long as I had a single robot, but maintaining all the small differences is a bit of a pain.

So my question is how best to maintain in parallel a few robots with 95% of identical code, but some small differences?

  • Should I go for param files in ros? (which means that each file has to handle all cases)
  • Or is there a nice solution using git?
  • Or should I use the #define mechanism of C++ (nearlly all my nodes are in C++)
  • Other ideas?

Nb : I'm asking the question on ROS Answers because the best solution might be ROS related, but I'm also perfectly fine with answers not depending on ROS

Thanks a lot in advance

Felix

EDIT :

as requested, the type of differences I have :

  • different number and position of proximity sensors
  • additionnal overload sensor (ie 2 additionnal nodes, no change in existing nodes, but they have to be in the launchfile)
  • a few different parameters (eg : url of the server for remote control)
  • an additional navigation mode on some robots (several extra nodes, potentially a small change in one common node)
  • maybe in future : omni wheels on some models (not planned for the comming few month)
edit retag flag offensive close merge delete

Comments

The most flexible answer would be to use different params files. That way you will have different features for 'robot1' and 'robot2' rather easily. The benefit being that when you test or make changes you do not have to build your system each and every-time. Params as I know have their limitations.

But it also depends on the complexity. If the differences cannot be handled by rosparam then you can also have several working branches in git for each of your individual packages. This way your system would be very modular. Then with git you will have three branches for each package: 'robot1', 'robot2' and 'common' so that if there are packages you want to update for both robots, you can simply upload it to the 'common' branch.

The solution with #define is a bit tricky as it would make a single file very flexible, but this would also make ...(more)

turtleMaster20 gravatar image turtleMaster20  ( 2021-02-24 08:58:37 -0600 )edit

It might be good if @felixN could provide a little insight into what exactly would be different between these "versions of robots".

Minor things (address offsets for peripherals on I2C or something), or major things (like the physical structure, or the nr of wheels, type of kinematics, etc).

The former would be solvable using parameter files.

The latter starts to sound like different product lines, which would require other solutions.

gvdhoorn gravatar image gvdhoorn  ( 2021-02-26 02:59:19 -0600 )edit

@gvdhoorn : as asked, I added the differences in the initial post

felixN gravatar image felixN  ( 2021-03-01 02:46:27 -0600 )edit

2 Answers

Sort by ยป oldest newest most voted
0

answered 2021-02-25 17:48:54 -0600

ejalaa12 gravatar image

Managing version across multiple repositories is not easy. I experienced the same issue in my job.

What I would advise is the following. The first step is to isolate those differences, which can be:

  • different nodes
  • same nodes different params
  • same package, different features=different git commit

Next, create a package for each robot (let's say you have 2 robots): robot1_robot & robot2_robot.

Create a common_robot package that will contains launch files, and params common to both robot. Then, each robot package will contain its specific launches & params, you will also include the common_robot launches that are needed.

Those 3 pkgs will only contain params and launches that include node from your other pkgs. Each of these 3 packages is then git-ed and versionned.

Finally, to track the version of robot1 for example, create a workspace for robot1. Clone in the packages robot1 depends on: robot1_robot, common_robot, pkgA, ..., pkgF. Checkout each one of them to the version needed by robot1. You can then either use vcs-tool to export the workspace to a yaml file, you then can update the yaml with every update. Or you can create a git submodule.

It's a lot, but don't hesitate if you have questions :)

edit flag offensive delete link more
0

answered 2021-02-26 01:51:05 -0600

The most flexible answer would be to use different params files. That way you will have different features for 'robot1' and 'robot2' rather easily. The benefit being that when you test or make changes you do not have to build your system each and every-time. You can also make individual packages for each robot but creating folders called 'robot1' and 'robot2' inside the same package will also do the trick. Params as I know have their limitations.

But it also depends on the complexity. If the differences cannot be handled by rosparam then you can also have several working branches in git for each of your individual packages. This way your system would be very modular. Then with git you will have three branches for each package: 'robot1', 'robot2' and 'common' so that if there are packages you want to update for both robots, you can simply upload it to the 'common' branch.

The solution with #define is a bit tricky as it would make a single file very flexible, but this would also make the code structure a bit complex. I would choose this as the last option.

edit flag offensive delete link more

Question Tools

3 followers

Stats

Asked: 2021-02-23 05:03:34 -0600

Seen: 264 times

Last updated: Mar 01 '21