ROS2 Configuration management
Hello,
In my project, as we get more customers, more hardware versions, more robots, configuration management is becoming more and more complex to manage and I'm wondering how does the ROS community handle it.
Our config is centralized in the bringup package, as it is for many I assume. One idea would be to move the config to its own repository and create a branch for each robot. A problem with that approach is that, to add/delete/modify a parameter, one would have to do it for each branch.
Another approach would be to have a default configuration in the bringup package/repository and in a separate configuration repository, create branches for each robot but only with some yaml files that override the defaults.
How do you version control your ROS configuration efficiently and scalably for a system where parameter modifications is still very common? This doesn't sound like a ROS/Robotics specific problem yet I failed to find much help online.
Asked by tnajjar on 2022-07-13 12:25:36 UTC
Answers
I can't speak for the best way of doing it, but "a" way I've done it is to have the configurations in cloud storage where its very easy to do bulk operations where required and then setup my CM software to grab the right files for a given facility / robot type when its being initially bootstrapped or updates to software are made.
Asked by stevemacenski on 2022-07-13 14:26:53 UTC
Comments
I appreciate the help Steve. Could you share some cloud storage and CM software examples that could do the job as you describe? CM software google results don't seem like something I could use.
Asked by tnajjar on 2022-07-13 16:22:40 UTC
Things like Ansible, Chef, Puppet, etc. I don't have any examples that I could share
Asked by stevemacenski on 2022-07-14 14:21:15 UTC
I've tried the bringup package approach but this leads to one overly complicated repository. Finding this hard to maintain and making some operational tasks time consuming.
I then moved to separate repositories for different types of configuration parameter; robot specific, deployed site specific, robot hardware version specific etc. Then branches to facilitate switching between sites, specific robots etc. This can work fairly well with little time investment in the setup. Like you mention the main issue is that if you want to update a single value for all branches of a given repo, but this can be mitigated by splitting out robot specific and manufacturing batch specific configurations
Steve's cloud based solution sounds like a much more scalable long term approach.
Interested to see if there are any other methods out there too.
Asked by MShields1986 on 2022-11-30 16:54:42 UTC
Comments