How to maintain several versions of a ros based robot?
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)
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)
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 : as asked, I added the differences in the initial post